Storing Tier 2 rep name in addition to the Assignee
Putting Zendesk to Work is Support Driven’s advice column about getting the most out of Zendesk. Get insights and answers from our community of Zendesk administrators and consultants.
Join our Zendesk community and we'll help you put Zendesk to work.
Storing Tier 2 rep name in addition to the Assignee
I just want to confirm this, to ensure I am not missing anything in all the docs I have read… Is it really not possible to create new "User" fields on a Ticket? e.g. I want to store a Tier 2 rep's name/email etc. in addition to the Assignee so I can report on both? The idea I want, when a ticket escalates to Tier 2, the Assignee changes to the Tier 2 agent, but the Tier 1 agent is copied elsewhere inside the ticket as meta data, so I can report on # of escalations by an individual.
- Zendesk Manager
Brandon Tidd, Lead Zendesk Architect: Have you tried looking at the field changes data in Explore? https://support.zendesk.com/hc/en-us/community/posts/4409222529690-How-do-I-report-on-a-field-value-update-
Andrei Kamarouski, Zendesk Expert: I do agree with Brandon - Assignee field changes are stored in Updates dataset. So you can look at Assignee value at any update event (in your case escalation event).
Rafael Santos, CRM Manager, Customer Service at Uphold Inc: While I agree with Brandon and Andrei, there’s a use case for storing the assignee’s data in a field before the escalation, for example, if you’d need a workflow to refuse/return the escalation to the same agent.If a single agent, I’d say to update a numeric ticket custom field with the agent’s ID. If multiple, to update a text field with a somewhat different structure. You could try updating a ticket’s text custom field via Webhook using its own value + the new entry as the format.
Update 1:
{ agent: 12345, escalation_timestamp: 1666113781, source_group: 5555555, target_group: 6666666 }Update 2:
{ agent: 12345, escalation_timestamp: 1666113781, source_group: 5555555, target_group: 6666666 }, { agent: 56789, escalation_timestamp: 1666115000, source_group: 6666666, target_group: 8888888 }and so on…This field could then be parsed with Liquid for whatever you’d need on a subsequent update.
Managing Views in Zendesk
How do y’all manage Views in Zendesk? Who's allowed to create+edit? Certain tiers of agents? And are they allowed to edit for everyone? For only group-provided views? Only personal? We've had numerous times where tickets "fall in the cracks" because views weren't configured correctly. It can also provide a means for agents to cherry-pick, when we want them working in play mode with tickets ordered by Next SLA Breach. But I also understand having legitimate needs to modify views and not wait on specific ZD admins to make the changes.
- Zendesk Admin
Brandon Tidd, Lead Zendesk Architect: To prevent slippage, I always recommend a leadership/admin/manager view that shows "All Tickets Less Than Solved Out Of SLA By Assignee".
Community Member A: Hello, my success in Zendesk is fully dependent on the views. Where possible I use skill based routing and only specific people in the organization can edit them. We do not allow agents to touch those views as we use it to decide which tickets are handled when.
Community Member B: I have an "All new tickets by {vital metric} view" personal view, and every day I check to make sure the top ticket isn't unusually behind where the rest of the views are.
Community Member C: I always tell my team that anyone creating views (personal or not) should instead Clone an existing view (the most similar view to what they're trying to create). This ensures that any crucial conditions aren't forgotten.
Zendesk Guide for internal knowledge base
Question for Zendesk users who use Zendesk Guide for internal knowledge base:
Do you prefer to set up your IKB as a separate help center or do you keep it nested with your external help center, and why?
- Zendesk Improver
Brandon Tidd, Lead Zendesk Architect: I'm a big fan of better together for less maintenance unless the data is completely siloed, in which case it doesn't really matter.
Community Member A: This isn't the way we do it, but I'd vote for keeping it together. One place to search!
Dave Dyson, Community Manager, Support Leader, CX Enthusiast: We have internal-facing KB articles in our help center as well -- makes them easily findable when agents are searching from Support or from the help center (although Federated Search could allow you to pull articles from elsewhere, of course)
Community Member B: i’ve tried both under one roof, but it makes it harder for folks who don’t have Zendesk seats to see how support does things. Process guides and product info benefit from regular review by other teams
Alerts when a percent of cases breaching SLA target
Anyone have a creative way they're using triggers/automation to alert via Slack or email when a percent of cases may be breaching their next SLA target? We have many SOPs for after breaches have happened (and we're working on implementing Assembled for realtime channel monitoring and associate routing) but wondering if there are any good recipes, so to speak, for proactive alerting before time based SLA breaches in bulk.
- Zendesk Administrator
Chandra Robrock, Manager, Support Specialists at FullStory & Zendesk Community Moderator: I don’t have a solution for when a percent of cases may be breaching their SLA but I do have a solution for triggering a Slack alert via Zapier when a view of tickets reaches a certain threshold. For instance, I have a view that includes all tickets that will breach within 6 hours and then I fire a Slack notification if that view exceeds X number of tickets.
Here you go! https://support.zendesk.com/hc/en-us/community/posts/4409515181338-How-To-Create-a-Slack-Notification-When-a-Ticket-View-Reaches-a-Specific-Threshold
