Volver al blog
Analytics and quality

Cómo definir motivos de cierre en atención al cliente que mejoren los informes

Una política práctica para definir motivos de cierre que describan por qué terminó el trabajo sin confundir el cierre con la resolución, la satisfacción o el éxito duradero del cliente.

Equipo de operaciones de soporte revisando una taxonomía de motivos de cierre e informes de conversaciones

Cerrada es un estado del flujo de trabajo, no un veredicto sobre la calidad del servicio

El estado de una conversación indica al equipo en qué punto se encuentra un elemento dentro del flujo de trabajo. El resultado para el cliente describe lo que se sabe que le ha ocurrido al cliente. Un motivo de cierre registra por qué el equipo dejó de trabajar activamente en esa conversación en ese momento. Son hechos relacionados, pero no deben tratarse como si fueran intercambiables.

Una conversación cerrada puede representar una respuesta confirmada, un hilo duplicado, un cliente que dejó de responder, una derivación a otro proceso o trabajo pendiente de una parte externa. Ninguno de estos casos demuestra por sí solo que el problema subyacente del cliente se haya resuelto o que esté satisfecho.

Esta separación es coherente con la forma en que los procesos de soporte maduros distinguen la resolución, el análisis, la auditoría y la revisión de la eficacia. También mejora la calidad de los datos: un campo útil es adecuado para el uso previsto y es preciso, completo, coherente y oportuno.

Algunos sistemas hacen explícita esta distinción. Por ejemplo, Zendesk define Solucionado como el momento en que un agente envía una solución, mientras que Cerrado es un estado cerrado por el sistema que el solicitante no puede reabrir. Sus propias etiquetas y mecánicas pueden diferir, pero el principio de gobierno se mantiene: no informe una transición del flujo de trabajo como prueba de un resultado.

  • Estado: abierto, asignado, pendiente, en espera o cerrado, según el flujo de trabajo del equipo.
  • Resultado: resuelto confirmado, información proporcionada, solución temporal ofrecida, no resuelto, desconocido u otro estado definido deliberadamente.
  • Motivo de cierre: conversación duplicada, sin respuesta del cliente, transferida a otro equipo, dependencia externa, solicitud del cliente u otro motivo observable por el que terminó el trabajo activo.
  • Valoración del cliente: datos de comentarios independientes, no un sustituto de un resultado o motivo de cierre.
Cerrada es un estado del flujo de trabajo, no un veredicto sobre la calidad del servicio

Empiece por las decisiones que deben respaldar los datos

No empiece haciendo una lluvia de ideas de etiquetas. Empiece por las decisiones que debe tomar un responsable, analista de calidad o líder de equipo. Una taxonomía de motivos de cierre es calidad de datos operativos: debe ayudar a identificar la demanda, gestionar trabajo que puede volver, comprobar si el enrutamiento funciona y encontrar casos que requieren revisión.

Para cada motivo propuesto, anote la decisión que respaldará. Si nadie puede nombrar una decisión, informe, regla de cola, pregunta de calidad o acción de seguimiento, elimine la etiqueta o capture la información en otro lugar.

En una bandeja de entrada compartida de WebChat y WhatsApp, revise los motivos por canal, departamento, ruta de enrutamiento, horario y contexto de nivel de servicio cuando esas dimensiones estén disponibles. webchat.vip proporciona una bandeja de entrada compartida para WebChat y WhatsApp, organización de operadores y departamentos, enrutamiento, horarios, niveles de servicio, etiquetas, registros de conversaciones, valoraciones e informes operativos exportables. Esos registros pueden respaldar la revisión; no convierten un motivo de cierre en prueba de resolución.

  • Patrones de demanda: ¿Qué necesidades de clientes terminan repetidamente como una dependencia externa o una transferencia?
  • Riesgo de acumulación: ¿Cuántas conversaciones se cerraron porque el cliente no respondió y cuántas vuelven más adelante?
  • Controles de calidad: ¿Los operadores eligen el motivo que respalda la transcripción?
  • Mejora del enrutamiento: ¿Departamentos concretos reciben transferencias evitables o contactos duplicados?
  • Riesgo de seguimiento: ¿Qué motivos de cierre deben supervisarse ante un nuevo contacto, una queja o un contacto manual según su política?
Empiece por las decisiones que deben respaldar los datos

Use una taxonomía pequeña, observable y accionable

Una taxonomía utilizable tiene categorías que los operadores pueden reconocer a partir del registro de la conversación, seleccionar de manera coherente y explicar a un revisor. Debe ser lo bastante distinta entre categorías como para que dos operadores formados normalmente elijan la misma etiqueta para el mismo caso. También debe ser lo suficientemente pequeña para usarla bajo una carga de trabajo normal.

