El CRM que configuraste para ahorrar en usuarios te está costando más de lo que crees
Flex, seasonal y temporary users: el hueco que ningún proveedor de CRM quiere llenar, y por qué la IA no es el atajo que muchos creen
Usuarios temporeros y "flex users": ¿por qué los proveedores de CRM se niegan a ofrecerlos?
Hay un patrón que veo en casi todos lados: en México, en Colombia, en Puerto Rico, en Estados Unidos. En banca, en automotriz, en educación, en retail, en restaurantes. Cambia el CRM, cambia la geografía, pero la historia es la misma.
La empresa tiene usuarios que necesitan usar el CRM para apoyar las operaciones, pero no son 100% “full users”: son “flex users” por temporada alta, por turnos o solo para realizar una tarea puntual, como las aprobaciones. No quieren pagar una licencia completa para cada uno de ellos, por temas de presupuesto, entre otras razones. Pero como el proveedor no le ofrece una opción óptima, "busca la vuelta". Configura, desarrolla o improvisa algo para no pagar a esos usuarios.
Y ahí nace la deuda. Deuda técnica y deuda funcional que, tarde o temprano, pueden costar más que las licencias que se quiso evitar. Y aquí hay culpa tanto de las empresas como de la industria y de los proveedores de CRM.
Veamos esto por partes.
El hueco: lo que los proveedores de CRM ofrecen y lo que no
Los proveedores de CRM sí tienen opciones para usuarios "livianos":
Salesforce tiene licencias Platform, Identity e Integration, para usuarios que no necesitan todo el CRM. Por ejemplo, el Platform user es una opción, pero tiene restricciones al usar el objeto de oportunidad. Y Salesforce te ofrece 5 Integration Users gratis para tus integraciones vía API.
Microsoft Dynamics 365 tiene la licencia Team Member, pensada para el usuario ocasional que solo lee datos o realiza tareas simples.
Desde marzo de 2024, HubSpot cambió a un modelo de "seats": Core (de pago) y View-Only (gratis, pero solo lectura).
Zoho tiene "Team Users" para áreas de operaciones de apoyo a las ventas; su modelo es pay-as-you-go, mensual por usuario. Puedes bajar y subir usuarios; no tiene contrato y, si pagas anualmente, te dan un mejor precio.
Notas:
(1) Me enfoqué en estos 4 proveedores; no analicé los detalles de otros proveedores como SugarAI, Pipedrive, Oracle, SAP, Odoo, Bitrix24 (cobra por tarifa “flat”, no por usuario), Creatio (que ahora tiene unlimited users), Freshworks, Copper, etc.
(2) Pero el mapa completo queda así: el usuario estacional/temporal/concurrente no existe en los enterprise (Salesforce, Dynamics, Oracle, SAP, SugarCRM / SugarAI, Creatio) ni en la mayoría de los per-seat de mercado medio. La única forma real de esquivarlo hoy, sin incurrir en deuda técnica ni en acceso indirecto, es adoptar un modelo flat como el de Bitrix24, asumiendo sus límites. O vtiger que es open source.
(3) La licencia de Zoho es la que más se acerca a permitir usuarios temporales, pero todo depende del cálculo basado en el número de usuarios.
El problema es que ninguna de esas opciones resuelve el caso del usuario estacional, temporal o concurrente. Todas siguen siendo licencias nominales (named), asignadas a una persona, y facturadas por mes o por todo el año, aunque esa persona solo trabaje tres meses o dos días por mes.
Lo que no existe en los proveedores de CRM es lo que de verdad haría falta:
Un usuario estacional: pagas solo durante la temporada alta.
Un usuario concurrente, en el que varias personas de distintos turnos comparten un pool de licencias.
Un usuario flex por consumo, en el que pagas por el uso real.
Ese modelo concurrente existía en el mundo on-premise (me acuerdo de Vantive, Clarify, Siebel y otros), y en el mundo de contact center (CaaS) en algunos mercados y/o “legacy licensing”. Pero en el Cloud, en el mundo de CRM, ganó el named user. Y con eso desapareció justo la flexibilidad que las empresas con fuerza laboral variable más necesitan.
¿Por qué los proveedores de CRM no lo ofrecen? (spoiler: Wall Street).
No es que se les haya ocurrido. Es su modelo de negocio.
El named user le proporciona al proveedor ingresos predecibles y recurrentes. Eso es exactamente lo que valora Wall Street y lo que sostiene el precio de la acción de una empresa de SaaS. Un modelo estacional o por consumo introduce ingresos variables, más difíciles de proyectar. Noten la ventaja que tiene Zoho en sus precios, ya que es una empresa privada y no tiene que lidiar con Wall Street.
Además, el named user les da control: cada persona con su cuenta, sin cuentas compartidas, todo auditable y todo licenciado. Para el proveedor de CRM es más ingreso y más control. Para la empresa con picos de temporada, esto no es óptimo.
La deuda que genera
Cuando el proveedor solo te da "licencia completa" o "licencia liviana", y ninguna ayuda con tu realidad, la empresa improvisa. Y las improvisaciones que veo casi siempre son las mismas:
Logins compartidos (un usuario genérico).
Apps personalizadas para estar al límite de la licencia barata o gratuita.
Datos que se ingresan al CRM por fuera: Excel, cargas batch, sistemas externos, exportaciones e importaciones manuales.
Y muchas otras cosas que he visto son muy creativas.
Cada una de esas "soluciones" crea deuda en varias dimensiones:
Modelo de datos. Se crean objetos o tablas custom solo para esquivar los límites de licencia. Se rompe el diseño limpio.
Calidad de datos. La información entra tarde, en batch, o por un usuario genérico. Se pierde el tiempo real y la trazabilidad.
Seguridad y gobernanza. Los logins compartidos rompen la atribución (¿quién hizo qué?) y violan la segregación de funciones. Es un dolor de cabeza en cualquier auditoría.
Compliance de licencia. Este es el que muerde después. Los proveedores de CRM pueden fiscalizar el abuso de las licencias al verificar que los roles del usuario coincidan con la licencia correspondiente y, si no lo hacen, bloquear el acceso.
Adopción. La gente que quedó fuera sigue trabajando en Excel o en WhatsApp, y el CRM deja de ser la única fuente de verdad. Que, irónicamente, es lo único para lo que sirve un CRM.
¿Las integraciones resuelven el problema?
Aquí es donde muchos se emocionan. "Si el CRM no me permite dar acceso a todo tipo de usuario, uso una plataforma de integración (iPaaS) y mantengo la lógica del CRM en otra app donde la gente ya trabaja."
Técnicamente se puede. Contractualmente, puede ser un tema legal; depende del caso de uso.
El concepto se llama acceso indirecto (indirect access) y multiplexing: usar el software a través de otra aplicación o mediante una sola conexión que sirve a múltiples personas. Ya hay ejemplos legales en varios países y con distintos proveedores de CRM. Hay que leer el “fine print” de los contratos y renovaciones.
Y aquí está el punto que más me importa, más allá del susto legal: el multiplexing te deja un registro de auditoría incompleto de quién hizo qué. No solo es un riesgo de compliance; también afecta la calidad de los datos y la gobernanza, de las que dependen todas tus decisiones.
¿Y la IA vía MCP o con agentes de IA?
La pregunta lógica de 2026 es: ¿y si en vez de darle una silla a ese usuario ocasional, dejo que un agente de IA haga el trabajo, o que la gente consulte los datos en lenguaje natural vía MCP?
Vale la pena separar dos cosas que se confunden mucho.
MCP es una tubería, no un atajo de licencia. El Model Context Protocol permite que un modelo consulte y actúe sobre el CRM en lenguaje natural, sin integraciones custom. Bajan el costo para los usuarios y pueden subir el costo de los tokens. Pero respeta los permisos existentes.
El servidor MCP de los CRMs lo deja claro: todas las acciones respetan los permisos del usuario; solo puedes ver y modificar lo que ya tienes permitido en el CRM.
Si canalizas a 50 empleados sin licencia a través de una sola conexión MCP para que hagan trabajo de CRM, eso es multiplexing otra vez. MCP no te salva de licenciar a quien usa los datos.
El cambio real del modelo radica en cómo se paga el trabajo del agente. La gran mayoría de los CRMs tienen un modelo de consumo, no de asiento: se cobra por conversación o por resultado del agente, no por asiento. Cada acción consume créditos, y pagas por lo que el agente hace. (Los modelos de precios cambian con frecuencia; valida las cifras actuales con tu proveedor de CRM).
Ese es el puente conceptual hacia el "flex/seasonal" que tanto pedimos. Pero, cuidado: es para el trabajo del agente, no para la persona.
Dónde la IA sí ayuda con tu usuario ocasional, y dónde no
Sí, ayuda cuando el agente hace el trabajo de verdad de forma autónoma. En vez de darle una silla a alguien que entra dos veces al mes, el agente ejecuta la tarea (actualiza un registro, resume un caso, responde una consulta) y pagas por esa acción. También ayuda a proporcionar a ejecutivos ocasionales, en lenguaje natural, insights de solo lectura.
No ayuda, y de hecho te mete en problemas, cuando usas el agente o la integración como disfraz de un humano haciendo trabajo de CRM. Ahí no eliminaste al usuario: solo lo escondiste detrás de una máquina. Sigue siendo acceso indirecto, y los proveedores de CRM lo van a tratar como tal.
La línea es simple de decir y fácil de cruzar sin darte cuenta: ¿el trabajo lo hace el agente, o lo hace una persona a través del agente?
Qué hacer (lo práctico) – Mis Recomendaciones
Esto es lo que recomiendo:
Segmenta bien los roles antes de comprar. La mayoría de los usuarios no necesita una licencia completa. Define quién de verdad edita y quién solo consulta.
Usa los tiers livianos correctamente, no de forma abusiva, y audítalos con regularidad. No esperes a que el vendor te fiscalice.
Para externos y ocasionales, aprovecha modelos por login o por consumo donde existan.
Para picos estacionales, considera proveedores de CRM con contratación mensual real y la opción de dar de alta o de baja según la temporada, como Zoho.
Si vas a usar IA/MCP, hazlo con gobernanza sólida: expón al agente un conjunto reducido de herramientas aprobadas, mantén las reglas de negocio del lado del CRM y registra todo para auditar qué se hizo, por quién y con qué datos.
Negocia. El usuario estacional es una conversación legítima en cada renovación o contrato nuevo, sobre todo en industrias con ciclos marcados: turismo, retail, agro y educación, con temporadas de admisión. Dependiendo del número de usuarios, el proveedor de CRM sí puede pasar del "pago por usuario" al "pago por uso". He visto que el modelo flex es viable en algunas negociaciones con cientos de usuarios. Lo he visto en ocasiones con grupos de empresas – descuentos muy bajos con contratos de 3 a 5 años. Mira Creatio y su unlimited user edition.
TCO & ROI: Trae a la mesa a tu CFO y a los principales ejecutivos del proveedor de CRM en tu país o región. Calcule junto el TCO/ROI, a partir de precios y tipos de usuarios, con escalones de crecimiento y de baja de usuarios, y las temporadas de cada tipo de usuario.
El Contrato: Las condiciones de licenciamiento de usuarios, add-ons, ediciones, los modelos de precios de IA y el estado de las funciones (GA, beta, etc.) cambian con frecuencia. Antes de tomar una decisión de compra o de armar un caso de negocio, valida cada cifra y cada política contra la documentación oficial vigente de cada proveedor de CRM en todo tu stack tecnológico.
El futuro del licenciamiento del CRM
El licenciamiento por named user no desaparecerá mañana. Pero el modelo de consumo ya llegó por la vía de los agentes de IA, Eso demuestra que el "flex user" que las empresas necesitan es totalmente viable. Solo falta que los proveedores de CRM lo apliquen tanto al usuario humano ocasional como al “full user”. Pero creo que esto lo decide Wall Street.
Mientras tanto, la peor decisión es la más común: configurar el CRM para no pagar a los usuarios, acumular deuda técnica y funcional en silencio y descubrir la factura completa el día de la auditoría del proveedor de CRM o cuando los datos ya no sirven para decidir nada.
Hay que sentarse con el proveedor de CRM para explorar opciones y negociar. Trae al CFO a la mesa a negociar.
Para cerrar, aquí tienes tres títulos alternativos para este blog post:
Flex, seasonal, temporary users: el tipo de usuario que ningún proveedor de CRM quiere ofrecer
Configurar tu CRM para no pagar usuarios es la deuda técnica más cara que nadie está midiendo
No, las integraciones y la IA no te van a salvar para pagar usuarios en tu CRM