El chatbot funerario que mejora todos los días: el bucle de mejora continua con MCP

Un grupo funerario grande lanza su chatbot de WhatsApp, celebra el hito y, seis meses después, descubre que la tasa de escalado a un asesor humano es prácticamente la misma que el primer mes. El bot “funciona” —no se cae, responde rápido, no hay quejas formales—, pero no aprendió nada: sigue fallando en las mismas cinco preguntas, sigue perdiendo las mismas oportunidades comerciales y sigue entregando al equipo humano conversaciones sin el contexto que la familia ya escribió tres veces. El problema no fue la tecnología. Fue tratar el chatbot como un proyecto que termina el día del lanzamiento, en lugar de como un producto vivo que se mejora todos los días con evidencia.

Este artículo desarrolla ese caso de uso concreto para la dirección de un grupo funerario: cómo montar un chatbot sobre los datos reales de tu ERP y, sobre todo, cómo construir el bucle de mejora continua que lo hace mejor cada semana, usando MCP para que la propia inteligencia artificial lea las conversaciones, los escalados y las ejecuciones fallidas de la operación y te diga qué corregir. No es teoría de MCP: es la rutina diaria, quién la ejecuta, qué se mira, qué se cambia y cómo se mide si sirvió. Al final encontrarás el gobierno que un contexto de duelo exige, los KPIs con línea base y meta, y una hoja de ruta por fases.

El problema de negocio y cuánto cuesta hoy

En una funeraria a escala, WhatsApp es el primer punto de contacto real: por ahí entra el aviso de un fallecimiento a las tres de la mañana, la duda sobre la cobertura de un plan, la solicitud de un certificado, el reclamo por un cobro y la consulta del asesor que está en campo. Un bot que atiende ese volumen mal —no que lo atienda poco, sino que lo atienda mal— genera costos que casi nunca aparecen en un tablero:

• Trabajo humano duplicado: la conversación llega al asesor sin los datos que la familia ya entregó, y el equipo vuelve a preguntar lo mismo. Cada escalado mal preparado cuesta minutos de un colaborador calificado y paciencia de una familia en duelo.
• Servicios que se atrasan: si el bot no reconoce un aviso de fallecimiento y lo trata como una consulta comercial, la activación del servicio pierde minutos críticos. Es el único error del sector que no se puede compensar después.
• Cartera que no se recupera: conversaciones de cobro de cartera que mueren sin acuerdo porque el bot no supo dar el saldo real ni generar el medio de pago, y nadie las retomó.
• Oportunidades comerciales perdidas: interesados en un plan de previsión que preguntaron precio, no obtuvieron respuesta útil y nunca fueron marcados como prospecto para que un asesor los llamara.
• Costo de IA sin control: un bot mal diseñado consume tokens en conversaciones que no resuelve. Se paga dos veces: el modelo y la persona que después arregla el caso.
• Desgaste de confianza interna: cuando el equipo de servicio percibe que “el bot estorba”, empieza a saltárselo, y la inversión se convierte en un adorno del sitio web.

Ninguno de estos costos se corrige con un modelo más grande. Se corrigen con un ciclo corto de observación y ajuste. Y aquí conviene mirar lo que ya pasó en otros sectores.

La homologación al sector es casi literal. Lo que en una fintech es “el reclamo por un cargo no reconocido que el bot cerró sin resolver”, en una funeraria es “el aviso de fallecimiento que el bot trató como una consulta de precios”. Y lo que en un e-commerce es una devolución mal gestionada, aquí es una familia que tuvo que explicar dos veces que su padre acaba de morir. Por eso el bucle de mejora no es un lujo de madurez: es el control de riesgo del canal.

Qué datos del ERP intervienen

Un bucle de mejora sirve solo si se alimenta de evidencia estructurada. La ventaja de montar la atención sobre el mismo ERP que opera la funeraria es que esa evidencia ya existe y es consultable: no hay que instrumentar nada nuevo para saber qué hizo el bot, cuánto costó, dónde falló y qué pasó después con esa familia. Estos son los datos que intervienen en el caso:

