Recherches récentes


Pas de recherche récente

Amy Dee's Avatar

Amy Dee

Adhésion le 14 avr. 2021

·

Dernière activité le 18 nov. 2024

Zendesk Customer Care

Suivis

0

Abonnés

4

Activité totale

86

Votes

29

Abonnements

18

APERÇU DES ACTIVITÉS

Dernière activité effectuée par Amy Dee

Amy Dee a créé un article,

ArticleE-mail - Conseils et dépannage

Question

Comment les e-mails entrants sont-ils dirigés vers les tickets ?

Réponse

À la réception d’un e-mail entrant, Zendesk le vérifie pour y rechercher des références à des tickets existants. Cela détermine si l'e-mail sera ajouté en tant que mise à jour de ticket ou si un nouveau ticket sera créé.

Zendesk vérifie trois références principales pour les e-mails de threads :

1. Éléments de l’en-tête d’e-mail

Dans l’en-tête du message, la balise References et In-Reply-To contiennent les ID de message pour les autres e-mails dans le même thread. Zendesk vérifie ces ID dans les tickets existants. Si Zendesk trouve une correspondance, l’e-mail sera ajouté en tant que réponse au ticket correspondant.

L’en-tête de l’e-mail est visible dans sa source. Consultez l’article : Affichage de la partie en HTML et de la source d’origine pour les tickets entrants pour en savoir plus.

Pour en savoir plus sur le dépannage des en-têtes d’e-mail, consultez l’article : Pourquoi les e-mails sont-ils intégrés au mauvais ticket ?

2. ID chiffrés dans le corps du message

Un ID chiffré est une référence unique à un ticket spécifique. Zendesk inclut un ID chiffré par défaut dans chaque notification par e-mail sortante, qui aide à trouver les réponses au bon ticket.

Un ID chiffré peut être ajouté à n’importe quel corps d’e-mail et n’est pas exclusif aux e-mails générés par Zendesk. L’ID chiffré doit s’afficher entre crochets [1G7EOR-0Q2J] pour que Zendesk le détecte.

3. ID chiffrés dans l’adresse de réception Zendesk

Les adresses e-mail d’assistance Zendesk peuvent utiliser des pseudos qui incluent l’ID chiffré. Par exemple, l’adresse e-mail pour un ticket avec ID chiffré 1G7EOR-0Q2J dans le sous-domaine mondocam : support+id1G7EOR-0Q2J@mondocam.zendesk.com.

Cette structure permet à l’e-mail d’être dirigé vers le ticket correspondant, même en l’absence d’autres références.

Cette utilisation d’ID chiffrés ne fonctionne que pour les adresses d’assistance Zendesk et pas pour les adresses d’assistance externes.

Comment accéder à l’ID chiffré

Vous trouverez l’ID chiffré d’un ticket en suivant les étapes ci-dessous :

  • Utilisez une {{ticket.encoded_id}} dans les macros ou les commentaires de ticket pour afficher l’ID chiffré.
  • Utilisez l’ API Tickets pour voir encoded_id . Cette approche permet aux workflows d’API d’accéder à l’ID chiffré sans manipuler les commentaires de ticket.
Remarque : Contrairement aux commentaires de ticket standard, pour les e-mails, les commentaires des conversations annexes utilisent le mot-clé Conversation ID du corps de l’e-mail et non Reference ou In-Reply-To dans l’en-tête du message.

Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.

Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.

Modification le 17 déc. 2024 · Amy Dee

1

Abonné

1

vote

0

Commentaire


Amy Dee a ajouté un commentaire,

CommentaireMeasuring success

Hi David Durr !

That is a valid security concern, and it's one that Zendesk shares. 

These account exports are always restricted to administrators. Agents don't have permission to see or initiate them. In addition, the account owner can restrict exports to administrators in specific email domains (or disable exports entirely). We have more information in this article: Restricting or deactivating account data exports

