Triaje de soporte e-commerce
Una cola mixta se convierte en dos rutas controladas: atención rápida con contexto para consultas rutinarias y visibilidad inmediata para casos sensibles.
Nota del caso
La implementación se trató como un sistema operativo pequeño: primero visibilidad, después ownership y solo entonces automatización.
Caso de uso
Triaje de soporte e-commerce
Una cola mixta se convierte en dos rutas controladas: atención rápida con contexto para consultas rutinarias y visibilidad inmediata para casos sensibles. Un equipo ecommerce con un volumen elevado de soporte gestionaba preguntas de pedidos, reembolsos, fallos de entrega, producto y quejas en una sola cola. Cada ticket empezaba con el mismo trabajo repetitivo: leer, localizar el pedido, comprobar la política y valorar el riesgo, aunque solo una parte necesitaba atención especializada.
Resultado: Los agentes abren cada ticket con la historia del pedido, los límites de la política y la ruta recomendada ya visibles. Las consultas rutinarias avanzan por una vía de respuesta revisable y los reembolsos, quejas o fallos de entrega aparecen como excepciones antes de dañar la confianza del cliente.
Mapa del flujo
Workflow de ticket a respuesta segura
Los tickets simples reciben contexto y draft; los casos sensibles se elevan antes de responder.
Base de datos principal: Supabase
Todo el workflow usa Supabase como fuente de verdad: guarda cada registro, su estado y los eventos clave para ver que paso, reintentar fallos y depurar sin buscar en cada herramienta.
Iconos de herramientas
Racional del sistema
El flujo hace visible la primera decisión de soporte
Soporte mejora cuando el sistema recoge contexto y detecta riesgo, mientras los agentes mantienen control sobre empatia, excepciones y juicio frente al cliente.
Contexto antes de responder
Estado de pedido, historial y politica llegan antes de redactar, reduciendo la lectura repetitiva inicial.
El riesgo no se esconde
Los reembolsos, las quejas y los fallos de entrega se marcan pronto para que la cola no trate todos los casos igual.
Borradores con límites
Las respuestas de bajo riesgo pueden prepararse, pero las decisiones sensibles conservan un control humano.
Add-ons que encajan encima
El punto de partida
Un equipo ecommerce con un volumen elevado de soporte gestionaba preguntas de pedidos, reembolsos, fallos de entrega, producto y quejas en una sola cola. Cada ticket empezaba con el mismo trabajo repetitivo: leer, localizar el pedido, comprobar la política y valorar el riesgo, aunque solo una parte necesitaba atención especializada.
El diagnostico se hizo sobre volumen real, herramientas conectadas, puntos de decision y excepciones. La pregunta no era solo que automatizar, sino que prueba demostraria que el proceso habia terminado bien. La prueba operativa importo tanto como la automatizacion.
La implementación
Ductio añadió una capa de triaje antes del trabajo del agente. Cada mensaje se clasifica, se enriquece con el historial del pedido, se comprueba frente a las reglas de atención, recibe una etiqueta de riesgo y se dirige a una respuesta revisable o a una ruta de escalado.
La implementacion separo reglas, contexto libre, decisiones humanas y efectos externos. Asi el sistema podia mejorar el trabajo diario sin convertir cada excepcion en una caja negra. IA como apoyo dentro del proceso, no como piloto automático.
Qué se usó
La selección de herramientas se hizo desde el proceso, no desde una preferencia técnica previa. El criterio fue que cada pieza tuviera un owner claro, integración estable y una forma sencilla de revisar errores.
En la práctica se combinó Helpdesk, Order API, Supabase, Python/FastAPI, OpenRouter, Resend. Las herramientas visibles para el equipo quedaron cerca de su trabajo diario, mientras la lógica de integración quedó documentada y separada de decisiones comerciales sensibles.
La mejora se vio en el trabajo diario.
En lugar de presentar el resultado como un dashboard, el equipo lo notó en tres escenas concretas: menos preparación manual, menos búsqueda de contexto y menos dudas sobre quién tenía que actuar.
Tiempo de triaje: Esfuerzo medio para la primera clasificación pasó de 18 min a 7 min.
Claridad de la cola: Tickets etiquetados con una siguiente acción pasó de Baja a Alta.
Escalado: Casos sensibles visibles desde el inicio pasó de Manual a Señalizado.
Prueba antes/después
Qué cambió en la operación
Antes
Después
Artefactos visibles
- Ejemplos de categorias
- Panel contexto pedido
- Matriz de riesgo
- Ejemplos de drafts
- Reglas de escalado
- Digest de mix de cola
Controles
- Refunds y quejas escalados
- Respuestas low-confidence quedan en revision
- Drafts ligados a pedido y politica
- Sin decision de refund/chargeback fuera de reglas
- Humano sigue siendo remitente final
Qué cambió después
Los agentes abren cada ticket con la historia del pedido, los límites de la política y la ruta recomendada ya visibles. Las consultas rutinarias avanzan por una vía de respuesta revisable y los reembolsos, quejas o fallos de entrega aparecen como excepciones antes de dañar la confianza del cliente.
El resultado no fue solo ahorrar minutos. El equipo gano una secuencia comun para revisar entradas, entender contexto, decidir, actuar y comprobar que el workflow habia quedado registrado. 60% triaje más rápido
El workflow en una línea
Cómo se construyó
El workflow escucha tickets nuevos, guarda estado de triaje, recupera metadata de pedido, usa OpenRouter para categoria/riesgo/draft, actualiza el helpdesk con labels y contexto, y escribe eventos de escalado para casos sensibles o low-confidence.
El stack fue pragmático: Helpdesk, Order API, Supabase, Python/FastAPI, OpenRouter, Resend. No se eligieron herramientas para impresionar, sino por ownership, integración y mantenimiento. El resultado es un sistema que el equipo puede entender y operar.
Lo que quedó entregado
- Clasificación de tickets
- Consulta de pedidos
- Borrador según política
- Etiquetas de riesgo
- Escalado
- Revisión por baja confianza
- Resumen de la cola
- Los agentes empiezan con categoria, estado de pedido, historial y siguiente accion.
- Respuestas simples quedan preparadas para revision con contexto real de pedido.
- Refunds, quejas, chargebacks y riesgos de entrega se detectan antes.
- Los casos low-confidence no se responden automaticamente; crean una revision.
- Los responsables ven la composición de la cola, no solo su volumen.
- Agentes nuevos entienden antes el primer camino de decision.
- Ningún caso sensible o de baja confianza genera una respuesta automática al cliente.
