How Do I Keep Suspended Users Out of Our Chats?
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.
I tried searching ZD help but ended up in circles - is there a way to ban a user in Workspace? We suspended them but they are still able to chat in.
- Workspace Ruler
Josh Keller, Sr. TechOps Manager, Customer Ops @ Udemy: If you don’t require authentication for chat, sorry to say there’s no way to avoid this. ... Sorry, I should mention that Chat admins can still do IP-based bans under Settings > Banned in chat admin, but regular chat agents cannot.
Rafael Santos, Zendesk & CS Tools Admin: The risk with bans on IP addresses for anonymous users is that those aren't static for most people, and you could risk banning another customer who'd get that same address in the future (small chance, though terrible UX).
Setting Default Options in Explore
I’m sure it’s something dumb that I’m missing, but in Explore, how do I change the default values that are selected in the drop downs? I tried editing the dashboard, unselecting everyone, and then publishing, but they’re still selected.
- Explore explorer
Dave Dyson, Sr. Customer Service Evangelist at Zendesk: Does this section "Save default filter values via bookmarks" help? https://support.zendesk.com/hc/en-us/articles/360034902733-Best-practices-for-using-dashboard-filters#h_bd2ba570-0721-4a5f-8bbb-e631c13caacf
Explore explorer: So the bookmarks thing accomplishes what I want, but it seems weird that I can’t just change the default? For example, the one I’m having an issue with is the ticket assignee. Currently, the default is that a few agents are selected, but I want no one to be selected. Is there no way to change that?
Explore Expert: if you made the queries themselves have those filters it should work on the dashboard. the real benefit of setting a default state for a dashboard was the ability to use a single query on multiple dashboards, instead of needing to save queries with really specific filtering for each relevant dashboard.
What Ticket Fields Do You Use for Reporting?
Hey everyone,
I am in the process of improving our ZD ticket form in order by adding ticket fields for better reporting and other long term benefits (routing, feature request trends, bug reports etc)
Did you break down your product into smaller components for better ticket classification?
What was your process? Was that done by the Product team or in collaboration with Support?
I would love to see some examples of ticket fields of your product.
I typically have these implemented:
Root cause - why did we get the request in the first place
feature request
bug
performance issue
third party issue
knowledge gap
About or Category
which part of the product impacted by the root cause?
For more complex products we broke down the categories into smaller modules, components, so we could see what are the key drivers of our incoming volume and where could we improve.
Any examples, suggestions or inputs are welcome!
- Zendesk Explorer
Community Member A: Hey Peter, wrote a couple of articles on this recently you might find useful.
Tagging best practice: https://www.sentisum.com/insights-article/best-practice-for-building-a-tagging-taxonomy
How to properly prioritise support issues: https://www.sentisum.com/library/how-to-properly-prioritize-customer-support-issues
Community Member B:
1. Yes, it's always good to break down the product modules and have it as a ticket category, so it's easier to track the "where" within the product.
2. Root cause can be set as "Ticket Type" - T1 - How to's, T2 - troubleshooting, T3 - Bug etc.
So, when you do the analysis, you can tag the ticket type with the module to understand what type of tickets you get and in which modules!
You are absolutely on the right track!
Community Member C: Great topic @Peter Sajevics! I've recently published a step-by-step guide and a template for building a strong support taxonomy which you might find useful: https://www.prodsight.com/resources/the-ultimate-support-tagging-taxonomy-guide/
Dave: We have an extensive Product Area field (formerly called the "About" field) -- this article is a bit out of date compared to our current processes and team structures, but the themes are still valid: https://support.zendesk.com/hc/en-us/community/posts/212671827-Zendesk-on-Zendesk-How-we-use-the-About-field
Hosam Hassan, Certified Zendesk Expert & SupportOps Consultant:
Hey Peter - I always take two things into consideration when building fields.
Audience: who needs this info (engineering, product, leadership)?
Reporting: what are we reporting on?
If you don’t need to report on it, and there isn’t an audience interested in that info, then you don’t need a field for it.
I typically like to create an end-user-facing field with all the actions a user could take. This helps narrow down the area in your product that’s not working well.
Field Name: Conversation Topic (What can we assist you with today?)
Option 1: Updating a credit card
Option 2: Signing in using Google authentication
Then I create at least one internal field for reporting.
Field Name: Request Type
Option 1: Bug
Option 2: Feature Request
Option 3: User education
An optional field would be another internal field to track outcomes.
Field Name: Outcome
Option 1: User error
Option 2: Platform error using Chrome
Option 3: User deactivated their account
