La carroza que todavía no ha salido: cómo detectar con IA y MCP el retiro del fallecido que se atrasa

El retiro del fallecido es el primer compromiso que una funeraria cumple o incumple ante la familia, y es el tramo del servicio con menos control. Un retiro atrasado casi nunca aparece como alerta, porque el atraso más frecuente no es el traslado que tarda, sino el que todavía no ha salido. Este caso de uso muestra cómo un asistente de IA conectado al ERP por SFUN MCP revisa cada pocos minutos las recogidas programadas, separa las que ya deberían estar en ruta, reúne la evidencia y le propone a la coordinación a quién llamar y qué vehículo reasignar. La decisión sigue siendo de una persona.

Está escrito para la gerencia de operaciones y la dirección de servicio de un grupo funerario con varias sedes, flota propia o contratada y atención las 24 horas. Sigue el formato de los casos de este blog: problema, datos, pasos, bucle de mejora, límites, indicadores y hoja de ruta. Dice con claridad qué hace hoy el producto y qué no.

1. El problema de negocio: el atraso que no se ve

Son las 3:40 de la madrugada. La línea de atención recibió el aviso a las 2:05, el asesor abrió el servicio, prometió a la familia que la carroza llegaría al hospital «en unos cuarenta minutos» y programó la recogida para las 2:45. El conductor de turno estaba terminando otro traslado al otro lado de la ciudad. Nadie reasignó. A las 3:40 la familia sigue en el pasillo, el hospital pregunta cuándo se desocupa el espacio y la coordinación de la sede ve una pantalla sin una sola alerta.

El costo no está en la factura de ese servicio. Está en tres lugares que la dirección rara vez mide juntos:

• La familia. Es el primer contacto físico con la funeraria y ocurre en el peor momento. Una espera larga sin información es lo que más se recuerda y lo que más se cuenta.
• La institución. Hospitales, clínicas y hogares geriátricos recomiendan o dejan de recomendar. Un retiro que tarda ocupa un espacio que necesitan y deja una mala referencia con quien más servicios puede remitir.
• La operación. El retiro que sale tarde corre toda la cadena: preparación, sala, velación. Y el conductor que llega cuando el certificado aún no está firmado pierde una hora que le hacía falta a otro servicio.

A escala, el problema deja de ser anecdótico. Un grupo con cinco sedes y cuarenta servicios al día tiene cuarenta retiros iniciales, buena parte de noche, con turnos reducidos. Si uno de cada diez sale tarde, son cuatro familias al día. La guía de gestión de traslados y flota explica el ciclo completo; aquí nos quedamos con el primer tramo.

Por qué la pantalla no lo muestra

En SFUN, cada traslado tiene una hora de inicio, una hora de fin y un estado: Pendiente, En proceso, Terminado o Cancelado. La consola de servicios marca un traslado como vencido cuando su hora de fin ya pasó y no está terminado ni cancelado. Es una regla razonable para un traslado en curso. Pero la recogida que nadie ha tomado suele no tener hora de fin, y entonces no entra en el contador de vencidos aunque lleve una hora de atraso. Además, el traslado guarda una sola hora de inicio: si alguien la corrige para «ponerla al día», la hora prometida a la familia se pierde.

2. Qué datos del ERP intervienen

Todo lo que el caso necesita ya está en el módulo de servicios funerarios. No hay que crear nada para empezar.

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

SFUN MCP conecta un asistente de inteligencia artificial con el ERP usando los permisos del usuario que lo autoriza. Para este caso basta la lectura: el asistente consulta traslados, servicios, fallecidos, conductores y vehículos, y escribe solo un aviso interno. Lo usa la coordinación de servicio de cada sede y, en consolidado, la gerencia de operaciones.

Paso 0: escribir qué es un retiro atrasado

Antes de conectar nada, la dirección fija la regla por escrito. Sin ella, cada coordinador y cada asistente la interpretan distinto.

