La fórmula del ROI cabe en una línea, pero esa línea no dice nada sobre lo difícil que es rellenar cada variable con datos reales cuando se trata de decidir si un proyecto de IA merece la pena. Este artículo recorre, paso a paso, cómo se resolvería ese cálculo sobre un caso construido a partir de proyectos habituales de automatización de back office: una pyme de mantenimiento industrial que automatiza la gestión de sus avisos de avería. Los detalles del caso son ilustrativos —el objetivo es mostrar el proceso, no describir un cliente concreto—, pero el proceso —línea base, piloto acotado, coste total, calidad como puerta y decisión final— es exactamente el que se aplicaría a cualquier otra empresa. Si se busca primero el marco teórico completo, conviene leer antes cómo medir el ROI de la IA en una pyme; aquí se ve ese mismo marco funcionando sobre un proceso concreto.
El ROI de un caso así no sale de multiplicar minutos ahorrados por un coste por hora. Sale de comparar un proceso completo, con sus excepciones y su revisión humana, antes y después de introducir IA —y de estar dispuestos a no escalar si los números no aguantan esa comparación—.
Por qué un caso vale más que una fórmula sola
Cualquiera puede aplicar la fórmula ROI = (beneficio neto acumulado − inversión) / inversión × 100. El problema real de una pyme no es la fórmula: es decidir qué cuenta como beneficio, qué entra en la inversión y durante cuánto tiempo hay que observar antes de fiarse del número. Un caso concreto obliga a responder esas preguntas con datos, no con supuestos optimistas. Por eso este artículo no repite la metodología general —ya publicada—, sino que la aplica, con sus dudas y sus ajustes, a un proceso que existía antes de que apareciera la IA.
El punto de partida: un proceso que no escalaba
La empresa del caso es una pyme de mantenimiento industrial de poco más de treinta empleados, con un equipo administrativo de tres personas encargado de recibir avisos de avería de clientes por correo electrónico, WhatsApp y llamada telefónica. Cada aviso debía leerse, clasificarse por urgencia y tipo de equipo, y convertirse en una orden de trabajo dentro de su gestor interno antes de asignarse a un técnico.
El volumen había crecido con la cartera de clientes, pero el equipo administrativo no. El resultado era previsible: avisos que tardaban horas en convertirse en orden de trabajo, alguna urgencia mal priorizada por acumulación de correo, y un equipo que pasaba buena parte del día haciendo trabajo repetitivo de lectura y transcripción en lugar de coordinar técnicos. La dirección quería IA, pero no quería un proyecto que sonara bien y no se pudiera defender delante de un balance.
La línea base: lo que se midió antes de decidir nada
Antes de elegir ninguna herramienta conviene medir, durante varias semanas representativas, el proceso tal y como funciona. En un caso como este, la línea base típica recoge:
- Volumen: unas cuantas decenas de avisos diarios por los tres canales.
- Tiempo medio de gestión manual: varios minutos por aviso, entre lectura, clasificación y alta en el gestor.
- Errores de priorización: una parte no desdeñable de los avisos se marca con una urgencia distinta de la que finalmente resulta correcta.
- Tiempo hasta la primera asignación a técnico: de varias horas, con picos de más de un día en momentos de mucho correo acumulado.
- Reclamaciones asociadas a demora en avisos urgentes: algunas al mes.
En el caso, esa línea base fue la referencia de toda la comparación posterior. Sin ella, cualquier comparación posterior habría sido una opinión, no una medición.
El piloto: qué se implantó y con qué límites
El diseño combinó tres piezas: un módulo de procesamiento inteligente de documentos para leer correos y adjuntos (fotos de la avería, partes en PDF o Excel que algunos clientes seguían enviando), un agente de IA para back office que clasificaba el aviso por tipo de equipo y urgencia y redactaba el borrador de la orden de trabajo, y una capa de automatización con n8n que orquestaba el flujo entre el buzón de correo, WhatsApp Business, el agente y el gestor interno.
El piloto no se lanzó directamente en producción. Siguió las fases que marca la metodología: primero en sombra, con el sistema clasificando avisos sin que nadie actuara sobre esa clasificación, para comparar sus decisiones con las que tomaba el equipo humano. Después en modo asistido, generando el borrador de orden de trabajo que una persona revisaba y confirmaba antes de que se abriera oficialmente. Solo tras varias semanas en ese modo se planteó ampliar el nivel de automatización, y solo para los tipos de aviso donde el acierto era más alto.
Los avisos por llamada telefónica se dejaron fuera del piloto desde el principio: transcribir y clasificar voz en tiempo real añadía una capa de riesgo distinta y no era necesario para demostrar el caso. Acotar el alcance fue una decisión deliberada, no una limitación técnica.
Qué entra en el coste y qué cuenta como beneficio
El coste del proyecto no se redujo a la licencia del modelo. Se sumaron todos los componentes que suelen quedarse fuera cuando alguien calcula el ROI a ojo:
| Componente | Qué incluía |
|---|---|
| Diseño e integración | Conexión con el buzón de correo, WhatsApp Business y el gestor interno. |
| Licencias y operación | Uso del modelo, orquestación en n8n y almacenamiento de los avisos procesados. |
| Revisión humana | El tiempo que el equipo administrativo dedicó a validar borradores durante el piloto asistido. |
| Formación y cambio | Sesiones para que el equipo supiera cuándo corregir el agente y cuándo confiar en él. |
En el lado del beneficio, solo se contabilizó lo que efectivamente se convirtió en algo medible: menos minutos de transcripción manual, menos avisos mal priorizados y un tiempo de primera asignación a técnico más corto. No se contó como ahorro el tiempo que, en la práctica, el equipo administrativo siguió dedicando a revisar y corregir los casos dudosos —ese tiempo restaba, no sumaba—.
Con esa forma de contar, la amortización se demuestra con meses de operación estable, no en el momento de encender el sistema. Es una diferencia importante: el retorno se demostró con meses de datos de producción, no con la promesa del piloto.
Lo que estuvo a punto de invalidar el ROI
Durante la fase en sombra apareció un problema que, de no haberse detectado, habría maquillado un ROI que en realidad no existía: el agente clasificaba con buena precisión media, pero fallaba de forma desproporcionada en un tipo concreto de avería —precisamente las de mayor urgencia, las que generaban las reclamaciones que la empresa más quería evitar—. Un promedio general de acierto habría ocultado ese fallo.
La respuesta fue tratar la calidad como puerta eliminatoria, no como un promedio a mejorar con el tiempo: ese tipo de aviso se excluyó de la automatización asistida hasta que el modelo, con más ejemplos etiquetados por el propio equipo, alcanzó un nivel de acierto que el responsable de operaciones consideró aceptable para dejar de revisarlo caso a caso. Escalar antes de resolver ese punto habría producido un ahorro de minutos y, al mismo tiempo, un coste oculto en forma de avisos urgentes mal gestionados —exactamente lo contrario de lo que se buscaba—.
El segundo riesgo fue la adopción. Al principio, parte del equipo revisaba cada borrador del agente con la misma minuciosidad que si lo hubiera escrito desde cero, lo que anulaba buena parte del ahorro de tiempo. Ese comportamiento se midió explícitamente —no se asumió que la herramienta se estaba usando bien solo porque estaba disponible— y se corrigió con sesiones cortas mostrando en qué tipos de aviso el agente ya acertaba de forma consistente.
La decisión de escalar (y lo que se dejó fuera)
La decisión de pasar de piloto a operación habitual se tomó cuando se cumplieron, a la vez, varias condiciones: la calidad en los tipos de aviso automatizados superaba el umbral que la dirección había fijado como aceptable, el tiempo de primera asignación había bajado de forma sostenida durante varias semanas seguidas —no solo en un día bueno—, el equipo administrativo usaba el borrador del agente sin revisarlo por completo en la mayoría de los casos, y el coste de operación mensual era claramente inferior al beneficio medido en tiempo liberado y reclamaciones evitadas.
No todo se escaló. Los avisos por teléfono siguieron gestionándose de forma manual, y el tipo de avería más problemático se mantuvo con revisión humana obligatoria durante más tiempo del inicialmente previsto, a la espera de más datos. Escalar solo lo que ya estaba demostrado —y dejar fuera lo que no— es parte de lo que hizo que el ROI final fuera defendible y no una cifra optimista construida antes de tener resultados de producción.
Qué se puede extrapolar a otra pyme
El proceso automatizado en este caso —avisos de avería en una empresa de mantenimiento— es específico, pero el método no lo es. Cualquier pyme con un proceso administrativo repetitivo y con volumen suficiente para justificar la inversión puede aplicar la misma secuencia:
- Medir el proceso actual antes de elegir ninguna herramienta.
- Acotar el piloto a una parte del proceso, no a todo de golpe.
- Sumar el coste total, incluida la revisión humana y la formación, no solo la licencia.
- Tratar la calidad en los casos críticos como una puerta, no como un promedio.
- Medir la adopción real, no asumir que la herramienta se usa bien porque está disponible.
- Escalar solo lo que ya está demostrado con datos de operación, no con el resultado de un piloto corto.
Un despacho profesional que automatice la clasificación de correo entrante, un comercio que use un chatbot de atención al cliente para las preguntas repetitivas, o una empresa que implante búsqueda interna sobre su propia documentación pueden seguir exactamente esta misma secuencia, cambiando solo el proceso y las métricas concretas. Pueden verse más ejemplos de aplicación por sector en la página de casos de uso de IA en empresas.
Checklist para replicar este caso
- ¿Existe un proceso con volumen suficiente y repetitivo como para justificar la inversión?
- ¿Hay línea base medida antes de tocar nada, con la misma definición que se usará después?
- ¿El piloto tiene un alcance acotado y una fase en sombra antes de actuar sobre el proceso real?
- ¿El coste total incluye integración, revisión humana, formación y operación, no solo la licencia?
- ¿Hay algún tipo de caso donde el error sea especialmente costoso, y se está tratando aparte del promedio?
- ¿Se está midiendo si el equipo usa realmente la herramienta, o solo si está disponible?
- ¿La decisión de escalar se apoya en semanas de datos de operación, o en el resultado de un piloto de pocos días?
La versión ampliada de esta lista, con más detalle en cada punto, está en el checklist fase a fase para replicar este caso.
Preguntas frecuentes
¿Qué diferencia hay entre este caso y calcular el ROI con una fórmula genérica?
La fórmula da un número; el caso muestra de dónde sale cada variable: línea base real, coste total con integración y operación incluidas, y beneficio medido después de descontar revisión y excepciones.
¿Se puede aplicar este mismo proceso a otra pyme con un caso de uso distinto?
Sí. El proceso —línea base, piloto acotado, calidad y adopción como puertas, decisión de escalar— es el mismo aunque cambie lo que se automatiza: avisos de avería, facturas, atención al cliente o cualquier otro back office repetitivo.
¿Cuánto tiempo tarda una pyme en tener un ROI fiable?
Un calendario realista sitúa la línea base y el piloto en el primer trimestre. Un ROI fiable exige operar el tiempo suficiente para observar el proceso real, no solo el resultado de un piloto controlado.
Summum IA puede diseñar la línea base, el piloto y el cuadro de ROI de un proceso concreto de tu empresa, con este mismo método: sin prometer ahorros antes de medirlos. Si el punto de partida es un proceso administrativo que no escala, puede empezarse revisando agentes de IA para back office o planteando el caso directamente en una consultoría estratégica de IA para pymes.