¿El fin del software por asientos? Qué cambia con los agentes
Con agentes, conviene revisar si cobrar por asiento, uso, acceso o una combinación. Un análisis de incentivos, límites y alternativas.
TL;DR: El precio por asiento sigue siendo útil cuando la colaboración humana es la métrica de valor. Los agentes pueden debilitar esa relación en procesos automatizados, pero no imponen un único sustituto: uso, acceso, resultado y modelos híbridos tienen ventajas y riesgos que deben medirse.
Puntos clave
- El asiento funciona como métrica cuando cada usuario adicional crea valor o costes de colaboración reconocibles.
- Si un agente procesa trabajo sin una cuenta humana adicional, conviene comprobar si los asientos siguen correlacionados con el valor recibido.
- Uso, resultado, acceso y modelos híbridos son alternativas; ninguno es correcto para todos los productos.
- Un plan gratuito o una prueba pueden reducir fricción de evaluación, pero deben tener costes, límites y objetivos medidos.
- El precio por asiento aporta previsibilidad; el precio por uso alinea actividad y factura, pero puede generar gasto variable difícil de anticipar.
El precio por asiento entra en tensión cuando una parte relevante del trabajo deja de corresponder a una cuenta humana. Esa es la tesis que analizamos, no una fecha de defunción del modelo.
Vale la pena entender cuándo el asiento sigue siendo una buena métrica, cuándo deja de serlo y qué alternativas se pueden contrastar.
Por qué el precio por asiento tenía sentido
El SaaS clásico necesitaba una unidad de medida simple para cobrar. «Por usuario y mes» es fácil de explicar y puede correlacionarse con el valor cuando más personas colaborando significa más uso efectivo del producto.
Funciona como proxy: no mide el resultado directamente, pero cuenta identidades autorizadas. Esa aproximación sigue teniendo sentido en permisos, colaboración y gobernanza; pierde fuerza cuando gran parte del volumen se procesa mediante integraciones o agentes.
El modelo también separa la factura del volumen de trabajo: un equipo puede crecer y pagar más aunque cada persona use poco el sistema, o mantener pocos asientos mientras aumenta mucho su automatización. Son desajustes posibles que deben medirse, no intenciones que puedan atribuirse a todos los proveedores.
Por qué puede desalinearse con agentes
Un agente no equivale necesariamente a una persona licenciada. Según las herramientas y permisos disponibles, puede leer datos, preparar borradores o ejecutar tareas concretas; su velocidad, cobertura y fiabilidad deben probarse por flujo.
Imagina, solo como escenario, que cinco cuentas se reducen a una persona supervisora y un agente que cubre parte del trabajo repetitivo. No se puede asumir que conserve el mismo resultado: la revisión, las excepciones y la responsabilidad siguen existiendo. El escenario sirve para probar la métrica de precio, no para prometer una reducción de plantilla.
En ese escenario, el importe por asientos caería un 80 % si solo se licencia una de cinco identidades, mientras que el volumen podría no caer en la misma proporción. El proveedor puede responder con límites de uso, una licencia para agentes o un modelo híbrido. Lo importante es que la unidad facturada sea visible y predecible.
No existe contradicción automática: puede haber valor por colaboración humana y por automatización a la vez. Sí existe un riesgo de desalineación si el contrato obliga a pagar identidades que ya no participan o esconde cargos variables que el cliente no puede anticipar.
Alternativas al asiento
Cuando el usuario ya no es necesariamente humano, conviene comparar «cuántas personas usan esto» con «qué volumen o resultado procesa». Tres alternativas que puedes evaluar son:
Por uso. Pagas por lo que el sistema procesa —facturas, documentos, llamadas o tareas—. Alinea la factura con actividad medible, pero exige contadores auditables, alertas y topes para evitar sorpresas.
Por resultado. Pagas por una salida acordada —una conciliación aceptada o una tarea completada—. Puede acercarse al valor, pero exige definir calidad, atribución, revisión y qué ocurre con los intentos fallidos.
Por acceso. Pagas por disponer del sistema dentro de límites explícitos, sin que cada identidad sea la unidad principal. Simplifica la factura, aunque el proveedor debe controlar costes y abuso de otra forma.
Ninguno de los tres es perfecto. Pero los tres tienen algo en común: ya no asumen que «usuario» significa «persona con cuenta activa que inicia sesión».
El plan gratuito como vía de evaluación
Un plan gratuito, una prueba o un entorno de evaluación pueden reducir la fricción inicial. No hay una única fórmula: dependen del tiempo hasta obtener valor, el coste marginal y la necesidad de acompañamiento o revisión de seguridad.
El agente no contrata por sí solo: una persona u organización sigue autorizando credenciales, permisos y gasto. Un recorrido autoservicio puede acelerar la prueba, pero en compras con requisitos de seguridad o contratación seguirá haciendo falta intervención humana.
Frihet publica un plan gratuito; sus límites y planes vigentes se consultan en la página de precios. El servidor MCP de Frihet se documenta como una superficie distinta: antes de automatizar, revisa herramientas, permisos y cobertura, sin inferir una autonomía mayor que la disponible.
La previsibilidad también tiene valor
El precio por asiento facilita prever la factura si el número de cuentas se mantiene estable. Una tarifa puramente por uso exige estimar también el volumen; un modelo híbrido puede añadir una base previsible.
En un ejemplo hipotético, un proveedor que cobra veinte euros por asiento a cien clientes con cinco asientos ingresa 10.000 euros mensuales antes de descuentos o bajas. El pago por uso o resultado introduce más variación: un mes puede tener mucha actividad y otro poca.
Para un proveedor, esa varianza es un riesgo financiero legítimo. Para el cliente, la predictibilidad también importa: una factura por uso sin alertas puede ser peor que una factura por asiento estable. Por eso los modelos híbridos —base fija más uso incluido o medido— merecen compararse junto a los extremos.
La solución debe repartir el riesgo de forma explícita: una unidad comprensible, límites observables y una relación razonable con el valor. No basta con cambiar «asiento» por «evento» si el evento resulta opaco.
Simula tres meses antes de cambiar el contrato
Estas tarifas son inventadas para comparar unidades de cobro; no son precios de Frihet ni una oferta de otro proveedor. Suponemos prestaciones y acceso equivalentes. Dejamos fuera impuestos, descuentos, soporte y coste de revisión humana.
- Plan A: 5 asientos a 20 € al mes cada uno.
- Plan B: 20 € de base al mes más 0,10 € por evento facturable, sin eventos incluidos.
- Un evento no equivale necesariamente a un resultado de negocio aceptado.
| Eventos facturables al mes | Plan A: 5 × 20 € | Plan B: 20 € + eventos × 0,10 € |
|---|---|---|
| 100 | 100 € | 30 € |
| 800 | 100 € | 100 € |
| 2.000 | 100 € | 220 € |
Las dos facturas se igualan a 800 eventos: (100 − 20) / 0,10. Por debajo sale más barato B y por encima A, con estos supuestos. No es un umbral del mercado ni una recomendación de producto.
Ahora prueba la definición de evento. Si 2.000 tareas útiles producen 2.500 eventos facturables porque también cuentan los reintentos, B cuesta 270 €. Si el contrato excluye esos reintentos, el resultado cambia. Conserva los fallos en el cálculo, aunque no produzcan un resultado aprovechable.
Lleva al proveedor un mes tranquilo, uno habitual y uno de máxima actividad. Pide que calcule la factura de los tres con la misma definición de uso. En una prueba pequeña usa una carga con un número conocido de peticiones e incluye un reintento, un resultado rechazado y un trabajo cancelado. Compara el registro de actividad, el contador de uso y la factura prevista; anota las diferencias en lugar de dar por correcto el mayor contador. Una alerta de gasto y un tope que detiene el proceso no son equivalentes: hay que definir qué sucede con el trabajo pendiente y quién puede cambiar el límite.
La pregunta que hay que hacer
Si usas software de gestión hoy —ERP, CRM, facturación, lo que sea— hazle una pregunta concreta a tu proveedor: ¿qué pasa con mi factura si conecto un agente y cambia el número de asientos que necesito?
Pide por escrito la definición de uso, los cargos adicionales y qué ocurre con el acceso y los datos históricos al reducir asientos. Compara la respuesta con tus necesidades de colaboración, seguridad y volumen. Mantener cinco licencias puede ser correcto si cinco personas siguen necesitando acceso y responsabilidad individual; cobrar por uso puede ser mejor si el agente concentra actividad, siempre que el gasto sea predecible.
Frihet dispone de un servidor MCP operativo con herramientas de consulta y gestión descritas en su documentación. Empieza por herramientas de consulta y valida cada flujo antes de usar las que crean o modifican datos.
La conclusión no es que el asiento desaparezca, sino que deja de ser la respuesta automática. Mide qué unidad refleja el valor, simula la factura en meses bajos y altos y conserva control humano donde haya efectos fiscales o financieros.
Fuentes y lecturas para contrastar el modelo
- Stripe: modelos de precios para product-led growth: compara freemium, prueba, asiento, uso e híbridos con sus límites.
- Stripe Docs: facturación basada en uso: documentación primaria sobre medición y cobro por consumo.
- Precios de Frihet: condiciones y límites vigentes del plan gratuito y los planes de pago.
Fuentes consultadas el 17 de septiembre de 2026. Los escenarios son ejemplos editoriales, no resultados medidos en clientes ni una propuesta de cambio de los planes de Frihet.
¿Te ha sido útil este artículo?
Preguntas frecuentes
¿Por qué algunos ERPs y CRMs cobran por usuario si parte del trabajo puede automatizarse?
Porque el asiento es sencillo de entender y mantiene relación con el valor en productos de colaboración. La automatización puede debilitar esa relación en algunos flujos, pero cambiar de métrica también introduce costes de medición, variabilidad y riesgo de facturas inesperadas.
¿Un agente de IA cuenta como asiento?
Depende del contrato, la autenticación y la métrica de cada proveedor. Antes de conectarlo, revisa si exige una identidad licenciada, cómo limita el uso de API o MCP y qué acciones permite. Frihet documenta su servidor MCP por separado; eso no convierte automáticamente cualquier tarea en trabajo autónomo ni elimina la supervisión.