Evite etiquetas basadas en suposiciones sobre la intención o la emoción, salvo que el cliente haya expresado el punto de forma explícita y la etiqueta sirva a un proceso definido. «Cliente insatisfecho», «no es un problema real» y «error del agente» son malos motivos de cierre predeterminados: son vagos, pueden ser injustos y a menudo mezclan distintas preguntas operativas.

Pruebe cada etiqueta con cuatro comprobaciones: ¿puede observarse?, ¿es distinta?, ¿provoca una acción o informa una decisión?, y ¿puede un auditor verificarla a partir de la transcripción o el registro vinculado? Si la respuesta es no, reescríbala, fusiónela o elimínela.

  • Mantenga los motivos de cierre obligatorios en aproximadamente el conjunto más pequeño que responda a las preguntas principales del equipo; añada detalle solo cuando cambie una decisión.
  • Use definiciones en lenguaje claro, reglas de inclusión, reglas de exclusión y un ejemplo positivo para cada etiqueta.
  • Use «desconocido» solo cuando sea realmente necesario y audítelo. Debe revelar una limitación de las pruebas, no convertirse en un valor predeterminado cómodo.
  • Versione la taxonomía. Conserve una correspondencia cuando se cambien de nombre o se fusionen etiquetas para que los informes de tendencias sigan siendo interpretables.

Una estructura inicial: necesidad, acción, resultado y cierre

Un campo rara vez contiene todos los hechos necesarios para generar informes útiles. En lugar de crear una larga lista de etiquetas híbridas como «pregunta de facturación resuelta tras transferencia», separe las dimensiones cuando sus herramientas y flujo de trabajo lo permitan. Esto reduce la ambigüedad y hace que el análisis sea más flexible.

Use un motivo de cierre obligatorio para indicar por qué terminó el trabajo activo. Capture la necesidad del cliente, la acción realizada y el resultado actual en campos estructurados independientes solo si el equipo tiene un uso claro para ellos. Cuando una plataforma no admita campos separados, utilice una entrada concisa y estandarizada en el registro de la conversación y documente sus limitaciones para la elaboración de informes.

Las etiquetas son útiles para marcadores flexibles y transversales, como una campaña, un área de producto o una referencia de incidente. No deben convertirse silenciosamente en un segundo sistema de motivos de cierre que compita con el primero. Mantenga el motivo de cierre autorizado en una única ubicación gobernada.

  • Necesidad del cliente: acceso a la cuenta, facturación, estado del pedido, problema técnico, información sobre el producto, queja u otra categoría de demanda.
  • Acción realizada: respuesta proporcionada, resolución de problemas efectuada, transferencia, proceso de reembolso iniciado, recurso de autoservicio compartido o escalación abierta.
  • Resultado actual: resuelto confirmado, el cliente indicó resolución, acción externa pendiente, no resuelto, desconocido o no aplicable.
  • Motivo de cierre: por qué el operador o el flujo de trabajo terminó la gestión activa de esta conversación específica.

Defina los casos ambiguos antes de que los operadores los encuentren

Los casos ambiguos son donde comienza la desviación en los informes. Proporcione al personal una regla de decisión que empiece con las pruebas de la transcripción, no con la etiqueta disponible más rápida. Cuando las pruebas sean incompletas, registre lo que se sabe y use la ruta definida de desconocido o sin respuesta en lugar de dar a entender que hubo éxito.

Una transferencia o escalación no es en sí misma una resolución. Debe preservar la responsabilidad, el equipo receptor y la siguiente acción requerida. Si la conversación de origen termina después de una derivación, su motivo de cierre puede describir la derivación, mientras que el proceso receptor registra su propio resultado final.

