zendesk-ticket-requesters-vs-submitters
Written by
eesel Team
Last edited 25 febrero 2026
{
"title": "Solicitantes vs. remitentes de tickets de Zendesk: ¿Cuál es la diferencia?",
"slug": "zendesk-ticket-requesters-vs-submitters",
"locale": "es",
"date": "2026-02-25",
"updated": "2026-02-25",
"template": "default",
"excerpt": "¿Confundido acerca de los campos de solicitante y remitente de Zendesk? Esta guía explica la diferencia, los escenarios comunes donde divergen y cómo usar cada campo de manera efectiva.",
"categories": [
"Zendesk",
"Guides"
],
"tags": [
"Zendesk",
"Customer Support",
"Ticket Management",
"Help Desk"
],
"readTime": 8,
"author": 16,
"reviewer": 14,
"seo": {
"title": "Solicitantes vs. remitentes de tickets de Zendesk: ¿Cuál es la diferencia?",
"description": "¿Confundido acerca de los campos de solicitante y remitente de Zendesk? Esta guía explica la diferencia, los escenarios comunes donde divergen y cómo usar cada campo de manera efectiva.",
"image": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-fba321c3-cc08-4f2c-bf28-10d4a691dae6"
},
"coverImage": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-fba321c3-cc08-4f2c-bf28-10d4a691dae6",
"coverImageAlt": "Imagen de banner para Solicitantes vs. remitentes de tickets de Zendesk: ¿Cuál es la diferencia?",
"coverImageWidth": 1920,
"coverImageHeight": 1080,
"faqs": {
"heading": "Preguntas frecuentes",
"type": "blog",
"answerType": "html",
"faqs": [
{
"question": "¿Puedo cambiar el remitente de un ticket de Zendesk?",
"answer": "No. A diferencia del campo de solicitante, el remitente no se puede cambiar después de que se crea un ticket. El remitente se establece permanentemente en el usuario que creó el ticket."
},
{
"question": "¿Por qué mi integración de API muestra el remitente incorrecto?",
"answer": "Cuando se crean tickets a través de la API, el remitente está determinado por las credenciales de autenticación utilizadas para realizar la solicitud, no por el campo de solicitante que establezca. Si está utilizando una cuenta de servicio o un cliente de OAuth, esa cuenta se convierte en el remitente. Para rastrear al usuario final real, utilice el campo de solicitante en su lugar."
},
{
"question": "¿Cómo puedo rastrear qué agente creó un ticket en nombre de un cliente?",
"answer": "Utilice el campo de remitente en los informes de Zendesk Explore. El remitente mostrará la cuenta de usuario del agente, mientras que el solicitante mostrará el cliente. Puede filtrar por 'Rol de remitente' para excluir a los usuarios finales y ver solo los tickets creados por los agentes."
},
{
"question": "¿Cuál es la diferencia entre solicitante y remitente en las reglas de negocio de Zendesk?",
"answer": "El solicitante se refiere a para quién es el ticket (generalmente el cliente). El remitente se refiere a quién creó el ticket. En los disparadores y las automatizaciones, 'el usuario actual es el solicitante' se comporta de manera diferente a 'el usuario actual es el remitente'; asegúrese de hacer referencia al campo correcto para la lógica de su flujo de trabajo."
},
{
"question": "¿Puede un agente ser el solicitante de un ticket?",
"answer": "Sí. Si bien los solicitantes suelen ser clientes, los agentes también pueden ser solicitantes. Esto sucede comúnmente con los centros de asistencia internos donde los empleados (que pueden tener cuentas de agente) envían tickets a otros departamentos."
}
],
"supportLink": null
}
}
---
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](https://www.eesel.ai/integration/zendesk).
Compartir esta entrada
Article by