Ese último punto es el que convierte el ejercicio en ingeniería y no en opinión: como cada conversación guarda la versión del bot que la atendió, puedes comparar el comportamiento antes y después de un cambio en lugar de discutir si “se siente mejor”. Y como en SFUN se publica una versión concreta, revertir es publicar de nuevo la anterior: la marcha atrás no es un rescate de emergencia, es una operación normal.

Cómo se arma el caso con MCP, paso a paso

El MCP (Model Context Protocol) es el estándar que permite conectar la inteligencia artificial que prefiera tu equipo con el ERP para consultar y operar en lenguaje natural, con los permisos del usuario que autorizó la conexión. En este caso de uso cumple un papel muy específico: no atiende a las familias —eso lo hace el bot— sino que audita al bot. Es el analista que lee todos los días lo que pasó y produce la lista de mejoras.

1. Monta el bot sobre datos reales, no sobre un guion estático. El chatbot debe poder consultar el ERP —estado del contrato, saldo de cartera, servicios, planes— y ejecutar acciones acotadas de la conversación (etiquetar, dejar nota, transferir a un asesor, cerrar). Un bot que solo repite un guion no puede resolver: solo puede entretener.
2. Define desde el día uno qué NO resuelve. Escribe la lista corta de casos que siempre escalan —aviso de fallecimiento, reclamo, cualquier señal de angustia, temas legales— y haz que el bot los detecte y transfiera con resumen. Un bot funerario se juzga tanto por lo que responde como por lo que sabe no responder.
3. Instrumenta el escalado con etiquetas normalizadas. Como se explicó arriba: una taxonomía corta, estable y aplicada por el propio flujo. Diez etiquetas bien elegidas valen más que cien improvisadas.
4. Conecta el MCP con un usuario de análisis. Autoriza la conexión con un usuario cuyo rol permita leer la bandeja y las ejecuciones, y nada más. Ese usuario es el que usará la dirección o el líder del canal para preguntar en lenguaje natural.
5. Pide el diagnóstico en lenguaje natural. “Dame las conversaciones de ayer que terminaron escaladas, agrupadas por etiqueta de motivo, con el mensaje de la familia que precedió al escalado.” La IA lee los datos reales y devuelve el patrón, no una impresión.
6. Convierte el diagnóstico en un reporte guardado. Cuando una consulta demuestra ser útil, pídele a la IA que la deje como reporte reutilizable en el sistema, para que cada mañana se ejecute igual y el repaso no dependa de cómo esté redactada la pregunta.
7. Corrige el flujo y publica una versión nueva. Cada ajuste —un nodo nuevo, una respuesta mejor, una consulta al ERP que faltaba— se publica como versión. Anota qué cambió y qué esperas que mejore.
8. Verifica el efecto contra la versión anterior. Una semana después, la misma pregunta al MCP: ¿bajó ese motivo de escalado? ¿Bajaron las fallas técnicas? ¿Se mantuvo el costo por conversación? Si no mejoró, revierte y prueba otra hipótesis.

Nota importante sobre el alcance: en SFUN el MCP lee y analiza la bandeja de conversaciones y las ejecuciones del bot con los permisos del usuario, pero no opera la mesa de agentes —responderle a una familia, asignar o escalar una conversación desde la IA está deliberadamente deshabilitado por seguridad—. Es una restricción sana y conviene que la conozcas antes de diseñar el proceso: la IA te dice qué arreglar; los cambios los publica una persona y las respuestas a las familias salen del bot o del asesor en el canal de atención, nunca de un analista improvisado con acceso al MCP.

El bucle de mejora continua: qué se revisa cada día y cada semana

Aquí está el corazón del caso. El bucle no exige un equipo de datos: exige una persona responsable, quince minutos diarios y una hora semanal. La forma más común de fracasar es hacerlo “cuando haya tiempo”.

El repaso diario tiene una regla que conviene proteger: se leen conversaciones completas, no resúmenes. El agregado te dice cuántos escalados hubo; solo el diálogo real te dice que la familia escribió “mi papá falleció” y el bot respondió con el listado de planes. Ese hallazgo, uno solo, justifica el bucle entero de un mes.

Gobierno y límites: lo que nunca se automatiza

