Solicitantes vs. remitentes de tickets de Zendesk: ¿Cuál es la diferencia?

Si alguna vez ha mirado un ticket de Zendesk y se ha preguntado por qué hay dos campos diferentes que parecen significar lo mismo, no está solo. Los campos de solicitante y remitente confunden a muchos equipos de soporte, y la distinción importa más de lo que podría pensar.

Vamos a desglosarlo. El solicitante es para quién es el ticket. El remitente es quien creó el ticket. La mayoría de las veces son la misma persona, pero cuando son diferentes, comprender por qué puede evitarle dolores de cabeza en los informes y percances en el flujo de trabajo.

Esto es lo que necesita saber sobre cada campo, cuándo divergen y cómo usarlos de manera efectiva en sus operaciones de soporte.

¿Qué es un solicitante de ticket en Zendesk?

El solicitante es la persona que solicita soporte. Es quien tiene el problema que necesita solución.

Para la mayoría de las empresas que utilizan Zendesk, el solicitante es un cliente. Pero los solicitantes también pueden ser agentes en su organización. Tal vez un empleado interno envió un ticket a su servicio de asistencia de TI, o un agente escaló algo en nombre de un colega.

El campo de solicitante importa porque:

• Reciben todas las comunicaciones del ticket Cada comentario público, actualización de estado y notificación de resolución va al solicitante
• Determinan la visibilidad del ticket En el portal del cliente de Zendesk, los usuarios solo pueden ver los tickets en los que figuran como solicitantes (a menos que estén en una organización compartida)
• Impulsan las reglas de negocio Sus disparadores, automatizaciones y vistas a menudo filtran o actúan en función del solicitante
• Se pueden cambiar Si se creó un ticket para la persona equivocada, los agentes con los permisos adecuados pueden actualizar el campo de solicitante

Lo clave para recordar es que el solicitante define para quién es la interacción de soporte, no necesariamente quién la inició.

¿Qué es un remitente de ticket en Zendesk?

El remitente es el usuario que realmente creó el ticket. Esta es la persona que hizo clic en "Enviar" o envió el correo electrónico que se convirtió en un ticket.

De forma predeterminada, el remitente de un ticket es el mismo que el solicitante. Cuando un cliente envía un correo electrónico a su dirección de soporte o completa su formulario web, está solicitando ayuda y creando el ticket. Por lo tanto, ambos campos se completan con su registro de usuario.

Pero aquí está la diferencia crítica: el remitente no se puede cambiar después de que se crea el ticket. Una vez que ese ticket existe en su sistema, el campo de remitente está bloqueado.

El campo de remitente importa para:

• Responsabilidad interna Saber qué agente creó un ticket en nombre de otra persona
• Seguimiento de API e integración Identificar qué sistema o cuenta de usuario creó los tickets mediante programación
• Pistas de auditoría Comprender el verdadero origen de una solicitud de soporte
• Enrutamiento del flujo de trabajo Algunas organizaciones utilizan los datos del remitente para enrutar o categorizar los tickets

Piense en el remitente como el campo de "rastro de papel". Le dice quién (o qué) realmente abrió el ticket, independientemente de para quién sea.

Cuándo el solicitante y el remitente son diferentes

Entonces, ¿cuándo divergen realmente estos campos? Aquí están los escenarios más comunes:

Agentes de centros de llamadas que crean tickets a partir de llamadas telefónicas

Un cliente llama a su línea de soporte. El agente les ayuda y crea un ticket para documentar la interacción. El cliente es el solicitante (necesitaba ayuda), pero el agente es el remitente (creó el ticket).

Asistentes ejecutivos que envían en nombre de los ejecutivos

Un asistente completa un formulario de soporte para su gerente. El ejecutivo es el solicitante, pero la cuenta de usuario del asistente es el remitente.

Servicios de asistencia de TI internos

Un empleado se acerca al mostrador de TI y pide ayuda. El personal de TI crea un ticket. El empleado es el solicitante, el personal de TI es el remitente.

Escenarios de API e integración

Su CRM, chatbot o integración de formulario crea tickets automáticamente. El usuario final es el solicitante, pero la cuenta de servicio o el cliente OAuth de la integración es el remitente.

Este último escenario es donde ocurre mucha confusión. Los desarrolladores que crean integraciones a veces esperan establecer el remitente en la ID del usuario final, pero Zendesk asigna el remitente en función de las credenciales de autenticación que realizan la llamada API. Si su integración utiliza una cuenta de servicio, esa cuenta se convierte en el remitente de cada ticket que crea.

Cómo ver y cambiar el solicitante

Puede encontrar el campo de solicitante en el panel de propiedades del ticket en el lado derecho de cualquier ticket en el espacio de trabajo del agente. Es uno de los campos principales que se muestran cerca de la parte superior.