Los 30 minutos son un punto de partida, no una norma. Una sede urbana con flota propia puede trabajar con 20; una sede que cubre municipios a dos horas necesita otra cifra. Lo que no cambia es que el umbral está escrito y es el mismo para todos los turnos.

Paso 1: la consulta que la consola no hace

El asistente pide al ERP los traslados en estado Pendiente cuya hora de inicio es anterior a este momento, y los que empiezan en los próximos 30 minutos sin vehículo o sin conductor. Después cruza cada uno con la tabla de traslados del servicio para quedarse con los de tipo recogida de cuerpo. Dos precauciones salen de cómo está construido el producto:

• La hora puede estar solo en el servicio. Cuando el servicio se confirma, SFUN crea un traslado por cada fila de la tabla, pero no copia la hora de la fila al traslado. Si nadie la digitó después, el traslado no tiene hora. El asistente debe leer la hora en los dos lugares y avisar cuando una recogida no tiene ninguna: esa también es una alerta.
• Las listas vienen paginadas. Cada consulta devuelve como máximo 50 documentos. Para un grupo grande, la consulta se hace por sede o se guarda como un reporte.

Paso 2: la evidencia de cada caso

Por cada recogida atrasada o en riesgo, el asistente arma una ficha corta con datos que ya están en el ERP: sede, minutos de atraso, dónde murió la persona y, si fue en una clínica registrada, su teléfono; si hay vehículo y conductor asignados y en qué estado están; si el certificado de defunción está registrado, y quién creó el servicio. No incluye el nombre del fallecido ni el de la familia en el aviso: basta el número del servicio.

Paso 3: la propuesta de reasignación

Con el estado de los conductores y de los vehículos, el asistente propone hasta dos opciones: un conductor libre de la misma sede con un vehículo libre, o el conductor cuyo traslado en curso termina antes. Donde está activo el control de reserva de flota, SFUN ya avisa o bloquea cuando una carroza o un conductor quedan asignados a dos servicios dentro de una ventana de dos horas; la propuesta debe respetar esa misma ventana. El asistente no asigna: muestra la opción y por qué.

Paso 4: el aviso, a quién y por dónde

SFUN MCP tiene tres acciones para avisar dentro de la organización: un mensaje por el chat interno, una tarea asignada a un usuario y un correo. El caso usa las dos primeras: mensaje al coordinador de turno de la sede con la lista ordenada por atraso, y una tarea por cada recogida con más de una hora, para que quede quién la tomó. La llamada al hospital y la llamada a la familia las hace una persona.

La frecuencia la pone el cliente de IA que la funeraria conecta: SFUN MCP no ejecuta consultas por su cuenta. En la práctica se programa una revisión cada 15 minutos de noche, que es cuando hay menos ojos sobre la pantalla, y el coordinador puede pedirla a demanda con una frase: «¿qué recogidas deberían haber salido ya?».

4. El bucle de mejora continua

• Cada turno: la lista de recogidas atrasadas y en riesgo, y qué se hizo con cada una.
• Cada mañana: el coordinador clasifica las de la noche por causa: sin conductor disponible, documento pendiente, institución que no entregó, hora mal digitada, aviso que no llegó a la sede. Cinco causas bastan.
• Cada semana: operaciones mira la causa dominante por sede y por franja. Si la mayoría es «sin conductor entre las 0:00 y las 5:00», el problema es de turnos y se trata con la guía de capacidad de flota por sede. Si es «documento pendiente» en una clínica concreta, es una conversación con esa clínica.
• Cada mes: se ajusta el umbral por sede y se revisan las falsas alarmas. Una alerta que el coordinador ignora tres noches seguidas está mal calibrada, como explica el caso de servicios en riesgo.

5. Gobierno y límites: lo que el asistente nunca hace