Las dependencias externas requieren especial cuidado. Cerrar un hilo de la bandeja de entrada porque el equipo espera a un transportista, proveedor de pagos, investigación de ingeniería u otra parte externa puede ocultar trabajo sin terminar. Mantenga el trabajo abierto, en espera o en un proceso de seguimiento controlado cuando su política requiera una acción. Si una conversación debe cerrarse, haga visible la dependencia en el motivo de cierre y en el registro vinculado.

  • Conversación duplicada: selecciónela solo cuando el mismo problema del cliente ya se gestione activamente en otro lugar. Vincule o identifique el registro principal de acuerdo con su política de privacidad; no marque un problema distinto como duplicado simplemente porque el cliente ya se haya puesto en contacto antes.
  • Abandono del cliente: úselo solo cuando el cliente se retire explícitamente o cuando su política defina la situación. No deduzca abandono a partir de una pausa breve.
  • Cierre por falta de respuesta: selecciónelo cuando el equipo solicitó información u ofreció ayuda, transcurrió el período de espera documentado y no llegó respuesta. Esto significa que el resultado es desconocido, salvo que existan otras pruebas.
  • Dependencia externa: úsela cuando el siguiente paso necesario corresponda a un tercero o a un proceso interno separado. Registre el responsable y el próximo punto de revisión en el flujo de trabajo de seguimiento adecuado.
  • Escalación o transferencia: úsela cuando la responsabilidad se haya trasladado. Registre el destino, el motivo de la derivación y si la parte receptora la aceptó.
  • Cierre solicitado por el cliente: úselo cuando el cliente pida claramente terminar la conversación; no demuestra que se haya atendido su necesidad.

Asigne responsabilidades y capture el motivo en el momento adecuado

El operador que termina el trabajo activo normalmente debe seleccionar el motivo de cierre porque tiene el contexto más reciente. Un responsable receptor debe seleccionarlo o modificarlo cuando se transfirió el trabajo y este completa la gestión final. Los supervisores y analistas de calidad pueden corregir un motivo tras una revisión, pero las correcciones deben poder atribuirse y no deben borrar la oportunidad de aprendizaje.

Capture el motivo en el evento de cierre o inmediatamente antes. Completarlo más tarde aumenta las conjeturas. Si la automatización puede cerrar conversaciones, identifique por separado sus rutas de cierre y compruebe si se omiten los campos obligatorios. Algunos productos de bandeja de entrada indican expresamente que los controles obligatorios antes del cierre pueden no aplicarse a cierres automatizados, de flujo de trabajo o mediante API; los equipos deben verificar el comportamiento de su propia configuración en lugar de asumir que se aplica.

Los flujos automatizados de webchat.vip pueden enviar mensajes y archivos, recopilar respuestas validadas, ramificarse, transferir y derivar a personas. Use la automatización para recopilar datos claros y enrutar el trabajo, pero envíe las excepciones, quejas, ambigüedades, cuestiones de seguridad y solicitudes que requieran criterio a una persona. La automatización no debe deducir que el silencio equivale a una resolución.

  • Operador: selecciona el motivo provisional o final que respalda la transcripción.
  • Equipo receptor: confirma el motivo de gestión final tras una transferencia, cuando es responsable de la finalización.
  • Líder de equipo: resuelve disputas, aprueba excepciones y supervisa etiquetas ausentes o usadas en exceso.
  • Analista de calidad: audita la precisión y recomienda cambios en la taxonomía o la formación.
  • Administrador: controla los valores permitidos, los avisos del flujo de trabajo, las correspondencias de informes y el historial documentado de cambios.

Use etiquetas y campos de contexto sin duplicar la taxonomía

Defina la función de cada campo antes del lanzamiento. Un motivo de cierre responde por qué terminó la gestión activa. Una etiqueta identifica un marcador flexible. Un campo de enrutamiento o departamento muestra adónde fue el trabajo. Un registro de transferencia explica el movimiento de responsabilidad. Una nota operativa interna concisa, cuando su proceso la admita, registra el contexto específico del caso que no puede estandarizarse con seguridad.

No exija al personal que introduzca el mismo hecho en un motivo de cierre, una etiqueta y una nota. La repetición crea contradicciones y tiempo de gestión desperdiciado. Exija el campo estructurado solo cuando impulse los informes o el flujo de trabajo, y use las etiquetas para recuperación y las notas para el contexto mínimo que necesite la siguiente persona que gestione el caso.

Use una lista de comprobación coherente para las transferencias. El siguiente equipo necesita la solicitud del cliente, los pasos ya realizados, las pruebas recopiladas, la siguiente acción prometida, cualquier plazo y el motivo de la transferencia. Proteja la información personal y sensible: registre solo lo necesario, limite el acceso de forma adecuada y cumpla los requisitos de conservación y consentimiento de su organización.

  • Motivo de cierre: un valor gobernado por cada evento de cierre.
  • Etiquetas: marcadores transversales opcionales o controlados, como área de producto o cohorte de incidente.
  • Registro de conversación: el rastro de pruebas para revisión y continuidad.
  • Contexto de transferencia: responsable receptor, propósito, trabajo completado y siguiente acción.
  • Valoración: señal independiente de comentarios del cliente, interpretada con datos de respuesta, reapertura y resultado.

Audite la precisión, la completitud y los cambios a lo largo del tiempo

