Ricerche recenti
Nessuna ricerca recente

Amy Dee
Data ingresso 14 apr 2021
·
Ultima attività 18 nov 2024
Seguiti
0
Follower
4
Attività totali
86
Voti
29
Abbonamenti
18
PANORAMICA ATTIVITÀ
BADGE
ARTICOLI
POST
COMMENTI NELLA COMMUNITY
COMMENTI AGLI ARTICOLI
PANORAMICA ATTIVITÀ
Ultima attività di Amy Dee
Amy Dee ha creato un articolo,
Domanda
In che modo le email in ingresso vengono inoltrate ai ticket?
Risposta
Quando viene ricevuta un’email in ingresso, Zendesk controlla l’email per trovare riferimenti a ticket esistenti. Determina se l’email verrà aggiunta come aggiornamento del ticket o se verrà creato un nuovo ticket.
Zendesk controlla tre riferimenti principali per le email di threading:
- Elementi nell’intestazione dell’email
- ID codificati nel corpo del messaggio
- ID codificati nell’indirizzo di ricezione Zendesk
1. Elementi nell’intestazione dell’email
Nell’intestazione dell’email, References
e In-Reply-To
le righe contengono gli ID dei messaggi per le altre email nello stesso thread. Zendesk verificherà la presenza di tali ID messaggio nei ticket esistenti. Se Zendesk trova una corrispondenza, l’email verrà aggiunta come risposta al ticket corrispondente.
L’intestazione dell’email è visibile nell’origine dell’email. Vedi l'articolo: Visualizzazione del codice HTML e dell’origine originale per i ticket in ingresso per i dettagli.
Per ulteriori informazioni sulla risoluzione dei problemi relativi alle intestazioni email, consulta l'articolo: Perché le email vengono indirizzate al ticket sbagliato?
2. ID codificati nel corpo del messaggio
Un ID codificato è un riferimento univoco a un ticket specifico. Zendesk include un ID codificato per impostazione predefinita in ogni email di notifica in uscita, che aiuta ad abbinare le risposte al ticket corretto.
Un ID codificato può essere aggiunto a qualsiasi corpo email e non è esclusivo delle email generate da Zendesk. L’ID codificato deve essere racchiuso tra parentesi quadre [1G7EOR-0Q2J]
per consentire a Zendesk di rilevare l’ID.
3. ID codificati nell’indirizzo di ricezione Zendesk
Gli indirizzi email dell’assistenza Zendesk possono usare alias che includono l’ID codificato. Ad esempio, l’indirizzo email di un ticket con ID codificato 1G7EOR-0Q2J
nel sottodominio mondocam apparirà così: support+id1G7EOR-0Q2J@mondocam.zendesk.com
.
Questa struttura consente all’email di indirizzarsi al ticket corrispondente, anche se non sono presenti altri riferimenti.
Questo uso di ID codificati funziona solo per gli indirizzi email di assistenza Zendesk e non per gli indirizzi di assistenza esterni.
Come accedere all’ID codificato
Puoi trovare l’ID codificato di un ticket procedendo nel seguente modo:
- Usa il
{{ticket.encoded_id}}
segnaposto nelle macro o nei commenti dei ticket per mostrare l’ID codificato. - Usa l’ API Tickets per visualizzare il
encoded_id
parametro. Questo approccio consente ai workflow API di accedere all’ID codificato senza manipolare i commenti dei ticket.
Conversation ID
dal corpo dell’email e non Reference
o In-Reply-To
nell’intestazione dell’email.Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.
Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.
Data ultima modifica: 17 dic 2024 · Amy Dee
1
Follower
1
Voto
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 28 ago 2024 · Amy Dee
0
Follower
1
Voto
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 02 mag 2024 · Amy Dee
0
Follower
0
Voti
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 01 mag 2024 · Amy Dee
0
Follower
0
Voti
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 01 mag 2024 · Amy Dee
0
Follower
0
Voti
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 15 apr 2024 · Amy Dee
0
Follower
0
Voti
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 10 apr 2024 · Amy Dee
0
Follower
0
Voti
0
Commenti
Amy Dee ha creato un articolo,
Sintomi del problema
- Gli utenti finali ricevono una notifica di rimbalzo da Microsoft dopo aver inviato un’email a un indirizzo di assistenza.
- La notifica inizia con: Impossibile consegnare il messaggio.
- Il messaggio include un errore o un codice di stato con
550 5.7.x
. - Le email non raggiungono Zendesk.
Il testo del messaggio sarà diverso per ciascun problema sottostante. Tuttavia, il problema principale rimane lo stesso: l'email dell'utente è stata rifiutata prima che potesse raggiungere Zendesk.
Passaggi per la risoluzione del problema
Questi errori sono generati da Microsoft, non da Zendesk. Zendesk non può aiutare a risolvere questi errori. Se gli utenti segnalano improvvisamente notifiche di mancato recapito e messaggi di errore, contatta il tuo amministratore email. Dovranno esaminare il messaggio di errore e la configurazione dell’indirizzo email.
L’amministratore email del tuo dominio email può indagare e risolvere questi errori. È possibile che Microsoft abbia aggiornato le politiche relative all’inoltro automatico delle emaile ciò potrebbe influire sugli indirizzi di assistenza che funzionano correttamente da molto tempo. Per ulteriori informazioni, leggi il seguente articolo: Inoltro delle email in ingresso dall’indirizzo email esistente a Zendesk Support.
Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.
Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.
Data ultima modifica: 26 mar 2024 · Amy Dee
1
Follower
1
Voto
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 16 giu 2023 · Amy Dee
0
Follower
3
Voti
0
Commenti
Amy Dee ha commentato,
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!
Visualizza commento · Data ultimo post: 12 giu 2023 · Amy Dee
0
Follower
0
Voti
0
Commenti