Para cambiar el solicitante:

1. Abra el ticket en Zendesk
2. Haga clic en el campo de solicitante (puede mostrarse como un menú desplegable o un campo editable según sus permisos)
3. Busque y seleccione el usuario correcto
4. Guarde sus cambios

No todos los agentes pueden cambiar los solicitantes de forma predeterminada. Los administradores deben habilitar este permiso en el Centro de administración:

1. Vaya a Objetos y reglas > Tickets > Configuración
2. Haga clic en CC y seguidores en los tickets para expandir
3. Marque Permitir que los agentes cambien el solicitante
4. Guardar

Cambiar el solicitante afecta a quién recibe las notificaciones y quién puede ver el ticket en su portal de clientes. No afecta el campo de remitente, que permanece bloqueado.

Cómo identificar al remitente para la elaboración de informes

A diferencia del solicitante, no puede cambiar el remitente. Pero puede usar este campo para informes y filtrado.

En Zendesk Explore, los conjuntos de datos de Tickets, Historial de actualizaciones y SLA incluyen atributos sobre el remitente. Puede crear informes que muestren:

• Qué agentes crean la mayor cantidad de tickets en nombre de los clientes
• Qué porcentaje de tickets son enviados por usuarios finales frente a agentes
• Tendencias en las fuentes de creación de tickets a lo largo del tiempo

Para filtrar tickets por rol de remitente en Explore:

1. Cree una nueva consulta en el conjunto de datos de Tickets
2. Agregue un filtro para Rol de remitente
3. Seleccione los roles que desea incluir o excluir

Esto es particularmente útil para los servicios de asistencia internos que desean rastrear cuántos tickets son creados por agentes en comparación con los enviados directamente por los empleados a través de canales de autoservicio.

Errores comunes y cómo evitarlos

Asumir que el solicitante y el remitente son siempre los mismos

Esto conduce a la confusión cuando los tickets parecen provenir de agentes pero en realidad son para clientes. Siempre verifique ambos campos si no está seguro de a quién pertenece un ticket.

No rastrear al remitente para la responsabilidad interna

Si sus agentes crean con frecuencia tickets en nombre de los clientes, es posible que desee rastrear esto. Considere la posibilidad de crear un campo personalizado o usar etiquetas para identificar los tickets creados por agentes frente a clientes, especialmente si necesita estos datos para las métricas de rendimiento.

Integraciones de API que utilizan el campo incorrecto

Los desarrolladores a veces intentan establecer la ID del remitente al crear tickets a través de la API. Esto no funciona; el remitente está determinado por las credenciales de autenticación. Para establecer para quién es un ticket, utilice el campo de solicitante en su lugar.

Confusión en las reglas de negocio

Asegúrese de que sus disparadores y automatizaciones hagan referencia al campo correcto. Un disparador que se activa en función de "el usuario actual es el solicitante" se comporta de manera muy diferente de uno basado en "el usuario actual es el remitente".

Mejor práctica: En caso de duda, utilice el solicitante para la lógica orientada al cliente y el remitente para el seguimiento interno o fines de auditoría.

Agilice su flujo de trabajo de tickets con eesel AI

Comprender la diferencia entre solicitante y remitente es solo una parte de la gestión de una operación de soporte eficiente. El mayor desafío es manejar todos esos tickets de manera eficiente una vez que llegan a su cola.

Ahí es donde entramos nosotros. En eesel AI, hemos creado un compañero de equipo de IA que se integra directamente con Zendesk para manejar la mayor parte de la gestión de tickets.

Así es como ayudamos:

• Resolución autónoma de tickets Nuestro agente de IA puede manejar los tickets de soporte de primera línea de principio a fin, desde leer la solicitud hasta enviar la respuesta. Las implementaciones maduras alcanzan hasta un 81% de resolución autónoma.
• Triaje inteligente El triaje de IA etiqueta, enruta y prioriza automáticamente los tickets en función del contenido, no solo de las palabras clave. Entiende lo que los clientes realmente necesitan.
• Manejo consistente La IA aprende de sus tickets anteriores, el centro de ayuda y las macros para responder con su voz y seguir sus políticas.
• Implementación progresiva Comience con la IA redactando respuestas para su revisión, luego expanda a la autonomía total a medida que se demuestre.

¿La mejor parte? eesel aprende su negocio en minutos, no en semanas. Conéctenos a su instancia de Zendesk e inmediatamente comprenderemos su tono, los problemas comunes y los flujos de trabajo a partir de sus datos existentes.

Si está buscando reducir el volumen de tickets, acelerar los tiempos de respuesta y liberar a sus agentes humanos para los problemas complejos que realmente los necesitan, pruebe eesel AI para Zendesk.