Cómo medir la demanda por fallos en atención al cliente

La demanda por fallos es el contacto de un cliente que no habría existido si una parte anterior del servicio hubiera funcionado como se prometió. Para medirla, revisa una muestra representativa de contactos entrantes y pregunta si cada uno seguiría siendo necesario si el trabajo anterior se hubiera hecho bien y el cliente hubiera recibido información a tiempo. Después informa tanto su proporción de contactos como su proporción de tiempo de atención.

Un contacto repetido no demuestra un fallo. El cliente puede volver con una pregunta nueva, enviar un documento solicitado o pedir ayuda por un hecho distinto. La causa importa más que el recuento.

La definición del Gobierno de Escocia de 2026 describe la demanda por fallos como una necesidad evitable o generada por el sistema que surge cuando una intervención anterior estuvo ausente, fue insuficiente o no funcionó. En atención al cliente puede ser perseguir una actualización prometida, repetir datos perdidos en una transferencia, reabrir un problema cerrado demasiado pronto o preguntar por una acción que nunca ocurrió.

Empieza por el contacto que no debería existir

Usa una misma pregunta contrafactual durante toda la revisión.

¿Este contacto seguiría siendo necesario si la empresa hubiera hecho correctamente el trabajo anterior y mantenido al cliente bien informado?

Si la respuesta honesta es no, probablemente sea demanda por fallos. Si el cliente hace una solicitud nueva o completa un paso acordado, probablemente sea demanda de valor, es decir, contacto que el servicio existe para atender.

Imagina que una persona pregunta cuándo llegará su pedido. La primera consulta puede ser normal. Soporte promete una actualización para el martes. El jueves la persona vuelve a escribir porque no recibió nada. Ese segundo mensaje nace de una promesa incumplida. Si después de la entrega pide una factura fiscal, se trata de otra necesidad.

Clasifica también la causa original

Una sola etiqueta muestra cuánto trabajo evitable existe, pero no qué debes corregir. Asigna una causa original a cada caso clasificado. Mantén una lista lo bastante corta para que los revisores la apliquen con consistencia.

• Falta de política o autoridad
• Causa desconocida tras la revisión

Guarda la necesidad aparte de la causa. Una pregunta sobre la entrega es la necesidad. La actualización que faltó es la causa.

La causa puede estar en logística, facturación, producto, un proveedor, automatización o una decisión anterior. No la atribuyas automáticamente al agente que recibe el nuevo mensaje.

Construye una muestra que puedas defender

Toma una muestra temporal que cubra los canales, periodos, idiomas, equipos y motivos importantes. Amplíala en áreas de mayor riesgo.

Conserva seis hechos por contacto. Son el cliente y la necesidad, la promesa o evento anterior, lo que ocurrió realmente, el motivo del contacto actual, la decisión con su nivel de confianza y la causa original con el responsable de la corrección.

Pide a dos revisores que clasifiquen una primera parte. Resolved los desacuerdos, ajustad las reglas y conservad una categoría incierta.

Los casos reabiertos, mensajes repetidos y cambios de canal son señales útiles, pero no son prueba. La guía actual de informes de soporte de Zendesk recomienda examinar reaperturas, varias solicitudes del mismo cliente, edad, prioridad y categoría.

Mide la proporción de contactos y de trabajo

Informa al menos dos cifras.

La proporción de contactos por fallos es el número de contactos clasificados como demanda por fallos dividido por todos los contactos entrantes elegibles.

La proporción de trabajo es el tiempo de atención dedicado a esos casos dividido por el tiempo de todos los contactos elegibles.

La revisión del servicio al cliente de DWP realizada por la Oficina Nacional de Auditoría británica es un ejemplo real útil porque separó el tiempo de llamadas evitable, potencialmente evitable e inevitable. La lección es el método y sus límites, no un porcentaje tomado de otro servicio.

Desglosa ambas medidas por necesidad, causa, canal, idioma, producto y equipo de origen.

Conecta el recorrido antes de automatizar la etiqueta

Vincula los contactos por cliente y necesidad cuando la política lo permita. Conserva fechas, propiedad, estados, motivo de transferencia y evidencia de finalización.

Una bandeja compartida de DripTell puede reunir el historial, la propiedad, las notas, el estado y la siguiente acción para ver la secuencia.

Automatiza señales solo cuando las personas ya clasifiquen de manera fiable. Deja que las reglas encuentren casos para revisar, no que cada repetición sea un fallo.

Usa la medida para eliminar una causa

Elige la mayor causa evitable que un equipo concreto pueda cambiar. Define una intervención específica, como enviar una actualización honesta antes de la hora prometida, conservar el contexto durante la transferencia o impedir el cierre hasta confirmar la acción posterior.

Repite la misma clasificación después del cambio. Comprueba que las proporciones de contactos y trabajo bajaron para la causa elegida sin aumentar abandonos, quejas o dificultades para obtener ayuda. Si las etiquetas caen solo porque los clientes ya no pueden contactar, el servicio no mejoró.

El objetivo es que menos clientes tengan que pedir a la empresa que termine un trabajo ya prometido.

Para conectar la evidencia de tu servicio, contacta con DripTell.

Preguntas frecuentes

Qué diferencia hay entre demanda por fallos y contacto repetido

El contacto repetido es un hecho observable. La demanda por fallos es un juicio sobre su causa. Una repetición puede tratar una necesidad nueva y un primer contacto con soporte puede surgir de un proceso anterior fallido.

Toda consulta de estado cuenta como demanda por fallos

No. Cuenta cuando la empresa incumplió una actualización prometida o dejó expectativas confusas. Revisa primero la promesa y el contexto.

Qué tamaño debe tener la muestra

Debe cubrir cada canal, motivo, idioma y periodo operativo importante. Amplíala hasta que la clasificación de las causas de mayor volumen sea estable e informa el tamaño y la incertidumbre.

Debe usarse como métrica de desempeño del agente

Normalmente no. La causa suele estar fuera del control del agente receptor. Usa la medida para encontrar el proceso fallido y asigna la corrección al equipo propietario del control original.