zendesk-ticket-requesters-vs-submitters
Written by
eesel Team
Last edited 25 février 2026
{
"title": "Demandeur vs. soumetteur de ticket Zendesk : Quelle est la différence ?",
"slug": "zendesk-ticket-requesters-vs-submitters",
"locale": "fr",
"date": "2026-02-25",
"updated": "2026-02-25",
"template": "default",
"excerpt": "Vous êtes confus au sujet des champs demandeur et soumetteur de Zendesk ? Ce guide explique la différence, les scénarios courants où ils divergent et comment utiliser chaque champ efficacement.",
"categories": [
"Zendesk",
"Guides"
],
"tags": [
"Zendesk",
"Customer Support",
"Ticket Management",
"Help Desk"
],
"readTime": 8,
"author": 16,
"reviewer": 14,
"seo": {
"title": "Demandeur vs. soumetteur de ticket Zendesk : Quelle est la différence ?",
"description": "Vous êtes confus au sujet des champs demandeur et soumetteur de Zendesk ? Ce guide explique la différence, les scénarios courants où ils divergent et comment utiliser chaque champ efficacement.",
"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": "Image de bannière pour Demandeur vs. soumetteur de ticket Zendesk : Quelle est la différence ?",
"coverImageWidth": 1920,
"coverImageHeight": 1080,
"faqs": {
"heading": "Foire aux questions",
"type": "blog",
"answerType": "html",
"faqs": [
{
"question": "Puis-je modifier le soumetteur d'un ticket Zendesk ?",
"answer": "Non. Contrairement au champ demandeur, le soumetteur ne peut pas être modifié après la création d'un ticket. Le soumetteur est définitivement défini comme l'utilisateur qui a créé le ticket."
},
{
"question": "Pourquoi mon intégration API affiche-t-elle le mauvais soumetteur ?",
"answer": "Lors de la création de tickets via API, le soumetteur est déterminé par les informations d'identification utilisées pour effectuer la requête, et non par le champ demandeur que vous avez défini. Si vous utilisez un compte de service ou un client OAuth, ce compte devient le soumetteur. Pour suivre l'utilisateur final réel, utilisez plutôt le champ demandeur."
},
{
"question": "Comment puis-je suivre quel agent a créé un ticket au nom d'un client ?",
"answer": "Utilisez le champ soumetteur dans les rapports Zendesk Explore. Le soumetteur affichera le compte d'utilisateur de l'agent, tandis que le demandeur affichera le client. Vous pouvez filtrer par « Rôle du soumetteur » pour exclure les utilisateurs finaux et ne voir que les tickets créés par les agents."
},
{
"question": "Quelle est la différence entre le demandeur et le soumetteur dans les règles de gestion Zendesk ?",
"answer": "Le demandeur fait référence à la personne à qui le ticket est destiné (généralement le client). Le soumetteur fait référence à la personne qui a créé le ticket. Dans les déclencheurs et les automatisations, « l'utilisateur actuel est le demandeur » se comporte différemment de « l'utilisateur actuel est le soumetteur » : assurez-vous de référencer le bon champ pour la logique de votre flux de travail."
},
{
"question": "Un agent peut-il être le demandeur d'un ticket ?",
"answer": "Oui. Bien que les demandeurs soient généralement des clients, les agents peuvent également être des demandeurs. Cela se produit couramment avec les services d'assistance internes où les employés (qui peuvent avoir des comptes d'agent) soumettent des tickets à d'autres services."
}
],
"supportLink": null
}
}
---
Si vous avez déjà regardé un ticket Zendesk et vous êtes demandé pourquoi il y avait deux champs différents qui semblaient signifier la même chose, vous n'êtes pas seul. Les champs demandeur et soumetteur déroutent beaucoup d'équipes de support, et la distinction est plus importante que vous ne le pensez.
Décomposons cela. Le demandeur est la personne *pour* qui le ticket est destiné. Le soumetteur est celui qui a *créé* le ticket. La plupart du temps, il s'agit de la même personne, mais lorsqu'elles sont différentes, comprendre pourquoi peut vous éviter des maux de tête liés aux rapports et des incidents de flux de travail.
Voici ce que vous devez savoir sur chaque champ, quand ils divergent et comment les utiliser efficacement dans vos opérations de support.
## Qu'est-ce qu'un demandeur de ticket dans Zendesk ?
Le demandeur est la personne qui demande de l'aide. C'est celle qui a le problème qui doit être résolu.
Pour la plupart des entreprises qui utilisent Zendesk, le demandeur est un client. Mais les demandeurs peuvent aussi être des agents de votre organisation. Peut-être qu'un employé interne a soumis un ticket à votre service d'assistance informatique, ou qu'un agent a escaladé quelque chose au nom d'un collègue.
Le champ demandeur est important parce que :
- **Il reçoit toutes les communications relatives au ticket** : chaque commentaire public, mise à jour de statut et notification de résolution est envoyé au demandeur.
- **Il détermine la visibilité du ticket** : dans le portail client de Zendesk, les utilisateurs ne peuvent voir que les tickets où ils sont répertoriés comme demandeur (à moins qu'ils ne fassent partie d'une organisation partagée).
- **Il pilote les règles de gestion** : vos déclencheurs, automatisations et vues filtrent ou agissent souvent en fonction du demandeur.
- **Il peut être modifié** : si un ticket a été créé pour la mauvaise personne, les agents disposant des autorisations appropriées peuvent mettre à jour le champ demandeur.
La chose essentielle à retenir est que le demandeur définit à qui est destinée l'interaction de support, et pas nécessairement qui l'a initiée.
## Qu'est-ce qu'un soumetteur de ticket dans Zendesk ?
Le soumetteur est l'utilisateur qui a réellement créé le ticket. C'est la personne qui a cliqué sur « Soumettre » ou qui a envoyé l'e-mail qui est devenu un ticket.
Par défaut, le soumetteur d'un ticket est le même que le demandeur. Lorsqu'un client envoie un e-mail à votre adresse de support ou remplit votre formulaire web, il demande de l'aide *et* crée le ticket. Les deux champs sont donc remplis avec son enregistrement d'utilisateur.
Mais voici la différence essentielle : **le soumetteur ne peut pas être modifié après la création du ticket**. Une fois que ce ticket existe dans votre système, le champ soumetteur est verrouillé.
Le champ soumetteur est important pour :
- **La responsabilité interne** : savoir quel agent a créé un ticket au nom de quelqu'un d'autre.
- **Le suivi des API et des intégrations** : identifier quel système ou compte d'utilisateur a créé des tickets par programmation.
- **Les pistes d'audit** : comprendre la véritable origine d'une demande de support.
- **Le routage du flux de travail** : certaines organisations utilisent les données du soumetteur pour router ou catégoriser les tickets.
Considérez le soumetteur comme le champ de la « trace écrite ». Il vous indique qui (ou quoi) a réellement ouvert le ticket, quel que soit le destinataire.
## Quand le demandeur et le soumetteur sont différents
Alors, quand ces champs divergent-ils réellement ? Voici les scénarios les plus courants :
**Agents de centre d'appels créant des tickets à partir d'appels téléphoniques**
Un client appelle votre ligne de support. L'agent l'aide et crée un ticket pour documenter l'interaction. Le client est le demandeur (il avait besoin d'aide), mais l'agent est le soumetteur (il a créé le ticket).
**Assistants de direction soumettant des demandes au nom de cadres**
Un assistant remplit un formulaire de support pour son responsable. Le cadre est le demandeur, mais le compte d'utilisateur de l'assistant est le soumetteur.
**Services d'assistance informatique internes**
Un employé se rend au bureau informatique et demande de l'aide. Le membre du personnel informatique crée un ticket. L'employé est le demandeur, le membre du personnel informatique est le soumetteur.
**Scénarios d'API et d'intégration**
Votre CRM, chatbot ou intégration de formulaire crée des tickets automatiquement. L'utilisateur final est le demandeur, mais le compte de service ou le client OAuth de l'intégration est le soumetteur.
Ce dernier scénario est source de beaucoup de confusion. Les développeurs qui créent des intégrations s'attendent parfois à définir le soumetteur sur l'ID de l'utilisateur final, mais Zendesk attribue le soumetteur en fonction des informations d'identification utilisées pour effectuer l'appel API. Si votre intégration utilise un compte de service, ce compte devient le soumetteur pour chaque ticket qu'il crée.
## Comment afficher et modifier le demandeur
Vous pouvez trouver le champ demandeur dans le panneau des propriétés du ticket sur le côté droit de n'importe quel ticket dans l'espace de travail de l'agent. C'est l'un des principaux champs affichés en haut.
Pour modifier le demandeur :
1. Ouvrez le ticket dans Zendesk.
2. Cliquez sur le champ demandeur (il peut s'afficher sous forme de liste déroulante ou de champ modifiable en fonction de vos autorisations).
3. Recherchez et sélectionnez l'utilisateur correct.
4. Enregistrez vos modifications.
Tous les agents ne peuvent pas modifier les demandeurs par défaut. Les administrateurs doivent activer cette autorisation dans le Centre d'administration :
1. Accédez à **Objets et règles** > **Tickets** > **Paramètres**.
2. Cliquez sur **CC et abonnés sur les tickets** pour développer.
3. Cochez **Autoriser les agents à modifier le demandeur**.
4. Enregistrez.
La modification du demandeur affecte les personnes qui reçoivent les notifications et celles qui peuvent voir le ticket dans leur portail client. Cela n'affecte pas le champ soumetteur, qui reste verrouillé.
## Comment identifier le soumetteur pour le reporting
Contrairement au demandeur, vous ne pouvez pas modifier le soumetteur. Mais vous pouvez utiliser ce champ pour le reporting et le filtrage.
Dans Zendesk Explore, les ensembles de données Tickets, Historique des mises à jour et SLA incluent tous des attributs sur le soumetteur. Vous pouvez créer des rapports indiquant :
- Quels agents créent le plus de tickets au nom des clients.
- Quel pourcentage de tickets sont soumis par les utilisateurs finaux par rapport aux agents.
- Les tendances des sources de création de tickets au fil du temps.
Pour filtrer les tickets par rôle de soumetteur dans Explore :
1. Créez une nouvelle requête dans l'ensemble de données Tickets.
2. Ajoutez un filtre pour **Rôle du soumetteur**.
3. Sélectionnez les rôles que vous souhaitez inclure ou exclure.
Ceci est particulièrement utile pour les services d'assistance internes qui souhaitent suivre le nombre de tickets créés par les agents par rapport à ceux soumis directement par les employés via les canaux en libre-service.
## Erreurs courantes et comment les éviter
**Supposer que le demandeur et le soumetteur sont toujours les mêmes**
Cela conduit à la confusion lorsque les tickets semblent provenir d'agents mais sont en fait destinés aux clients. Vérifiez toujours les deux champs si vous n'êtes pas sûr à qui appartient un ticket.
**Ne pas suivre le soumetteur pour la responsabilité interne**
Si vos agents créent fréquemment des tickets au nom des clients, vous voudrez peut-être suivre cela. Envisagez de créer un champ personnalisé ou d'utiliser des balises pour identifier les tickets créés par les agents par rapport aux clients, surtout si vous avez besoin de ces données pour les indicateurs de performance.
**Intégrations API utilisant le mauvais champ**
Les développeurs essaient parfois de définir l'ID du soumetteur lors de la création de tickets via API. Cela ne fonctionne pas : le soumetteur est déterminé par les informations d'identification. Pour définir à qui est destiné un ticket, utilisez plutôt le champ demandeur.
**Confusion dans les règles de gestion**
Assurez-vous que vos déclencheurs et automatisations référencent le bon champ. Un déclencheur qui se déclenche en fonction de « l'utilisateur actuel est le demandeur » se comporte très différemment de celui basé sur « l'utilisateur actuel est le soumetteur ».
**Meilleure pratique :** En cas de doute, utilisez le demandeur pour la logique orientée client et le soumetteur pour le suivi interne ou à des fins d'audit.
## Rationalisez votre flux de travail de tickets avec eesel AI
Comprendre la différence entre le demandeur et le soumetteur n'est qu'un élément de la gestion d'une opération de support efficace. Le plus grand défi est de gérer efficacement tous ces tickets une fois qu'ils atteignent votre file d'attente.
C'est là que nous intervenons. Chez eesel AI, nous avons créé un coéquipier d'IA qui s'intègre directement à Zendesk pour prendre en charge la lourde tâche de la gestion des tickets.
Voici comment nous aidons :
- **Résolution autonome des tickets** : notre agent d'IA peut gérer les tickets de support de première ligne de bout en bout, de la lecture de la demande à l'envoi de la réponse. Les déploiements matures atteignent jusqu'à 81 % de résolution autonome.
- **Tri intelligent** : le tri par IA balise, route et hiérarchise automatiquement les tickets en fonction du contenu, et pas seulement des mots-clés. Il comprend ce dont les clients ont réellement besoin.
- **Gestion cohérente** : l'IA apprend de vos tickets passés, de votre centre d'aide et de vos macros pour répondre avec votre voix et suivre vos politiques.
- **Déploiement progressif** : commencez par l'IA qui rédige des réponses pour examen, puis passez à l'autonomie complète au fur et à mesure qu'elle fait ses preuves.
Le meilleur ? eesel apprend votre activité en quelques minutes, pas en quelques semaines. Connectez-nous à votre instance Zendesk et nous comprendrons immédiatement votre ton, vos problèmes courants et vos flux de travail à partir de vos données existantes.
Si vous cherchez à réduire le volume de tickets, à accélérer les temps de réponse et à libérer vos agents humains pour les problèmes complexes qui ont réellement besoin d'eux, [essayez eesel AI pour Zendesk](https://www.eesel.ai/integration/zendesk).
Partager cet article
Article by
