"Desde ayer no tengo internet en casa. He reiniciado el router varias veces, trabajo en remoto y necesito solución urgente. En WhatsApp me han dicho una cosa y por teléfono otra. Si esto sigue así me doy de baja." — Este mensaje, literal, es el escenario que propone Orange. Detrás hay un cliente frustrado, un teletrabajo parado y una decisión de negocio en juego. Tu misión no es un chatbot que responde FAQs: es un agente que decide — ¿avería de zona o problema individual? ¿diagnóstico o escalado? ¿está a punto de irse? — y deja tras de sí un ticket que un humano puede ejecutar.
La decisión que lo cambia todo
En una operadora real, la primera pregunta del diagnóstico nunca es "¿has reiniciado el router?" — es "¿es solo este cliente o es su zona entera?". Esa consulta convierte tu chatbot en un centro de operaciones.
Informa del alcance y el ETA real, vincula el ticket a la avería masiva y NO hagas perder tiempo al cliente con diagnósticos. Sin escalar.
Diagnóstico guiado paso a paso desde la KB: luces del router (LOS/PON), cable vs WiFi, una pregunta cada vez.
Detectar la frustración, aplicar la política de retención: empatía, datos honestos, prioridad alta, compensación anotada — nunca prometida.
Tu misión
Un agente que acompaña al cliente desde el "no funciona" hasta la resolución o el escalado correcto, y que siempre termina generando un ticket estructurado:
| Campo del ticket | Qué demuestra |
|---|---|
| tipo_incidencia (sin_conexion · lentitud · wifi · router · averia_linea · instalacion · cita_tecnica) | Clasificación correcta |
| urgencia (alta si impide teletrabajar o >24h sin servicio) | Criterio de negocio aplicado |
| resumen + pasos_probados | El humano que lo recoja no vuelve a empezar de cero |
| riesgo_baja (true/false) | Detección de churn |
| escalado (true/false) + recomendación | LA decisión — con los criterios de la KB |
Niveles
El agente de triaje completo
Conversación → clasificación → consulta de avería de zona por código postal (Data Table) → diagnóstico guiado con la KB (RAG) → detección de riesgo de baja → decisión de escalado → ticket real insertado en la Data Table de tickets.
El banco de pruebas
Evalúa tu agente con métricas reales: los casos de prueba traen el resultado esperado — montad el arnés (bucle sobre los casos + comparación por código) y presentad % de clasificación correcta, % de escalados correctos y % de detección de churn. Aviso de quien ya pasó por ahí: las métricas no solo evalúan al agente, también auditan vuestra taxonomía.
La organización de agentes
Ideas: atención multicanal con contexto compartido — el cliente empieza en el chat web, sigue por Telegram y el agente recuerda toda la conversación sin hacerle repetir su historia (justo lo que el cliente del brief se queja de que NO pasa: "en WhatsApp me dicen una cosa y por teléfono otra") · supervisor multi-agente (Triaje → Técnico → Retención → Operaciones) · cita técnica agendada de verdad · dashboard de tickets · cliente sintético LLM que estresa al agente.
Datos y recursos disponibles
| Recurso | Contenido | Descarga |
|---|---|---|
| Brief oficial del reto | El encargo completo de Orange: escenario del cliente, entregables y arquitectura pedida | orange-brief-del-reto.pdf |
| KB de soporte | Sintética: diagnóstico sin internet/lentitud/WiFi, luces del router, criterios de escalado, política de retención, canales | orange-kb-soporte.md |
| Averías de red por CP | 3 averías sintéticas activas (zona, severidad, estado, ETA) — el dato que habilita LA decisión | orange-averias-red.csv |
| Casos de prueba | 4 casos UAT con resultado esperado (tipo, escalado, riesgo de baja) — ampliadlos | orange-casos-prueba.csv |
Documentación útil: Ayuda Orange (fuente pública) · Data Tables · RAG en n8n · Kapso (WhatsApp)
Definition of Ready · Definition of Done
- KB indexada en vuestra instancia y averías importadas a vuestra Data Table (sabéis qué CP tiene qué)
- Taxonomía de tipos acordada en el equipo — con definiciones (¿"sin internet por avería" es
sin_conexionoaveria_linea? Decididlo y documentadlo) - Criterios de escalado de la KB leídos por todos
- Guion de demo con el escenario del brief
- El agente consulta la avería de zona ANTES de diagnosticar si tiene el CP
- Con avería masiva: informa ETA, vincula, no escala; sin ella y con LOS rojo: escala
- Riesgo de baja detectado y tratado con la política de retención (sin prometer compensaciones)
- Ticket completo insertado en la Data Table al cierre de cada conversación
- Métricas del banco de pruebas presentadas en el pitch (aunque no sean perfectas — explicadas)
Pruebas UAT — autoevalúate antes del pitch
"Desde ayer sin internet, reinicié el router, teletrabajo, me dicen cosas distintas en cada canal, me doy de baja. CP 28045."
Detecta la avería masiva de Arganzuela → informa ETA → NO escala → riesgo_baja=true → urgencia alta → ticket vinculado con petición de compensación anotada. Tono empático, datos honestos.
"La luz LOS está en rojo fija desde esta mañana, ya reinicié dos veces. CP 28001."
Sin avería de zona en 28001 + LOS rojo = criterio de escalado de la KB → escalado=true, ticket tipo avería de línea con los pasos ya probados.
"En el salón va perfecto pero en mi habitación el WiFi va lentísimo."
Diagnóstico WiFi desde la KB (5GHz vs 2,4GHz, canal, repetidor) — sin escalar, sin drama, sin inventar pasos que la KB no contiene.
"El 5G me va fatal hoy por Alcobendas, CP 28100."
Encuentra la incidencia de mantenimiento (severidad baja, 4G operativo, ETA hoy) → informa, sugiere 4G mientras tanto, no abre drama ni escalado.