Búsquedas recientes
No hay búsquedas recientes

Mark Schäfermann
Incorporación 15 abr 2021
·
Última actividad 21 mar 2023
Seguimientos
0
Seguidores
0
Actividad total
21
Votos
2
Suscripciones
9
RESUMEN DE LA ACTIVIDAD
INSIGNIAS
ARTÍCULOS
PUBLICACIONES
COMENTARIOS DE LA COMUNIDAD
COMENTARIOS DE ARTÍCULOS
RESUMEN DE LA ACTIVIDAD
Última actividad de Mark Schäfermann
Mark Schäfermann hizo un comentario,
Today we found out that Requester Changes are not synced to the Receiving Account. The original Requester remains.
Example:
Customer A opens a Ticket which is send to another Account. Requester is changed to Customer B. The receiving Accont still shows Customer A as Requester ans sends Public Replies to him.
Is this behaviour intended? Are there workarounds?
Ver comentario · Publicado 21 mar 2023 · Mark Schäfermann
0
Seguidores
0
Votos
0
Comentarios
Mark Schäfermann hizo un comentario,
Hey Leif Cederblom,
yes, from a technical point of view this description might be understood that on-hold is the only status that is not actively synced. However, I still don't see the use case why you would implement it that way. Why the difference in behaviour, if any agent action on the Ticket triggers the status sync, overwriting the on-hold status.
Ticket is on-hold, agent in receiving account assigns the Ticket to himself, Ticket is now Open in sending account. I just don't see the sense in it.
I more or less assumed that the sending Ticket would stay On-Hold as long as the receiving Ticket would stay open. But that is clearly not the case.
I've built a workaround setting the Ticket back to On-Hold as long as the Status remains Open in the receiving account. Only problem is that it screws with our reports as it now looks like the Ticket has been send back and forth way more often.
Cheers
Mark
P.S.: I was wrong in my post before. This has always been the behaviour. I must have overlooked it when testing the sharing feature.
Ver comentario · Editado 22 nov 2021 · Mark Schäfermann
0
Seguidores
0
Votos
0
Comentarios
Mark Schäfermann hizo un comentario,
Has there been an update to how Status sharing works?
Before when I set a Ticket to On-Hold it stayed On-Hold unless the receiving instance chose a status different than Open. Now the Ticket changes to Open when the Ticket is saved in the receiving instance (no status change).
This is very inconvenient as it messes with our process. Also I can't imagine any reason why this should be the intended behaviour.
Ver comentario · Publicado 10 nov 2021 · Mark Schäfermann
0
Seguidores
0
Votos
0
Comentarios
Mark Schäfermann hizo un comentario,
Great page! Mass edit for roles would be nice.
Also filters are lost when going to an agents page and back.
Ver comentario · Publicado 13 sept 2021 · Mark Schäfermann
0
Seguidores
5
Votos
0
Comentarios
Mark Schäfermann hizo un comentario,
@... That's awesome to hear, are you willing to share some more details on what you are planning?
Our use case would be related to ticket sharing between instances. For example, an Italian customer contacts our Italian colleagues. They cannot answer his question completely and share the Tickt with the HQ instance. The HQ agent answer to the Italian agent via internal comment (not directly meant for the customer). Can we create an SLA for the internal comments coming from the HQ agents?
Ver comentario · Publicado 31 mar 2021 · Mark Schäfermann
0
Seguidores
1
Voto
0
Comentarios
Mark Schäfermann hizo un comentario,
Ok, I see your point.
As we provide technical support, the chance is very high that the customer uses the "old" email again, to tell us that the issue has come back.
The part about using fields and tags to auto assign tickets is also exactly what I meant by features only being applied half baked. This only works if you have only so few entries that it can be managed manually. For example in a multi select field you can use :: to create categories. But those categories can't be used anywhere, no trigger, no nothing. I would have to add every single product in a trigger to make this work.
I like Zendesk for a lot of features, otherwise we wouldn't have bought it, but it is lacking when you want to have more than the standard "enduser has a question to 1 of 20 possible categories" process.
Ver comentario · Publicado 25 sept 2020 · Mark Schäfermann
0
Seguidores
0
Votos
0
Comentarios
Mark Schäfermann hizo un comentario,
+1
this goes right to the list of obvious missing features
the deeper you work with Zendesk the more you ask yourself why a lot of functions are only implemented half baked.
What could possibly be a good reason to have the follow up ticket created without a group and requiring manual assignment. and no, adding triggers for this is not the way to go. I already have too many triggers fixing missing SLA integrations.
Ver comentario · Publicado 16 sept 2020 · Mark Schäfermann
0
Seguidores
0
Votos
0
Comentarios
Mark Schäfermann hizo un comentario,
A lot of our requesters are Light Agents. While the First Reply time fires, the next reply time does not.
This seems only half implemented and is of crucial importance to us.
Ver comentario · Publicado 15 sept 2020 · Mark Schäfermann
0
Seguidores
0
Votos
0
Comentarios
Mark Schäfermann hizo un comentario,
+1
We have different groups that work on different email addresses. Must have for us.
Ver comentario · Publicado 08 sept 2020 · Mark Schäfermann
0
Seguidores
0
Votos
0
Comentarios
Mark Schäfermann creó una publicación,
We just started with Zendesk and it is going great, in fact it is going so good that our launch plan needs to be overthrown.
More and more groups are being created every day (and yes, we need them all). Is there a way to structure them? Like this is the IT department, and this is sales and each of them has like 5 subgroups?
-------
I've seen that hierarchic organizations is coming to Sell, would be awesome if it would also come to Support.
Publicado 19 mar 2020 · Mark Schäfermann
6
Seguidores
12
Votos
11
Comentarios