Pesquisas recentes


Sem pesquisas recentes

Amy Dee's Avatar

Amy Dee

Entrou em 14 de abr. de 2021

·

Última atividade em 18 de nov. de 2024

Zendesk Customer Care

Seguindo

0

Seguidores

4

Atividade total

86

Votos

29

Assinaturas

18

VISÃO GERAL DA ATIVIDADE

Atividade mais recente por Amy Dee

Amy Dee criou um artigo,

ArtigoAjuda com e-mail

Pergunta

Como os e-mails recebidos são vinculados aos tickets?

Resposta

Quando um email é recebido, o Zendesk verifica se há referências a tickets existentes no email. Isso determina se o email será adicionado como uma atualização do ticket ou se um novo ticket será criado.

O Zendesk verifica três referências principais para a conversa de e-mails:

1. Elementos no cabeçalho do e-mail

No cabeçalho do e-mail, o References e In-Reply-To linhas contêm as IDs de mensagem para outros e-mails na mesma conversa. O Zendesk verificará essas IDs de mensagem nos tickets existentes. Se o Zendesk encontrar uma correspondência, o email será adicionado como resposta ao ticket correspondente.

O cabeçalho do email fica visível na origem do email. Consulte o artigo: Visualização do HTML e da fonte original dos tickets recebidos para obter detalhes.

Para obter mais informações sobre a solução de problemas de cabeçalhos de email, consulte o artigo: Por que os e-mails são enviados para o ticket errado?

2. IDs codificadas no corpo da mensagem

Uma ID codificada é uma referência exclusiva a um ticket específico. O Zendesk inclui uma ID codificada por padrão em cada email de notificação de saída, o que ajuda a fazer a correspondência das respostas com o ticket correto.

Uma ID codificada pode ser adicionada a qualquer corpo de email e não é exclusiva dos emails gerados pelo Zendesk. A ID codificada deve aparecer entre colchetes [1G7EOR-0Q2J] para que o Zendesk detecte a ID.

3. IDs codificadas no endereço de recebimento do Zendesk

Os endereços de e-mail de suporte do Zendesk podem usar alias que incluam a ID codificada. Por exemplo, o endereço de e-mail de um ticket com ID codificado 1G7EOR-0Q2J no subdomínio mondocam apareceria assim: support+id1G7EOR-0Q2J@mondocam.zendesk.com.

Essa estrutura ajuda a permitir que o email seja conectado ao ticket correspondente, mesmo que nenhuma outra referência esteja presente.

Esse uso de IDs codificadas funciona apenas para endereços de email de suporte do Zendesk e não para endereços de suporte externos.

Como acessar a ID codificada

Você pode encontrar a ID codificada de um ticket seguindo as etapas abaixo:

  • Use o {{ticket.encoded_id}} placeholder em macros ou comentários do ticket para mostrar a ID codificada.
  • Use a API de tickets para visualizar os encoded_id . Essa abordagem permite que os fluxos de trabalho da API acessem a ID codificada sem manipular os comentários do ticket.
Observação: Ao contrário dos comentários de ticket padrão, para conversar por e-mail, os comentários de conversas paralelas usam a tag Conversation ID do corpo do e-mail, e não Reference ou In-Reply-To no cabeçalho do e-mail.

Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.

Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.

Editado 17 de dez. de 2024 · Amy Dee

1

Seguidor

1

Votos

0

Comentários


Amy Dee comentou,

ComentárioMeasuring 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!
 

Exibir comentário · Publicado 28 de ago. de 2024 · Amy Dee

0

Seguidores

1

Votos

0

Comentários


Amy Dee comentou,

Comentário na comunidade 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!

Exibir comentário · Publicado 02 de mai. de 2024 · Amy Dee

0

Seguidores

0

Votos

0

Comentários


Amy Dee comentou,

ComentárioMeasuring 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!

Exibir comentário · Publicado 01 de mai. de 2024 · Amy Dee

0

Seguidores

0

Votos

0

Comentários


Amy Dee comentou,

Comentário na comunidade 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!

Exibir comentário · Publicado 01 de mai. de 2024 · Amy Dee

0

Seguidores

0

Votos

0

Comentários


Amy Dee comentou,

ComentárioMeasuring 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!

Exibir comentário · Publicado 15 de abr. de 2024 · Amy Dee

0

Seguidores

0

Votos

0

Comentários


Amy Dee comentou,

ComentárioMeasuring 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!

Exibir comentário · Publicado 10 de abr. de 2024 · Amy Dee

0

Seguidores

0

Votos

0

Comentários


Amy Dee criou um artigo,

ArtigoAjuda com e-mail

Sintomas do problema

  • Os usuários finais recebem uma notificação de devolução da Microsoft após enviarem um email para um endereço de suporte.
  • A notificação começa com: Sua mensagem não pode ser entregue.
  • A mensagem inclui um código de erro ou status com 550 5.7.x.
  • Os emails não chegam à Zendesk.

O texto da mensagem será diferente para cada problema subjacente. No entanto, o principal problema continua o mesmo: o email do usuário foi rejeitado antes de chegar à Zendesk.

Etapas de resolução

Esses erros são gerados pela Microsoft, não pela Zendesk. A Zendesk não pode ajudar na resolução desses erros. Se seus usuários relatarem notificações de devolução e mensagens de erro, entre em contato com o administrador de email. Eles precisarão revisar a mensagem de erro e sua configuração de email.

Observação: Esse tipo de erro pode ocorrer em um endereço de suporte que estava funcionando anteriormente. Isso normalmente significa que algo mudou. Por exemplo, se a Microsoft implementar uma nova política para encaminhamento de email, os endereços existentes podem não atender aos novos requisitos sem uma atualização.

O administrador de email do seu domínio de email pode investigar e resolver esses erros. A Microsoft pode ter atualizado suas políticas sobre o encaminhamento automático de emaile isso pode afetar os endereços de suporte que estão funcionando sem problemas há muito tempo. Para mais informações, consulte este artigo: Encaminhamento dos e-mails recebidos no seu endereço de e-mail existente para o Zendesk Support.

Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.

Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.

Editado 26 de mar. de 2024 · Amy Dee

1

Seguidor

2

Votos

0

Comentários


Amy Dee comentou,

Comentário na comunidade 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!

Exibir comentário · Publicado 16 de jun. de 2023 · Amy Dee

0

Seguidores

3

Votos

0

Comentários


Amy Dee comentou,

ComentárioExplore 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!

Exibir comentário · Publicado 12 de jun. de 2023 · Amy Dee

0

Seguidores

0

Votos

0

Comentários