• No cambia la hora programada. Corregir la hora para que el atraso desaparezca borra la única evidencia del compromiso. Si hay que reprogramar, lo hace una persona y deja el motivo.
• No asigna ni reasigna vehículo o conductor. Propone. El coordinador conoce lo que el dato no dice: quién acaba de doblar turno, qué carroza tiene una falla.
• No escribe a la familia ni a la institución. La noticia de un atraso se da con voz humana, y los datos del fallecido no salen del ERP en un mensaje automático.
• No cierra ni cancela traslados. Un retiro terminado se marca terminado cuando alguien confirma que el cuerpo fue entregado.
• Trabaja con los permisos del usuario. El asistente ve lo mismo que vería esa persona en el ERP. Para una primera etapa conviene un usuario con lectura sobre servicios y traslados y sin escritura; SFUN MCP admite además un modo de solo lectura para todo el sitio.

6. KPIs para saber si funcionó

El segundo indicador depende de que el cambio de estado a En proceso se haga cuando el vehículo sale, no al final del turno. Si la sede actualiza los estados en bloque, lo primero que revela el caso es ese hábito, y corregirlo es parte del resultado.

7. Hoja de ruta de adopción y errores comunes

• Semana 1: una sede, solo lectura. Escribir la regla del paso 0, correr la consulta a demanda y medir la línea base sin avisar a nadie. Corregir las recogidas sin hora.
• Mes 1: revisión programada de noche en esa sede, con aviso por chat interno al coordinador. Clasificación diaria de causas. Ajuste del umbral.
• Trimestre 1: todas las sedes, tareas para los casos de más de una hora, tablero semanal para operaciones y primera conversación con las instituciones que más atrasos por documento concentran.

Los errores que más se repiten: avisar de todo desde el primer día y quemar la atención del coordinador; medir al conductor en lugar de medir la asignación; dejar que el asistente «arregle» la hora; y confundir este control con el de traslados duplicados, que es el problema contrario: allí salen dos carrozas, aquí no sale ninguna.

Lo que falta construir: la hoja de ruta de producto

Para que el caso no dependa de una consulta externa, estas piezas no existen hoy en SFUN y se describen como hoja de ruta, no como función disponible:

• Hora del aviso, hora prometida y horas reales de salida, llegada y entrega como campos propios, separados de la hora programada.
• Que el semáforo de la consola marque también la recogida Pendiente cuya hora de inicio pasó.
• Un reporte de recogidas pendientes y atrasadas por sede.
• Catálogo de instituciones con tipo (hospital, morgue, medicina legal), contacto y horarios de entrega.
• Aviso automático de atraso al coordinador. Hoy existe, como opción que cada compañía activa, un aviso por correo al conductor cuando se le asigna una recogida; avisa una vez y no vuelve a avisar si se atrasa.

De dónde sale el patrón: logística, salud y servicio en campo

El retiro que no arranca es, en otros sectores, la recolección fallida. El transporte de carga lleva más de un año poniendo agentes de IA justo en ese punto, y de ahí sale el patrón de este caso.

• Carga terrestre. C.H. Robinson informó el 26 de enero de 2026 que usa dos agentes para las recolecciones fallidas de carga fraccionada: uno llama al transportista para saber qué pasó y otro decide el paso siguiente. Según la nota de la compañía, el 95 % de las verificaciones de recolecciones fallidas quedó automatizado y los viajes de retorno innecesarios bajaron 42 %. Son cifras reportadas por la propia empresa, sin línea base ni periodo declarados, y la nota no describe revisión humana.
• Carga marítima. project44 presentó el 2 de marzo de 2026 un agente para contenedores que la naviera deja fuera del buque: detecta el caso, confirma con la naviera, reúne las alternativas y las deja en una tarea para el analista. La nota lo dice sin rodeos: los analistas conservan toda la autoridad sobre la decisión de reprogramar. Es el diseño que seguimos aquí.
• Flotas. Samsara anunció en septiembre de 2026 un servidor MCP de solo lectura sobre los datos de su plataforma de flotas, que respeta los permisos de cada usuario: el asistente no ve lo que la persona no puede ver. Es el mismo principio con el que trabaja SFUN MCP.

