Gestión de Incidencias Courier con IA: Escenario y Arquitectura

La respuesta corta: un agente que elige entre cuatro acciones, no un chatbot que improvisa

La gestión de incidencias courier con IA funciona cuando un agente revisa cada 15 minutos los envíos con problema (cliente ausente, dirección errada, reprogramación pedida o demora) y, para cada uno, elige entre cuatro acciones cerradas: contactar al cliente por WhatsApp, reprogramar, escalar a un supervisor o esperar. El modelo devuelve probabilidades y un nivel de confianza; el código decide si esa respuesta se ejecuta, se descarta o pasa a una persona.

Es un escenario ilustrativo de Latech (septiembre de 2026), no un cliente real. La arquitectura sí es real: viene de Jev Lab, nuestro laboratorio interno de paper trading sin dinero real, donde un agente decide en ciclos fijos sobre datos en vivo, con límites duros, umbral de confianza y cada decisión guardada. Con su costo de referencia, la IA cuesta unos 3 centavos de dólar por cada 1,000 decisiones (estimación, cuenta más abajo).

El escenario: una courier de Lima con incidencias que se enfrían

Imagina una empresa de última milla en Lima que entrega para e-commerce y clientes corporativos con motorizados. Cada incidencia queda en su ERP de mensajería, pero resolverla depende de un coordinador que revisa la lista, escribe por WhatsApp uno por uno y decide a ojo qué reprogramar. En hora punta la cola crece y las incidencias se enfrían: el cliente deja de responder, la ventana se cierra y el envío vuelve a base.

El agente no reemplaza al coordinador: ordena la cola, resuelve lo claro, deja constancia y le entrega a la persona solo lo ambiguo o delicado. La cadencia de 15 minutos es un supuesto de diseño.

La condición previa son estados confiables. Latech construyó el ERP de mensajería de PITS Courier (órdenes, repartidores, estados, tracking y panel administrativo); PITS no es el cliente de este escenario, pero ese tipo de sistema es la base que el agente necesita.

Qué datos necesita el agente y cuáles se calculan en código

El modelo no debería leer el historial crudo del envío. En Jev Lab, durante 763 ciclos el agente nunca salió de “mantener” mientras veía precios crudos minuto a minuto; con variables ya calculadas en código empezó a diferenciar casos. En la courier, el código prepara un resumen compacto por envío y el modelo solo evalúa.

• Estado del envío, tipo de incidencia e intentos que quedan antes de devolver al remitente, leídos del ERP.
• Ventana horaria comprometida y minutos que faltan para que se cierre, calculados en código.
• Antigüedad del último evento (escaneo, GPS o cambio de estado), para saber si el dato sigue vigente.
• Historial del cliente: si respondió antes por WhatsApp, cuántas veces reprogramó y en qué franja suele recibir.
• Capacidad de reparto del día siguiente por zona y condiciones del remitente (contra entrega, valor declarado, SLA).
• Consentimiento y canal: si el destinatario tiene un número válido y aceptó recibir avisos por WhatsApp.

Cómo decide: una pregunta cerrada por envío y un umbral de confianza

En cada ciclo el sistema arma una pregunta cerrada por envío: “¿Qué acción corresponde: contactar, reprogramar, escalar o esperar?”. Varias preguntas viajan en una sola solicitud, como en Jev Lab, donde una solicitud llegó a llevar 12. La respuesta no es texto libre: son probabilidades sobre las cuatro opciones y una medida de confianza.

Un ejemplo ilustrativo: contactar 0.62, reprogramar 0.21, escalar 0.12 y esperar 0.05, con confianza 0.55. Con un umbral de 0.7, el valor que usa Jev Lab, esa decisión va a la cola del coordinador con las probabilidades a la vista. En el laboratorio, en un ciclo donde el modelo se inclinó a comprar cuatro activos, solo uno superó el umbral.

Un punto clave: el modelo elige la acción, no redacta el mensaje. Según la documentación de precios de Meta, las plantillas son el único tipo de mensaje que una empresa puede enviar fuera de la ventana de atención de 24 horas. El agente escoge la plantilla aprobada y el sistema la completa con los datos del envío.

Guardrails y aprobación humana: lo que el código no deja pasar