El sector funerario no admite el estándar de riesgo de un e-commerce. Un error de tono en el peor día de la vida de una familia no se compensa con un cupón. Por eso el caso exige un gobierno explícito, escrito y auditado, no un “vamos viendo”:

• Alcance por rol, no por confianza: el usuario con el que se conecta el MCP para analizar la calidad del bot debe tener permisos de lectura sobre la bandeja y las ejecuciones, y nada más. El sistema garantiza que la IA no puede hacer nada que ese usuario no pueda hacer por sí mismo, y cada operación queda registrada.
• Separación entre analizar y responder: el análisis por MCP no toca la conversación con la familia. Quien responde es el bot en producción o el asesor humano en la bandeja.
• Datos sensibles del doliente: los datos del fallecido y de la familia se tratan con el mismo criterio que un historial clínico. En el repaso diario se leen conversaciones para corregir el flujo, no para perfilar personas, y las evidencias que se compartan fuera del sistema —capturas en un acta, ejemplos en una capacitación— deben ir con los datos identificables cubiertos.
• Nunca se automatiza: confirmar o comunicar un fallecimiento, negar una cobertura o resolver un reclamo, cerrar un acuerdo de pago que modifique un contrato, cualquier respuesta ante señales de angustia o crisis emocional, y la comunicación con autoridades. Todo eso escala a una persona, siempre.
• Declaración de identidad: el bot se identifica como asistente automático y ofrece paso a una persona en cualquier momento. En el contexto del duelo, la transparencia no resta: construye la confianza que sostiene el canal.
• Revisión humana del cambio: ninguna versión llega a producción porque “la IA lo sugirió”. La IA propone el diagnóstico; una persona decide, publica y firma el cambio.
• Marcha atrás ensayada: el equipo debe haber revertido a una versión anterior al menos una vez, en frío, antes de necesitarlo en caliente.

KPIs: línea base y meta

Estos son los indicadores que hacen medible el bucle. Las metas que aparecen abajo son referencias de arranque para una operación funeraria a escala, no promesas: lo que importa es que cada organización fije su propia línea base en el primer mes y mida el movimiento contra ella, no contra el promedio de nadie.

Hoja de ruta de adopción

Semana 1: instrumentar antes de optimizar

• Definir la lista corta de casos que el bot nunca resuelve solo y verificar que los detecta y escala con resumen.
• Implementar la taxonomía de etiquetas de motivo de escalado y confirmar que el flujo las aplica.
• Configurar la política de SLA de primera respuesta del canal y el presupuesto de IA por turno, día y mes.
• Conectar el MCP con un usuario de análisis de solo lectura y correr las cinco preguntas de diagnóstico.
• Nombrar al responsable del bucle. Sin un nombre propio, el bucle no existe.

Mes 1: línea base y primeras versiones

• Establecer la línea base de todos los KPIs de la tabla anterior. No se optimiza lo que no se midió primero.
• Sostener el repaso diario de 15 minutos sin excepciones y publicar una versión nueva cada semana.
• Dejar guardados los reportes de diagnóstico para que el repaso no dependa de cómo se redacte la pregunta.
• Ensayar una reversión a una versión anterior en frío, con el equipo mirando.
• Revisar con Cumplimiento el tratamiento de datos personales del canal según la normativa del país.

Trimestre 1: ampliar alcance con evidencia

• Ampliar el alcance del bot solo a los temas donde ya demostró resolver bien: primero calidad, después cobertura.
• Sumar el segundo caso de uso del canal (cobranza, atención telefónica con agentes de voz o recepción de solicitudes de servicio) con su propio bucle.
• Empezar a construir el banco de casos de prueba: guarda las conversaciones que fallaron y verifica cada versión nueva contra ellas antes de publicar.
• Llevar el reporte del canal al comité de operaciones como un indicador de servicio más, no como un proyecto de tecnología.
• Documentar qué se automatizó, qué se decidió no automatizar y por qué. Ese documento vale más que el flujo.

Errores comunes que hacen fracasar el caso

