Volver al blog
Automatización13 de marzo de 20265 min

De FTE's a Services as Software: El futuro de los BPO's

Durante años, la pregunta que se hacía un director o directora de operaciones al externalizar un proceso era siempre la misma: ¿cuántas personas necesito? Era la unidad de medida natural. El proveedor cotizaba FTEs (full time employees), el cliente aprobaba FTEs, y el éxito se medía en FTEs. Pero ese modelo está llegando a su límite, y cada vez más organizaciones están empezando a plantearse una pregunta distinta: ¿qué resultado necesito?

El modelo FTE tiene un problema estructural El BPO tradicional es, en esencia, un negocio de arbitraje de mano de obra. Cuanto más trabajo hay, más personas se contratan. Cuantas más personas se contratan, más factura el proveedor. La mecánica es sencilla, pero esconde una contradicción que rara vez se discute abiertamente.

El proveedor no tiene un incentivo real para ser más eficiente. Si automatiza un proceso, pierde facturación. Si reduce errores drásticamente, necesita menos personas para corregirlos. En el modelo clásico, la eficiencia va en contra del negocio del proveedor. No es mala voluntad, es la estructura del modelo.

Para el cliente, esto se traduce en una relación donde se compran inputs — horas, personas, capacidad — cuando lo que realmente se necesita son outputs: préstamos concedidos en plazo, siniestros resueltos correctamente, reclamaciones cerradas sin escalado.

De comprar recursos a comprar resultados El cambio que está ocurriendo en los modelos de externalización más avanzados es profundo. Los clientes ya no quieren comprar FTEs. Quieren comprar resultados.

Y esto no es solo un cambio de modelo de precios. Es un cambio de responsabilidad. Cuando se compra un resultado, el proveedor asume el riesgo de la eficiencia. Si tarda más, el coste es suyo. Si comete errores, el coste es suyo. Si el volumen escala, tiene que absorberlo sin que el cliente asuma más coste por cada persona adicional.

Esta lógica — propia del software — es la que empieza a aplicarse a los servicios. De ahí el concepto que está ganando tracción en el sector: Services as Software. No significa que las personas desaparezcan del proceso. Significa que el servicio se comporta como el software: con coste marginal decreciente, escalabilidad real y métricas de rendimiento claras.

Automatizar tareas, no puestos de trabajo Uno de los errores más comunes cuando se habla de automatización es plantearlo como una sustitución directa de personas. Los estudios más rigurosos apuntan a algo más matizado: la IA automatiza tareas, no roles.

En un proceso de concesión de préstamos, por ejemplo, hay tareas rutinarias que una persona realiza de forma repetitiva — extracción de datos, validación documental, cotejo de información — y tareas que requieren criterio humano: análisis de excepciones, decisiones sobre casos complejos, comunicación con el cliente en situaciones delicadas.

Automatizar las primeras no elimina el rol. Lo transforma. La persona deja de hacer lo que una máquina puede hacer más rápido y con menos errores, y se enfoca en lo que aporta valor real. El resultado en operaciones reales es significativo: reducciones de hasta un 80% en tiempos de proceso y ahorros de alrededor del 50% frente a un BPO tradicional sin tecnología. No por eliminar equipos, sino por eliminar fricciones.

Qué preguntar antes de elegir proveedor Para un director de operaciones o un CTO que esté evaluando proveedores de servicios externalizados para procesos críticos — gestión de siniestros, reclamaciones bancarias, concesión de crédito — hay una forma sencilla de distinguir quién tiene tecnología real y quién sigue vendiendo personas con otra etiqueta.

La primera pregunta es si el proveedor cobra por persona o por resultado. Si la respuesta es por persona, los incentivos siguen desalineados. La segunda es si puede escalar sin que el coste escale proporcionalmente. Si cada incremento de volumen requiere contratar a alguien más, no hay tecnología de fondo. La tercera es qué métricas de SLA garantiza sobre el resultado final, no sobre la actividad intermedia. Y la cuarta, a menudo olvidada, es si la tecnología es propia o depende de terceros que no controla. Cuando algo falla en un proceso crítico a las tres de la madrugada, la diferencia entre tecnología propia y un stack de terceros integrados se nota.

Los BPOs que no puedan responder con solidez a estas preguntas no van a desaparecer de un día para otro. Pero van a perder terreno frente a proveedores que combinan personas y tecnología para ofrecer el servicio con la economía del software.

Services as Software en la práctica El concepto de Services as Software no es una teoría. Es un modelo que ya funciona en procesos críticos de banca y seguros: procesamiento de siniestros, onboarding de clientes, concesión de crédito, gestión de reclamaciones. Procesos donde el volumen es alto, la precisión es innegociable y los tiempos de respuesta impactan directamente en la experiencia del cliente.

En Serimag llevamos años construyendo este modelo. Tecnología propia de extracción y procesamiento documental, equipos especializados que aportan criterio donde la tecnología no llega (humans in the loop), y un compromiso con métricas de resultado, no con conteos de personas. Porque al final, lo que importa no es cuántas personas trabajan en tu proceso. Lo que importa es que el proceso garantiza resultados.