Los guardrails viven en código, no en el prompt: si el modelo se equivoca o devuelve algo inválido, eso no llega al cliente. Los valores numéricos de la lista son supuestos de diseño, salvo el umbral de 0.7, que viene de Jev Lab.

Hay además un motivo normativo. Según El Peruano (11 de septiembre de 2026), obligaciones generales del reglamento de la Ley 31814, como la supervisión humana, la transparencia y la rendición de cuentas, ya están vigentes para el sector privado; las específicas llegan por sectores en un plazo máximo de cuatro años.

• Dato vencido, no hay decisión: si el último evento tiene más de 30 minutos (supuesto de diseño), el envío se salta el ciclo. Jev Lab hace lo mismo con cotizaciones de más de 90 segundos.
• Tope de contactos: máximo 2 mensajes automáticos por envío al día y solo entre 8:00 y 20:00 (supuesto de diseño).
• Reprogramar solo si el ERP confirma cupo en la zona. Confianza bajo 0.7: la decisión pasa al coordinador.
• Aprobación humana sobre umbral de negocio: contra entrega, valor declarado alto, clientes con SLA o tercer intento fallido van siempre a un supervisor.
• Respuesta inválida, cero acción: si falta un envío, aparece una opción inexistente o las probabilidades no cuadran, se rechaza y se guarda. En Jev Lab una respuesta rechazada igual consumió 8,943 tokens: se paga aunque no sirva.
• Avisos sin promociones: según Meta, una plantilla que mezcla una actualización de pedido con una promoción se clasifica como marketing. El aviso de incidencia va solo.
• Auditoría: se guardan entrada, pregunta, probabilidades, regla aplicada, aprobador y costo. Cada ciclo reserva su turno antes de llamar al modelo, así un reinicio no duplica mensajes.

Benchmark: reglas fijas, agente con IA o equipo manual

La comparación honesta es contra reglas fijas (if/else) y contra el equipo trabajando a mano. Donde no hay un número verificado usamos calificaciones cualitativas; los plazos son rangos típicos, no una promesa.

Si tus incidencias se resuelven con cinco reglas estables, empieza por las reglas. El agente se justifica cuando se cruzan muchas señales y el equipo ya no alcanza a revisar todo a tiempo. Incluso ahí las reglas siguen: son los guardrails.

Cuánto cuesta la IA por decisión: la cuenta a la vista

En Jev Lab, una solicitud con 12 preguntas consumió unos 8,950 tokens de entrada, y el laboratorio estima el costo con USD 0.042 por millón de tokens de entrada. Es una estimación, no una factura: excluye tokens de salida, hosting y solicitudes fallidas. Los volúmenes son supuestos de diseño, igual que asumir que cada envío pesa lo mismo que cada activo del laboratorio.

El resultado de la tabla, unos USD 0.018 al día, sería USD 1.80 con un modelo 100 veces más caro por token (hipotético). El costo a vigilar está en otro lado: los mensajes de WhatsApp y las horas de supervisión. Según Meta, desde el 1 de octubre de 2026 se cobran también los mensajes de servicio (con 1,000 gratis al mes por número) y suben las tarifas de utility para Perú.

Plan típico de implementación en 4 a 6 semanas

Así lo armaríamos sobre un ERP courier existente. Es un plan típico, no una promesa: el plazo depende sobre todo de la calidad de los estados del ERP y de la aprobación de plantillas por Meta.

1. Semana 1, diagnóstico: mapear tipos de incidencia y estados del ERP, definir las cuatro acciones y quién aprueba qué, y medir la calidad de las marcas de tiempo.
2. Semana 2, datos: variables en código (minutos al cierre de la ventana, intentos restantes, historial), regla de dato vencido e integración con el ERP.
3. Semana 3, decisión: pregunta cerrada, validación de respuestas, guardrails, auditoría y medición de tokens. En paralelo, las plantillas de WhatsApp van a aprobación.
4. Semana 4, modo sombra: el agente propone y el coordinador decide. Comparas ambas decisiones sin tocar al cliente.
5. Semanas 5 y 6, activación gradual: primero un tipo de incidencia (por ejemplo, cliente ausente), con aprobación humana sobre umbral y una revisión semanal de las decisiones escaladas.