¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
Un contacto repetido solo debería contar cuando el mismo cliente vuelve por la misma necesidad porque el resultado prometido no se ha producido. Un segundo mensaje no es automáticamente un fallo. Puede ser una actualización prevista, un agradecimiento o un problema distinto.
La diferencia parece obvia hasta el informe. Agrupar los contactos de una persona durante treinta días eleva la tasa ante preguntas distintas y oculta problemas que vuelven por otro canal.
Cuente la vuelta solo si la necesidad continúa
Empiece por la necesidad del cliente, no por el número del ticket. Imagine que alguien avisa de que su conexión a internet falla todas las tardes. Soporte reinicia el router y cierra el chat. Dos días después, la persona llama porque la conexión sigue fallando. Es un contacto repetido aunque la llamada haya creado otro registro.
Cambiemos un detalle. Si esa persona llama dos días después para preguntar por una factura, se trata de una necesidad nueva. No debe entrar en el numerador.
La regla exige que coincidan cliente, problema y resultado pendiente. Si no puede demostrar uno de esos elementos, conserve el evento como desconocido.
Elija la unidad antes de calcular
Fije una cohorte de primeros contactos elegibles y observe cada problema durante una ventana publicada. El numerador es el número de problemas iniciales que producen al menos una vuelta no prevista sobre la misma necesidad sin resolver. El denominador contiene todos los problemas iniciales elegibles de la cohorte.
- 1Fije la cohorte inicialIncluya necesidades iniciales elegibles y dé a todas la misma ventana completa de observación.
- 2Vincule cliente y problemaUna evidencia de identidad permitida entre canales y confirme si la necesidad posterior es la misma.
- 3Clasifique el evento posteriorSepare la vuelta sin resolver de actualizaciones previstas, agradecimientos, necesidades nuevas, duplicados y desconocidos.
- 4Revise la primera causaExamine los recorridos y asigne el primer fallo controlable de conocimiento, autoridad, proceso, producto, comunicación o propiedad.
Esta tasa evita contar tres veces un problema porque el cliente envió tres seguimientos. Para medir carga, divida por separado todos los contactos repetidos entre todos los atendidos.
La ventana debe seguir el trabajo. Siete días sirven para una contraseña, pero pueden ser pocos para una pieza. La guía oficial de Microsoft sobre enrutamiento de clientes que regresan admite periodos como siete, diez o treinta días. Esas opciones muestran que no existe una ventana universal. Publique la suya y manténgala estable.
Conecte el recorrido entre canales
Una medida útil necesita dos enlaces. Primero, una a la persona entre correo, teléfono, WhatsApp, chat web y cualquier otro punto de entrada. Después, determine si el contacto posterior trata del mismo resultado pendiente.
Una bandeja compartida puede conservar el historial de la conversación y un registro de cliente puede mantener la identidad estable y la relación con el problema. No una por número de teléfono solamente si los números pueden compartirse, cambiar o escribirse mal. Use solo identificadores permitidos y mantenga la lógica de coincidencia dentro de sus reglas de seguridad y acceso.
La coincidencia puede comenzar con relaciones entre casos y una clasificación breve, pero debe admitir revisión. Palabras iguales pueden describir necesidades distintas y palabras diferentes una misma entrega fallida. Las reglas de automatización pueden sugerir un enlace, pero una coincidencia débil permanece desconocida hasta su revisión.
Separe repeticiones de contactos legítimos
La regla de clasificación importa más que la aritmética.
| Contacto posterior | Cuenta como repetición | Motivo |
|---|---|---|
| La misma necesidad y el resultado prometido sigue pendiente | Sí | El problema original continúa sin resolverse |
| Actualización en un momento acordado con el cliente | No | El contacto forma parte del servicio previsto |
| El cliente da las gracias sin pedir nada más | No | No existe una necesidad renovada de servicio |
| El mismo cliente comunica un problema distinto | No | Coincide la persona pero no el problema |
| El equipo envía un mensaje saliente duplicado | No | Es un defecto de mensajería y no demanda repetida |
| No hay evidencia suficiente | Desconocido | No fuerce un evento incierto hacia ningún lado |
La guía oficial de Microsoft sobre el proceso desde el caso hasta la resolución describe identificar al cliente entre canales y registrar, investigar, resolver y cerrar casos. Esos eventos conservan evidencia, pero no determinan si una necesidad posterior es repetida. Un toque, resolución inicial, reapertura y contacto repetido están relacionados, pero no son intercambiables.
Busque causas sin culpar al agente
Después de confirmar una repetición, asigne la primera causa controlable. Puede ser una respuesta incorrecta, un reembolso fallido, contexto perdido en una transferencia, una actualización ausente, un producto aún averiado o una política que exige otro contacto.
Revise una muestra con la necesidad inicial, la promesa, el resultado, la vuelta y la corrección. Una revisión del flujo de soporte debe distinguir conocimiento, autoridad, proceso, producto, comunicación y propiedad. Si toda repetición se convierte en formación, el informe esconderá el fallo del sistema.
Muestre también la distribución. Indique cuántos problemas regresaron una vez, dos o más, y cuánto tardó el cliente en volver. Un promedio estable puede ocultar a un grupo pequeño atrapado en un bucle.
Lea la tasa junto a otras medidas
Lea la tasa junto a reapertura, resolución inicial, esfuerzo y finalización verificada. Si mejora la primera resolución mientras aumentan las repeticiones, compruebe las definiciones. Una medida puede depender del cierre del agente y la otra del comportamiento del cliente.
Use cohortes fijas para que los casos recientes tengan su ventana completa. Un informe de bandeja semanal puede mostrar cohorte madura, coincidencias desconocidas, problemas repetidos, carga, tiempo hasta la vuelta y causas verificadas. No mezcle casos inmaduros para publicar antes.
El resultado útil no es únicamente un porcentaje menor. Es que menos clientes tengan que volver porque el resultado que esperaban no ocurrió.
Preguntas frecuentes
Es la tasa de repetición lo contrario de la resolución en el primer contacto
No de forma fiable. La resolución inicial puede basarse en el estado marcado por el agente, una encuesta o una regla de un solo toque. La repetición observa el comportamiento posterior del cliente dentro de una ventana. Si cambian elegibilidad e identidad, las tasas pueden moverse por separado.
Cuál es una buena ventana de observación
Use la ventana más corta que todavía capture una vuelta normal para ese problema. Publíquela por grupo y manténgala estable. Las tareas rápidas de cuenta pueden necesitar días, mientras que los casos con cumplimiento o dependencias externas requieren más tiempo.
Deben contarse varias respuestas más de una vez
No en una tasa basada en problemas. Cuente el problema inicial una vez en el numerador si produce alguna repetición confirmada. Registre por separado el total de contactos repetidos para medir carga y bucles del cliente.
Qué ocurre si el mismo problema aparece en otro canal
Vincúlelo con la necesidad original cuando la identidad y la evidencia sean suficientemente sólidas. El cambio de canal no borra la repetición. Si la coincidencia es incierta, clasifíquela como desconocida y revise la regla de enlace.
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