Pesquisas recentes
Sem pesquisas recentes

Robin Hoese
Entrou em 05 de mai. de 2021
·
Última atividade em 04 de mar. de 2022
Seguindo
0
Seguidores
0
Atividade total
14
Votos
9
Assinatura
1
VISÃO GERAL DA ATIVIDADE
MEDALHAS
ARTIGOS
PUBLICAÇÕES
COMENTÁRIOS NA COMUNIDADE
COMENTÁRIOS EM ARTIGOS
VISÃO GERAL DA ATIVIDADE
Atividade mais recente por Robin Hoese
Robin Hoese comentou,
I think the purpose of this feedback thread is to have the Zendesk behaviour changed, not to determine a workaround for badly implemented features via additional triggers.
Exibir comentário · Publicado 25 de set. de 2020 · Robin Hoese
0
Seguidores
2
Votos
0
Comentários
Robin Hoese comentou,
@..., while you're describing the use cases correctly, this is not how Zendesk currently behaves. The tool actively mixes behaviours, treating the a follow-up as a new case (without group assignment) as well as an existing case (with previously applied tags) at the same time.
Either one of these options would be workable, either deleting all old meta data and starting routing from scratch or keeping old data and returning it to the agent/team who previously worked it.
Exibir comentário · Publicado 25 de set. de 2020 · Robin Hoese
0
Seguidores
0
Votos
0
Comentários
Robin Hoese comentou,
@Gasper, the crux here is in 'discovered'. Regardless of the company or specific use case, I think we can work off of a few assumptions:
- The vast majority of ZD email users will have a need for somewhat persistent Groups and Agent assignments
- All of these users are likely to use some form of trigger to assign to these Groups (unless contact volume is so low that all of that sorting is done manually)
- It is impossible to predict or prevents end-customers from replying to emails after an indefinite amount of time, creating follow up cases.
This alone tells us, that many, if not all users, will receive follow-up tickets and have a need to treat those tickets in the same way than the original case, whether the reply comes after 1h hour or 1 month.
It would be feasible to either transfer all the data of the parent ticket, including group/agent assignment, to the follow-up or transfer none of it and treat the follow-up like a new case, trusting your triggers to route them the same way as they'd done before.
However, somewhere in the design there was a deliberate decision to only transfer partial data, making it impossible for a trigger to distinguish between an already routed open case and a follow-up case, entirely without group/agent assignment.
Exibir comentário · Publicado 14 de ago. de 2019 · Robin Hoese
0
Seguidores
3
Votos
0
Comentários
Robin Hoese comentou,
60 comments over 7 years and it still didn't make the prioritisation list? Folks, this isn't some nice-to-have idea, this seems like basic functionality that should have been included from the start.
Exibir comentário · Publicado 14 de ago. de 2019 · Robin Hoese
0
Seguidores
9
Votos
0
Comentários