Una persona responde una pregunta, espera y no oye nada. El agente de voz no ha entendido mal la intención. Ha dejado de responder. Repetir la pregunta no arreglará una conexión rota.
Configura la ruta de fallo antes del lanzamiento. Decide qué debe oír el cliente, elige una acción de Dynamics 365 que alcance ayuda real, ensaya el fallo y conserva evidencia de que después hubo una persona o un final honesto. El silencio no es una alternativa.
Las notas de Microsoft Update 26092 indican que Dynamics 365 Contact Center mantiene mejor la continuidad de mensajes y enrutamiento cuando un agente de IA deja de responder. Aun así, operaciones debe elegir la promesa y demostrar que el destino funciona.
Trata el silencio como un incidente de servicio
Un fallo de intención ocurre cuando el agente no entiende lo que quiere la persona. Un fallo de ejecución es distinto. El cliente puede haber compartido su nombre, un pedido o el motivo de la llamada antes de que un problema del sistema o la red deje al agente fuera de servicio.
- 1Define la promesaDecide qué oirá el cliente y qué ayuda está realmente disponible.
- 2Ajusta la acción al riesgoElige de forma consciente escalado, transferencia, espera o cierre.
- 3Verifica el destinoConfirma número, cola, personal y permisos antes de depender de ellos.
- 4Ensaya el falloDeja la IA fuera de servicio de forma controlada y sigue la ruta del cliente.
- 5Vigila la recuperaciónRevisa llamadas alternativas, destinos fallidos, propiedad y resultado.
No obligues al cliente a diagnosticar la diferencia. Ofrece un mensaje breve, sincero y un siguiente paso. Conserva internamente el punto de fallo, la ruta intentada y si alguien aceptó la llamada. Quien la recibe debe ver el contexto disponible en una bandeja compartida, no pedir que se repita toda la historia.
La gravedad depende de la tarea. El silencio al preguntar un horario molesta. En acceso a una cuenta, ayuda de pago o un servicio urgente exige una ruta humana más rápida. Elige la salida por el coste del retraso.
Elige la promesa antes del ajuste
La guía de Microsoft sobre acciones alternativas de IVR documenta cuatro opciones cuando el cliente no alcanza al agente o hay un fallo del sistema o la red. Cada una promete algo distinto.
| Acción integrada | Cuándo usarla | Qué comprobar | Evidencia que conservar |
|---|---|---|---|
| Aviso y fin de llamada | No existe un destino humano responsable y terminar es mejor que esperar | El aviso explica el final y el siguiente paso realista | Aviso reproducido, fin y dueño del seguimiento |
| Aviso y transferencia externa | Un servicio separado y atendido puede aceptar | El número E.164 aprobado responde en el horario prometido | Intento, respuesta y responsable del destino |
| Aviso y escalado | Hay una ruta interna disponible | Enrutamiento, capacidad y permisos permiten entregar | Evento, propietario que acepta y estado final |
| Música y escalado | Una espera breve con personal es aceptable | La música empieza, la cola puede atender y la espera larga tiene dueño | Inicio, aceptación, abandono o recuperación |
No tapes la incertidumbre con palabras alegres. Si alguien revisará mañana, dilo. Si nadie puede atender, un final claro con una alternativa real puede ser más honesto que música indefinida.
Un buen modelo operativo de IA limita la autoridad de la automatización y muestra la frontera humana. En un fallo, la ruta alternativa es esa frontera.
Demuestra que el destino responde
Una transferencia configurada no equivale a una recuperación. Comprueba el formato E.164 del número externo. Confirma que la cola interna está abierta, que una persona adecuada puede recibir el trabajo y que el cliente no cae en otro callejón automatizado.
Asigna dueño a cada dependencia. Telefonía puede ser del administrador, la cobertura del supervisor y el mensaje del responsable del servicio. Un flujo de automatización es más manejable con responsabilidades explícitas.
Usa datos sintéticos en la primera prueba. Inicia una llamada real, completa varios turnos normales y deja al agente fuera de servicio de forma controlada. Escucha como cliente. ¿Sonó el aviso una vez? ¿Coincidió la ruta con la acción elegida? ¿Respondió el destino? ¿Llegó el contexto previo?
Repite fuera del horario atendido. Prueba un número externo inalcanzable, una cola llena o cerrada y una persona que cuelga durante el aviso. Así sabrás si la propia alternativa falla con seguridad.
Conserva un registro compacto
Anota hora, canal, versión del agente, último turno correcto, punto de fallo, mensaje, acción, destino, resultado, propietario y decisión de reparación. No uses datos personales ni de pago. El acceso a evidencia y ajustes debe respetar tus controles de seguridad.
Microsoft documenta la métrica Fallback calls en el panel histórico del bot y en el análisis en tiempo real de Omnichannel. Úsala como señal, no como diagnóstico. Un aumento puede indicar una caída, una dependencia mala o más tráfico. Revisa conversaciones y separa los abandonos de fallos confirmados.
El responsable de recuperación debe revisar destinos fallidos, puntos repetidos y llamadas sin un siguiente paso aceptado. Las operaciones de soporte necesitan esa propiedad activa, mientras el registro del cliente conserva el contexto duradero.
DripTell puede mantener visibles la propiedad, las notas y el seguimiento entre canales tras la entrega. No puede hacer que un destino sin personal responda. La promesa debe coincidir con la cobertura real.
Preguntas frecuentes
Qué debe oír el cliente cuando falla la IA
Usa un mensaje breve que diga que el servicio automatizado no puede continuar y explique el siguiente paso real. No prometas una persona si la ruta no puede alcanzarla.
Qué acción alternativa es más segura
No hay una ganadora universal. El escalado sirve con una ruta interna atendida. La transferencia externa necesita un número E.164 probado. Terminar puede ser honesto sin ayuda en vivo. La música solo funciona si la cola responde.
Cómo se prueba un agente que no responde
Usa datos sintéticos, completa turnos normales, activa un fallo controlado y observa aviso, ruta, destino, contexto, responsable y estado final. Repite con el destino no disponible.
Dónde se vigilan estos fallos
Microsoft documenta Fallback calls en los informes históricos y en tiempo real del bot de Omnichannel. Combina el recuento con evidencia de conversaciones y un responsable de revisión.
¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
De la lectura a la acción
¿Quieres aplicar estas ideas en tu negocio?
Déjanos tus datos. Tendremos en cuenta el artículo que estás leyendo y empezaremos con una respuesta útil para tu equipo.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes
