Vor Kurzem aufgerufene Suchen


Keine vor kurzem aufgerufene Suchen

Amy Dee's Avatar

Amy Dee

Beigetreten 14. Apr. 2021

·

Letzte Aktivität 18. Nov. 2024

Zendesk Customer Care

Folge ich

0

Follower

4

Gesamtaktivitäten

86

Stimmen

29

Abonnements

18

AKTIVITÄTSÜBERSICHT

Neueste Aktivität von Amy Dee

Amy Dee hat einen Beitrag erstellt

BeitragHilfe zu E-Mail

Frage

Wie werden eingehende E-Mails mit Tickets verknüpft?

Antwort

Wenn eine eingehende E-Mail eingeht, prüft Zendesk, ob sie Hinweise auf vorhandene Tickets enthält. Das bestimmt, ob die E-Mail als Ticketaktualisierung hinzugefügt oder ein neues Ticket erstellt wird.

Zendesk prüft drei Hauptreferenzen für Threading-E-Mails:

1. Elemente im E-Mail-Header

Im E-Mail-Header wird die References und In-Reply-To enthalten die Nachrichten-IDs für andere E-Mails im gleichen Thread. Zendesk sucht nach diesen Nachrichten-IDs in vorhandenen Tickets. Wenn Zendesk eine Übereinstimmung findet, wird die E-Mail als Antwort zum passenden Ticket hinzugefügt.

Der E-Mail-Header ist in der E-Mail-Quelle sichtbar. Lesen Sie den Beitrag: Anzeigen der HTML- und Originalquelle für eingehende Tickets.

Weitere Informationen zur Behebung von Fehlern in E-Mail-Headern finden Sie im folgenden Beitrag: Warum werden E-Mails im falschen Ticket angezeigt?

2. Codierte IDs im Nachrichtentext

Eine codierte ID ist ein eindeutiger Verweis auf ein bestimmtes Ticket. Zendesk fügt standardmäßig in jeder abgehenden Benachrichtigungs-E-Mail eine codierte ID hinzu, anhand der die Antworten dem richtigen Ticket zugeordnet werden können.

Eine codierte ID kann zu jeder beliebigen E-Mail hinzugefügt werden, nicht nur zu von Zendesk generierten E-Mails. Die codierte ID muss in eckigen Klammern stehen [1G7EOR-0Q2J] damit Zendesk die ID erkennen kann.

3. Codierte IDs in der Zendesk-Empfangsadresse

Zendesk-Support-E-Mail-Adressen können Aliasse verwenden, die die codierte ID enthalten. z. B. die E-Mail-Adresse zu einem Ticket mit codierter ID 1G7EOR-0Q2J in der mondocam-Subdomäne wie folgt aus: support+id1G7EOR-0Q2J@mondocam.zendesk.com.

Diese Struktur sorgt dafür, dass die E-Mail auch dann im entsprechenden Ticket angezeigt wird, wenn keine anderen Bezüge vorhanden sind.

Diese Verwendung codierter IDs funktioniert nur für Zendesk-Support-E-Mail-Adressen, nicht für externe Supportadressen.

Wie greife ich auf die codierte ID zu?

Sie können die codierte ID eines Tickets wie folgt bestimmen:

  • Verwenden Sie die {{ticket.encoded_id}} in Makros oder Ticketkommentaren den Platzhalter ein, damit die codierte ID angezeigt wird.
  • Verwenden Sie die Tickets API , um die anzuzeigen encoded_id enthalten. Auf diese Weise können API-Workflows auf die codierte ID zugreifen, ohne Ticketkommentare zu manipulieren.
Hinweis: Im Gegensatz zu standardmäßigen Ticketkommentaren verwenden Kommentare aus Nebenkonversationen die Conversation ID aus dem E-Mail-Text entfernt Reference oder In-Reply-To im E-Mail-Header.

Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.

Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.

Bearbeitet 17. Dez. 2024 · Amy Dee

1

Follower

1

Stimme

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

KommentarMeasuring 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!
 

Kommentar anzeigen · Gepostet 28. Aug. 2024 · Amy Dee

0

Follower

1

Stimme

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

Community-Kommentar 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!

Kommentar anzeigen · Gepostet 02. Mai 2024 · Amy Dee

0

Follower

0

Stimmen

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

KommentarMeasuring 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!

Kommentar anzeigen · Gepostet 01. Mai 2024 · Amy Dee

0

Follower

0

Stimmen

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

Community-Kommentar 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!

Kommentar anzeigen · Gepostet 01. Mai 2024 · Amy Dee

0

Follower

0

Stimmen

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

KommentarMeasuring 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!

Kommentar anzeigen · Gepostet 15. Apr. 2024 · Amy Dee

0

Follower

0

Stimmen

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

KommentarMeasuring 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!

Kommentar anzeigen · Gepostet 10. Apr. 2024 · Amy Dee

0

Follower

0

Stimmen

0

Kommentare


Amy Dee hat einen Beitrag erstellt

BeitragHilfe zu E-Mail

Symptome

  • Endbenutzer erhalten von Microsoft eine Benachrichtigung über Unzustellbarkeit, nachdem sie eine E-Mail an eine Supportadresse gesendet haben.
  • Die Benachrichtigung beginnt mit: Nachricht konnte nicht zugestellt werden.
  • Die Nachricht enthält einen Fehler- oder Statuscode mit 550 5.7.x.
  • Die E-Mails erreichen Zendesk nicht.

Der Text der Nachricht ist je nach Problem unterschiedlich. Das Hauptproblem bleibt jedoch das gleiche: Die E-Mail des Benutzers wurde abgewiesen, bevor sie Zendesk erreichen konnte.

Lösungsschritte

Diese Fehler werden von Microsoft generiert, nicht von Zendesk. Zendesk kann bei der Behebung dieser Fehler nicht weiterhelfen. Wenn Benutzer plötzlich Unzustellbarkeitsbenachrichtigungen und Fehlermeldungen melden, wenden Sie sich an Ihren E-Mail-Administrator. Dieser muss die Fehlermeldung und Ihre E-Mail-Konfiguration überprüfen.

Hinweis: Diese Art von Fehler kann bei einer Supportadresse auftreten, die zuvor funktioniert hat. Das bedeutet in der Regel, dass sich etwas geändert hat. Wenn Microsoft beispielsweise eine neue Richtlinie für die E-Mail-Weiterleitung implementiert, erfüllen vorhandene Adressen die neuen Anforderungen ohne eine Aktualisierung möglicherweise nicht.

Der E-Mail-Administrator Ihrer E-Mail-Domäne kann diese Fehler untersuchen und beheben. Möglicherweise hat Microsoft seine Richtlinien zur automatischen E-Mail-Weiterleitungaktualisiert, und dies betrifft möglicherweise Supportadressen, die seit langem reibungslos funktionieren. Weitere Informationen finden Sie in diesem Beitrag: Weiterleiten eingehender E-Mails von Ihrer vorhandenen E-Mail-Adresse an Zendesk Support.

Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.

Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.

Bearbeitet 26. März 2024 · Amy Dee

1

Follower

1

Stimme

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

Community-Kommentar 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!

Kommentar anzeigen · Gepostet 16. Juni 2023 · Amy Dee

0

Follower

3

Stimmen

0

Kommentare


Amy Dee hat einen Kommentar hinterlassen

KommentarExplore 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!

Kommentar anzeigen · Gepostet 12. Juni 2023 · Amy Dee

0

Follower

0

Stimmen

0

Kommentare