La traducción al sector funerario es directa: la recolección fallida es la recogida que sigue Pendiente; la llamada al transportista es la consulta del estado del conductor y del vehículo; la tarea para el analista es el aviso al coordinador de turno. La diferencia es de fondo y no de forma: aquí no se mueve una carga, se acompaña a una familia, y por eso el asistente no llama a nadie fuera de la organización.

Preguntas frecuentes

¿Cómo se detecta un retiro del fallecido que va atrasado?

Buscando las recogidas de cuerpo que siguen en estado Pendiente después de su hora programada, y las que están a menos de 30 minutos de su hora sin vehículo ni conductor. La alerta habitual de traslados vencidos no las incluye, porque se basa en la hora de fin y una recogida que no ha arrancado no la tiene.

¿SFUN avisa solo cuando una recogida se atrasa?

Hoy no. La consola de servicios marca los traslados vencidos por hora de fin y existe un aviso opcional por correo al conductor cuando se le asigna una recogida. El aviso de atraso descrito aquí se arma con un asistente de IA conectado por SFUN MCP, que consulta el ERP y escribe al coordinador por el chat interno o le crea una tarea.

¿La IA puede reasignar la carroza o llamar al hospital?

No en este caso, por diseño. El asistente propone un conductor y un vehículo disponibles y explica por qué; la reasignación, la llamada a la institución y la conversación con la familia las hace una persona. Para impedir técnicamente que modifique traslados, se conecta con un usuario sin permiso de escritura.

¿Qué pasa cuando el atraso es del hospital o de medicina legal?

Se clasifica aparte. Si el certificado de defunción no está registrado o la institución aún no entrega, mover un vehículo no resuelve nada y sí le quita capacidad a otro servicio. El valor está en contarlos por institución: tres semanas de datos bastan para sentarse con una clínica con cifras propias.

¿Esto aplica igual en todos los países de Latinoamérica?

El control operativo es el mismo. Cambian los documentos que habilitan el retiro, la autoridad que interviene en las muertes violentas o en vía pública y los plazos sanitarios de cada país, que la funeraria debe configurar según su norma local. Por eso la regla del paso 0 deja esos casos fuera del cálculo de atraso.

En resumen

• El atraso más común del retiro inicial es el traslado que no ha salido, y la alerta por hora de fin no lo ve.
• Los datos para detectarlo ya están en el ERP: tipo de tramo, hora, estado, vehículo, conductor, lugar de fallecimiento y certificado.
• Con SFUN MCP, un asistente consulta, ordena por atraso, propone quién puede tomarlo y avisa al coordinador. No asigna, no cambia horas y no habla con la familia.
• Se mide con seis indicadores y empieza en una sede, en solo lectura, con dos semanas de línea base.

Fuentes de este artículo

• C.H. Robinson, nota de prensa del 26 de enero de 2026 sobre agentes de IA para recolecciones fallidas de carga fraccionada. Cifras reportadas por la compañía.
• project44, nota de prensa del 2 de marzo de 2026 sobre su agente de excepciones marítimas. Cifras de despliegues iniciales reportadas por el proveedor; no se usan aquí.
• Samsara, presentación de su servidor MCP (septiembre de 2026).
• Ministerio de Salud y Protección Social de Colombia, Resolución 717 del 21 de abril de 2026, artículo 20.
• Producto: lo descrito de SFUN se verificó en el código de la versión principal el 7 de octubre de 2026. Las piezas que no existen figuran como hoja de ruta.
• No encontramos una estadística pública y citable sobre tiempos de retiro de cuerpos en hospitales de Latinoamérica; por eso el artículo no da ninguna y propone medir la propia.