Un cliente llega a recoger un pedido y dice que nunca recibió el mensaje. Reenviarlo parece la respuesta más rápida, pero puede crear un segundo fallo, una conversación duplicada o un informe engañoso.
Conviene investigar un solo intento desde el evento comercial hasta el dispositivo del cliente. En Dynamics 365, enviado, fallido y sin respuesta describen momentos distintos. Necesitan decisiones distintas. Empieza con un cliente, un mensaje, un intervalo y un responsable.
Empieza por una promesa al cliente
Un SMS suele representar una promesa real: recordar una cita, avisar de una recogida, pedir un pago o comunicar un cambio urgente. Registra qué debía recibir la persona y antes de qué hora. Conserva el identificador del mensaje, el de la conversación, los números de origen y destino, la hora, la versión de la plantilla o flujo y el evento que inició el envío.
Hazlo antes de modificar la automatización o reintentar. Si la evidencia cambia durante la investigación, no podrás separar el fallo original de una acción posterior. La causa podría estar en el disparador, la plataforma, el proveedor, el operador o el destino.
Mantén el alcance pequeño. Una queja no demuestra una caída del canal. Varias incidencias parecidas del mismo remitente y periodo sí pueden señalar algo mayor. La pregunta no es si se rompió todo el SMS empresarial, sino dónde se detuvo esta promesa. Así el equipo de soporte recibe un estado útil y no una frase técnica vaga.
Lee el resultado de forma literal
La guía actual de Microsoft sobre resultados de contacto proactivo separa estados fáciles de confundir.
- 1Identifica el intentoConserva cliente, mensaje, conversación, remitente y hora.
- 2Lee el resultadoSepara enviado, fallido, timeout y conversación activa.
- 3Sigue el límiteAvanza del flujo a Dynamics, proveedor y operador.
- 4Protege la promesaElige una recuperación segura o un canal alternativo.
- 5Verifica el cierreRegistra el resultado del cliente y el alcance de la revisión.
MessageSent significa que el mensaje se entregó al proveedor u operador de SMS. No confirma que llegó al dispositivo. MessageFailed significa que el proveedor u operador no pudo entregarlo. ResponseTimeout indica que el cliente no respondió dentro del primer plazo configurado. No prueba un fallo de entrega. ConversationExists evita el envío cuando ya existe una conversación activa entre el mismo origen y destinatario. EngagementAbandoned puede aparecer si sale otro mensaje antes de que el cliente responda.
La diferencia es importante. Reintentar un ResponseTimeout como si fuera un fallo del operador puede molestar a quien ya leyó el mensaje. Forzar un envío ante ConversationExists puede anular la protección contra conversaciones solapadas. Trata el resultado como el inicio de la investigación.
Sigue la evidencia hasta el límite
La actualización 26092 de Dynamics 365 Contact Center mejora el seguimiento de SMS no entregados para relacionar mensajes atascados con información del operador. Usa esa evidencia para localizar el límite. Si el evento no creó un intento, revisa el flujo. Si Dynamics entregó el mensaje pero no aparece resultado final, sigue el rastro del proveedor y el operador. Si hubo rechazo, conserva el motivo antes de corregir.
Asigna un dueño a cada límite.
| Límite de evidencia | Responsable principal | Qué conservar | Decisión necesaria |
|---|---|---|---|
| Evento comercial | Dueño del proceso | Evento, regla de elegibilidad, versión del flujo | Debía crearse el mensaje |
| Registro de Dynamics | Administrador de plataforma | Identificadores, resultado, horas, estado | Empezó y terminó el procesamiento |
| Proveedor y operador | Dueño de mensajería | Referencia, trazado y detalle del fallo | Se puede reintentar o hay que configurar |
| Promesa al cliente | Dueño del servicio | Plazo, urgencia, consentimiento y alternativa | Cómo ayudar ahora |
| Registro de incidente | Líder de operaciones | Alcance, grupo afectado, acción y verificación | Es aislado o sistémico |
Este mapa evita una reunión llena de capturas sin nadie responsable del cliente. La evidencia técnica y la recuperación del servicio deben avanzar juntas.
Recupera sin crear otro incidente
Elige la acción según la evidencia. Corrige un destino inválido antes del reintento. Repara credenciales vencidas o una configuración errónea antes de liberar trabajo retenido. Si falta parte del rastro, mantén el caso abierto y escálalo con los identificadores ya reunidos. Para una promesa urgente, usa un canal alternativo aprobado o una llamada humana en vez de enviar repetidamente por una ruta incierta.
Haz un solo reintento controlado cuando entiendas la causa o puedas probar una hipótesis segura. Vincúlalo al incidente original. Detente si ya existe una conversación activa, la persona se da de baja o el responsable confirma el cumplimiento por otra vía.
Los controles de automatización pueden aplicar la condición de parada, mientras una bandeja compartida conserva la explicación y el dueño. Ninguno sustituye la evidencia del operador.
Convierte el fallo en un control útil
Cierra el incidente solo cuando el equipo pueda explicar qué pasó, qué vivió el cliente, qué cambió y cómo se verificó. “Mensaje reenviado” no basta. Anota el estado original, el límite del rastro, la recuperación, el resultado final y si se revisaron otros mensajes.
Busca patrones por remitente, proveedor, región, plantilla, versión del flujo y periodo, sin convertir cada queja aislada en un cambio de plataforma. Guarda la preferencia y el resultado en el registro del cliente. Si el fallo se repite, crea un umbral vigilado y un plan con dueño.
DripTell puede unir la conversación SMS, la propiedad del proceso y el contexto del cliente. La prueba práctica es que la siguiente persona vea qué se intentó, por qué falló y quién recupera la promesa. Para evaluar ese modelo, solicita una demostración enfocada.
Preguntas frecuentes
Significa MessageSent que el cliente recibió el SMS
No. Significa que llegó al proveedor u operador. Hace falta un resultado posterior o un rastro que confirme el límite del dispositivo.
La falta de respuesta indica fallo de entrega
No necesariamente. El plazo solo muestra que no hubo respuesta a tiempo. El cliente pudo recibir y leer el mensaje.
Cuándo es seguro reintentar
Después de conservar la evidencia y corregir una causa conocida, o como una sola prueba controlada con responsable y condición de parada.
Qué debe contener el registro del incidente
Guarda identificadores, números, horas, resultado, evidencia del proveedor u operador, impacto, acción de recuperación y verificación final.
¿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