• Lanzar sin taxonomía de motivos. A los tres meses tendrás miles de conversaciones y ninguna forma barata de saber por qué te escala el bot.
• Medir solo el promedio. Los promedios esconden exactamente los casos que más importan en este sector: los pocos, graves y silenciosos.
• Cambiar varias cosas a la vez. Si publicas cinco ajustes en una versión y el indicador se mueve, no sabrás cuál sirvió. Una hipótesis por versión.
• Delegar el repaso en quien no atiende. Quien revisa las conversaciones debe conocer la operación; un analista sin contexto funerario no distingue una respuesta correcta de una respuesta fría.
• Confundir “el bot no se cayó” con “el bot funciona”. La estabilidad técnica es el piso, no el resultado.
• Dejar el bot sin dueño. Un canal sin responsable se degrada solo, porque el mundo cambia —planes, tarifas, sedes, normativa— y el flujo no.
• Automatizar lo sensible para subir un número. Es el único error de esta lista que puede costar la reputación construida en décadas.

Preguntas frecuentes

¿Cómo se mejora un chatbot todos los días sin un equipo de datos?

Con una rutina corta y datos que ya existen. El repaso diario de 15 minutos consiste en pedirle a la IA conectada por MCP los escalados y las ejecuciones fallidas del día anterior, leer completas las tres peores conversaciones y anotar el defecto concreto. Una vez por semana, esos defectos se agrupan, se corrigen los tres de mayor impacto y se publica una versión nueva del flujo. No hace falta un equipo de datos: hace falta un responsable con nombre propio, la disciplina de no saltarse el repaso y una taxonomía de etiquetas que permita contar los motivos de escalado en lugar de intuirlos.

¿Qué es MCP y para qué sirve en la mejora de un chatbot funerario?

MCP (Model Context Protocol) es un estándar abierto que conecta la inteligencia artificial que prefiera tu equipo —Claude, Gemini, ChatGPT u otro agente— con tu ERP, para consultar y ejecutar operaciones en lenguaje natural respetando los permisos del usuario que autorizó la conexión. En este caso de uso sirve para auditar al bot: la IA lee las conversaciones, los escalados, los incumplimientos de SLA y las ejecuciones fallidas directamente de los datos reales de la operación y devuelve el diagnóstico y los patrones. Eso convierte un análisis que antes exigía exportar datos y armar hojas de cálculo en una pregunta de dos líneas que se puede hacer todos los días.

¿Cuánto tarda un chatbot funerario en dar resultados medibles?

El primer mes es de línea base: se mide cómo se comporta el canal antes de optimizarlo. Con un bucle semanal disciplinado, la mejora más visible aparece entre la cuarta y la octava semana, y se nota primero en los escalados por falla del bot —los casos que no entendía y ahora resuelve— y en las fallas técnicas repetidas. Los efectos de negocio, como la recuperación de cartera o la calidad de las solicitudes de servicio recibidas, se consolidan hacia el tercer mes. Un grupo funerario que espere resultados de negocio en la semana dos suele estar midiendo velocidad en lugar de resolución.

¿Es seguro que la inteligencia artificial lea las conversaciones con las familias?

Lo es cuando el acceso está acotado y es auditable. La conexión por MCP se autoriza con un usuario concreto y hereda sus roles y permisos: la IA no puede leer nada que esa persona no pueda leer, cada consulta queda registrada y el acceso se revoca cuando se quiera. En SFUN, además, las operaciones de la mesa de agentes —responder, asignar, escalar— están deshabilitadas desde el MCP: la IA analiza, no interviene la conversación. A eso hay que sumarle el gobierno propio de la funeraria: leer conversaciones para corregir el flujo, nunca para perfilar personas, y cubrir los datos identificables en cualquier evidencia que salga del sistema.

¿Qué indicadores debe vigilar la dirección en el canal de WhatsApp?

Cuatro, y ninguno de ellos es la tasa de automatización. Primero, los escalados por falla del bot, que deben caer sostenidamente. Segundo, el tiempo hasta el humano en casos sensibles, que nunca puede empeorar. Tercero, la reapertura de conversaciones resueltas, que es la mejor señal temprana de una mala resolución. Cuarto, el costo de IA por conversación, para asegurarse de que la calidad no se compró con gasto. La tasa de automatización se reporta, pero acompañada: sola, premia a un bot que aprendió a cerrar lo que debía escalar.