Those settings apply to the account export tools described in this article. It doesn't extend to the API. That said, while agents can access some data through the API, the Incremental Exports API endpoints are all admin-only as well.
 

I hope this helps!
 

Afficher le commentaire · Publication le 28 août 2024 · Amy Dee

0

Abonnés

1

vote

0

Commentaire


Amy Dee a ajouté un commentaire,

Commentaire de la communauté Feedback - Ticketing system (Support)

Hi Riah Lao -


Correct again! Zendesk functions - including views, automations, and analytics - use the full timestamp of the SLA target. That means views should consistently show a 1:40 ticket ahead of a 2:20 ticket, even though they both show a “2h” badge. The badge is just there as a quick visual indicator for agents.

 

I hope this helps!

Afficher le commentaire · Publication le 02 mai 2024 · Amy Dee

0

Abonnés

0

Votes

0

Commentaire


Amy Dee a ajouté un commentaire,

CommentaireMeasuring success

Hi there! 

Solving a ticket also fulfills all active SLA targets. This includes reply and update targets, which typically require a public comment. In your example, solving the ticket would fulfill the next reply time target, even if the agent didn't publicly respond to “Thank you.”

 

I hope this helps!

Afficher le commentaire · Publication le 01 mai 2024 · Amy Dee

0

Abonnés

0

Votes

0

Commentaire


Amy Dee a ajouté un commentaire,

Commentaire de la communauté Feedback - Ticketing system (Support)

Hi Riah Lao 

 

Thanks for the question! Your example is spot on. If the time remaining is 2:20, the badge will round down and show “2h.” If the time remaining is 2:40, the badge will round up and show “3h.” The exact halfway point - 2:30 - also rounds down to “2h.”

 

SLA badges have three different units: minutes, hours, and days. They start displaying the next unit up when that unit rounds to 2. For example, a target of 36 hours and 30 minutes would round down to a “36h” badge. A target of 36 hours and 31 minutes would round up to 37 hours, which then rounds up to “2d.”

 

There is no unit above “days." If you have a 2-year target, you'll see “730d” in the badge. There is also no unit below “minutes.” When the target is at or below 30 seconds, you'll see “now” in the badge.

 

I hope this helps!

Afficher le commentaire · Publication le 01 mai 2024 · Amy Dee

0

Abonnés

0

Votes

0

Commentaire


Amy Dee a ajouté un commentaire,

CommentaireMeasuring success

Hi Jon! 

At this time, there's no way to adjust how first reply time is measured. The system metric will start at ticket creation and end at the first public agent comment after that. The SLA target will wait for a public end user comment to get started (if the ticket was created with a private note).

 

You could create separate SLA policies for phone tickets. That wouldn't change the first reply target behavior, but it would allow you to manage those tickets and agent expectations separately.

I do have some good news. Our SLA team is hard at work on enhancements that will give users more flexibility over reply time SLA targets. That could help for workflows like yours. I recommend following our Announcements page for more information.

 

I hope this helps!

Afficher le commentaire · Publication le 15 avr. 2024 · Amy Dee

0

Abonnés

0

Votes

0

Commentaire


Amy Dee a ajouté un commentaire,

CommentaireMeasuring success

Hi Hannah! 
Schedules are applied to tickets, not SLA policies (or other business rules). For the SLA policy, you just choose between calendar and business hours for each target. If you choose business hours, the SLA will use the schedule associated with the ticket. 

 

Professional accounts only have one schedule, so there isn't much flexibility with business hours. Enterprise accounts can have multiple schedules, though, and they're controlled with business rules. That would allow you to create corresponding schedules and SLA policies for tickets in certain workflows.

We have more information about schedules here: Setting your schedule with business hours and holidays.

I hope this helps!

Afficher le commentaire · Publication le 10 avr. 2024 · Amy Dee

0

Abonnés

0

Votes

0

Commentaire


Amy Dee a créé un article,

ArticleE-mail - Conseils et dépannage