Una taxonomía es un control operativo vivo, no una configuración puntual. Realice una revisión periódica de calidad usando una muestra de operadores, departamentos, canales, motivos de alto volumen y motivos de alto riesgo. Compare el valor seleccionado con la transcripción y cualquier registro de seguimiento vinculado. Evalúe si el motivo está respaldado, si existe el contexto requerido y si se utilizó la ruta de escalación correcta.

Mida tanto la calidad de la selección como la salud de la taxonomía. Una tasa alta de «otro», «desconocido», «resuelto» o cierre por falta de respuesta puede indicar definiciones poco claras, diseño inadecuado del flujo de trabajo, una carencia de formación o un cambio en la demanda de los clientes. No suponga que es un problema de rendimiento del operador sin revisar las pruebas.

Documente los cambios propuestos, su justificación, fecha de entrada en vigor, responsable y correspondencia en los informes. Pruebe revisiones importantes con un grupo pequeño y, después, enseñe las reglas modificadas con ejemplos y ejercicios breves de calibración. ISO 10002 identifica la formación, el análisis, la auditoría y la revisión como elementos separados de una gestión eficaz de quejas; trate el gobierno de los motivos de cierre con la misma disciplina.

  • Semanal o mensualmente: audite una muestra basada en el riesgo de conversaciones cerradas.
  • Para cada elemento auditado: compare la transcripción, el motivo seleccionado, el resultado, el historial de transferencias y cualquier contacto posterior.
  • Calibre: pida a dos revisores que clasifiquen una pequeña muestra compartida, analicen los desacuerdos y perfeccionen las definiciones.
  • Realice seguimiento de: valores ausentes, tasa de corrección, tasa de «otro», desacuerdo entre revisores y patrones de reapertura o contacto repetido por motivo.
  • Cambie de forma segura: mantenga un registro de versiones de la taxonomía y asigne los valores antiguos a los nuevos grupos de informes.

Preguntas frecuentes

¿Cuál es la diferencia entre un motivo de cierre de atención al cliente y un código de resolución?

Un motivo de cierre indica por qué terminó la gestión activa de una conversación. Un código de resolución o resultado indica lo que se sabe sobre el problema del cliente. Pueden coincidir en un caso sencillo, pero un cierre por falta de respuesta o una dependencia externa muestran por qué deben mantenerse separados.

¿Debe informarse cada conversación cerrada como resuelta?

No. Cerrada es un estado del flujo de trabajo. Informe por separado la resolución confirmada, el resultado desconocido, las transferencias, los cierres por falta de respuesta y las dependencias externas para que los responsables no confundan el volumen de cierres con la calidad del servicio.

¿Cuántos motivos de cierre de atención al cliente debemos usar?

Use el conjunto más pequeño que respalde decisiones definidas y pueda aplicarse de manera coherente. Empiece con un conjunto básico limitado, audite conversaciones reales y añada una categoría solo cuando sea observable, distinta y accionable.

¿Qué debe ocurrir cuando un cliente deja de responder?

Use un proceso documentado de falta de respuesta: indique qué información o acción se solicitó, espere el período aprobado, envíe cualquier recordatorio requerido y cierre con un motivo de falta de respuesta. Registre el resultado como desconocido salvo que la transcripción aporte pruebas de lo contrario.

¿Quién puede cambiar un motivo de cierre después de cerrar una conversación?

Permita que un rol definido de supervisión o revisión de calidad corrija errores claros y conserve un registro de la corrección y su justificación. El proceso de corrección debe mejorar los informes sin ocultar el problema original de formación o flujo de trabajo.

¿Cuándo debe una persona tomar el control de la automatización?

Derive a una persona cuando el caso sea ambiguo, implique una queja, requiera una decisión basada en criterio, incluya circunstancias sensibles, tenga una dependencia externa sin resolver o necesite una excepción a la política normal de cierre.

Fuentes y lecturas adicionales

Referencias primarias y autorizadas usadas para verificar la base factual de esta guía.

  1. ISO 10002:2018 — Quality management: Customer satisfaction — Guidelines for complaints handling in organizations — International Organization for Standardization (ISO)
  2. Research Data Framework (RDaF): Version 1.5 — National Institute of Standards and Technology (NIST)
  3. About the ticket lifecycle and ticket statuses — Zendesk Help
  4. How and when to use conversation topics, attributes, and tags — Intercom Help
  5. Create and use conversation data attributes (CvDAs) in the Inbox — Intercom Help
  6. Reporting metrics & attributes — Intercom Help
  7. Loop teammates or teams into conversations — Intercom Help
  8. Assign conversations to teammates and teams — Intercom Help