Symptômes

  • Les utilisateurs finaux reçoivent une notification de retour d'expérience de Microsoft après avoir envoyé un e-mail à un e-mail du service d'assistance.
  • La notification commence par : Impossible de livrer votre message.
  • Le message inclut un code d'erreur ou de statut avec 550 5.7.x.
  • Les e-mails ne parviennent pas à Zendesk.

Le texte du message sera différent pour chaque problème sous-jacent. Cependant, le principal problème reste le même : l'e-mail de l'utilisateur a été refusé avant de pouvoir atteindre Zendesk.

Étapes de résolution

Ces erreurs sont générées par Microsoft, pas Zendesk. Zendesk ne peut pas vous aider à résoudre ces erreurs. Si vos utilisateurs signalent soudain des notifications de retour en arrière et des messages d'erreur, contactez votre administrateur de messagerie. Il devra examiner le message d'erreur et votre configuration de messagerie en revue.

Remarque : Ce type d'erreur peut se produire avec une adresse du service d'assistance qui fonctionnait auparavant. Cela signifie généralement que quelque chose a changé. Par exemple, si Microsoft met en œuvre une nouvelle politique pour le transfert des e-mails, il est possible que les adresses existantes ne satisfassent pas aux nouvelles exigences sans mise à jour.

L'administrateur d'e-mail de votre domaine d'e-mail peut enquêter sur ces erreurs et les résoudre. Microsoft peut avoir mis à jour ses politiques concernant le transfert automatique des e-mailset cela peut affecter des adresses d'assistance qui fonctionnent correctement depuis longtemps. Pour en savoir plus, consultez cet article : Transfert des e-mails entrants de votre adresse e-mail existante à Zendesk Support.

Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.

Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.

Modification le 26 mars 2024 · Amy Dee

1

Abonné

1

vote

0

Commentaire


Amy Dee a ajouté un commentaire,

Commentaire de la communauté Feedback - Ticketing system (Support)

Hi @...! A business hours badge could work, but it would require total consistency: one schedule that never changes; no holidays (or exhaustively communicated holidays); all users in the same time zone; no SLA targets in calendar hours, ever.

If there's any variation in any of those points, a business hours badge becomes ambiguous. Multiple schedules, schedule changes, different regions, and different SLA policies all impact how much time is actually left on a target. Agents could no longer take the badge at face value.

Even if there is total consistency, SLA badges round their numbers to hours (or days) when the target is far enough away. This means two tickets could both have a "2 business hours" badge, but one is due Friday at 4:50pm while the other is due Monday at 9:10am. Agents should prioritize the Friday ticket, but they need an easy way to know which is which.

SLA badges in business hours put a burden on agents. Before agents can act on a badge, they'd need to interpret that number in relation to the schedule and their current time. That mental math is taxing, even in simple environments. In more complex environments, it's prohibitive. 

SLA badges are designed to quickly prioritize workflows. It's important to ensure that they're all on the same scale, regardless of account complexity, and that the scale is intuitive at a glance. That's why badges show real time remaining. This allows agents to see accurate deadlines, without any extra effort required.

I hope this helps!

Afficher le commentaire · Publication le 16 juin 2023 · Amy Dee

0

Abonnés

3

Votes

0

Commentaire


Amy Dee a ajouté un commentaire,

CommentaireExplore recipes

Hi Leif Cederblom! At this time, Explore only captures SLA durations after the target has been fulfilled. There is no way to create an Explore report that shows live SLA counters for breached tickets. 

This is due to how Explore syncs data. It isn't a live feed; it pulls data at periodic intervals. That means it has no way to maintain live durations for metrics. Explore can't tell whether an SLA has been fulfilled until after the next data sync, so durations would be stale.

If you need to monitor active SLAs in real time, we recommend using Views. You can export Views to CSV as well if needed. Explore is better suited for historic reporting.

I hope this helps!

Afficher le commentaire · Publication le 12 juin 2023 · Amy Dee

0

Abonnés

0

Votes

0

Commentaire