Recent searches
No recent searches

Robin Frerichs
Joined Jan 13, 2021
·
Last activity Jul 10, 2024
Following
0
Followers
0
Total activity
14
Votes
3
Subscriptions
5
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Robin Frerichs
Robin Frerichs commented,
Hi Julian
I totally understand where you're coming from and we've actually run into similar issues with our About Field and reporting on it. What was done internally by our data analytics team was to create a custom metric within insights to group values together. Alternatively (if you're up for trying out something brand new that's really cool) you could consider setting up levels using our new Conditional Ticket Fields EAP.
Using that you could set up a top level selector then have subsections appear as needed. Something to perhaps consider as your build time will be a little longer but the eventual solution is likely more scalable.
Cheers,
Robin
View comment · Posted Mar 22, 2019 · Robin Frerichs
0
Followers
0
Votes
0
Comments
Robin Frerichs commented,
Hey Justin!
That's definitely an option, when it comes to our instance creating a separate form for each nested option would result in 50+ forms but depending on how you plan to use it that might be a great way to get what you want. There is a metric in Insights that lets you sort by Ticket Form so even in terms of reporting you could get that granular.
The only issue I came across when trying to use the Ticket Form setup is that the Ticket Form field is not a searchable field like the ticket field is. That means that as your list of categories grows you will inevitably end up scrolling through a long list of options.
At Zendesk we actually use the Ticket Form in a larger sense where a ticket form may indicate what the purpose of the ticket is. We have a ticket form for tickets that go to our Dev teams which has ticket fields relevant to them, whereas a ticket that stays in support wouldn't need to have those fields displayed.
@allen ask and you shall receive this is what the About field could look like:
View comment · Posted Jul 06, 2016 · Robin Frerichs
0
Followers
0
Votes
0
Comments
Robin Frerichs commented,
Hey Mustafa,
If you're already using time tracking and reporting on that, using the About field in the "How" portion of your insights report will get you a nice read out of the About field that was set and the time spent to solve.
We have a report exactly like that setup for our instance that uses Average Handle Time along with the About field. This give us an overview of how long it's taking advocates to handle tickets about certain things!
View comment · Posted Jul 05, 2016 · Robin Frerichs
0
Followers
0
Votes
0
Comments
Robin Frerichs commented,
Hey Matthew,
That's pretty much it! We use a dropdown field which is easiest in terms of reporting, and the nesting tip will help you the rest of the way :)
View comment · Posted Jun 30, 2016 · Robin Frerichs
0
Followers
0
Votes
0
Comments
Robin Frerichs commented,
Hey Reagan,
What we usually do in situations like that is pick the option that's most likely going to take the most time to resolve. If there are actually different questions on separate parts of the product our advocates can split the ticket to make sure our stats are matching.
You can always start your About field with concepts and then work on refining it as you start gathering more data and feedback. It really depends on how granular you want to get, with a nested field you can start with concepts and work from there!
View comment · Posted Jun 29, 2016 · Robin Frerichs
0
Followers
0
Votes
0
Comments
Robin Frerichs created a post,
Zendesk on Zendesk is a day-long discussion about a specific topic and how Zendesk Support uses Zendesk. Each session is hosted by a member of our Support team.
This session is about how we use a custom About field to drive our support workflows and is hosted by Robin Frerichs, a System Specialist in our Dublin office.
See all of the Zendesk on Zendesk series discussions.
What's this all About?
The About field is a custom ticket field we use at Zendesk. Our Support team, as well as some other teams, rely on the About field for a variety of different purposes, including reporting, routing, escalation and notifications. We started using the About field in 2010 and it's been a constant presence ever since, eventually becoming the 321-option behemoth it is today. In this edition of Zendesk on Zendesk, we’ll look at the following:
- Setting the About field
- Managing the About field
- Reporting on the About field
- Business rules and the About field
- Using the About field in Tier 2
Setting the About field
The current triage agent sets the About field during the triage process. (See Zendesk on Zendesk: How we triage for more on our triage process!) With 321 field values to choose from, it can be difficult to select the right option. One way we minimize the chance of errors is organizing the field to allow for browsing based on product category.
The About field is nested to allow for browsing based on product category, so one selection could look something like: Product > Business Rules > Triggers.
Additionally, every agent who touches a ticket double-checks the About field and updates the value if necessary.
Managing the About field
The About field is managed by Support Operations, the team responsible for maintaining and managing our Zendesk instance. We need to regularly update the field values to account for new internal processes and support team changes, as well as for actual product updates. Occasionally, we also remove About field options, mainly due to lack of use or because the feature is deprecated. We make updates like these to the About field almost weekly and send notifications to all relevant parties when we do so.
To initiate an update to the About field values, a product champion (an experienced advocate specializing in a specific product area) or a product manager sends a ticket to Support Ops requesting the change and explaining the reason why. Support Ops will then evaluate the request and, if necessary, update the field values.
Each option on the dropdown adds a tag starting with "about_" and then the name of the option selected. For example, if the About field is set to Facebook, the tag "about_facebook" is added. To keep the tags short, we don't include the full names of nested fields in the tags.
Reporting on the About Field
One of the most important reasons we have the About field is so we can report on it in Explore. Our data analysts, who work as part of the Support Ops and Program Management teams, maintain the Insights reports. This way, we can get results regarding a product area that might apply to more than one of the About field values. Based on those buckets, we build out other metrics, such as one-touch solves, based on the About field.
We use these reports to determine which types of tickets take the most time to solve or are escalated to higher support tiers most frequently. We can also use the reports to see if there are any specific areas agents are specialized in or are leaning towards. This, in turn, helps our management team with decisions on training and escalation.
It also helps us look for gaps in our documentation. By looking at frequency of different About field values, we can see what type of questions are frequently being asked and if we can write documentation to proactively support our customers.
Using the About field reports, our Team Leads in Tier 2 are also able to look into ways of optimizing the About field. When an advocate has a triage shift, they generally want to get through tickets as quickly as possible to stay on top of the inbound queue. This means that the About field has to be set as soon as possible, and the wording of the field options can make a world of difference. When the wording is off or counterintuitive, an option might not be selected even when it is relevant.
Business Rules and the About Field
The About field is also used for certain business rules. For example, when we launch a new feature, developer groups within Zendesk might want to be notified of feedback coming in through tickets. In some cases, our Support Ops team will set up a trigger that CCs specific agents when a ticket is submitted with that About field. That way, the developers can stay up to date of any incoming feedback or questions regarding the new feature and can choose to chime in or find gaps in our documentation.
The About field also features heavily in our macros. For macros used to answer specific questions, we can set the About field to save the agent time when solving the ticket. A Chat-related macro, for example, usually automatically sets the About field to Chat, saving agents some time.
The About field in Tier 2
Our Tier 2 support team has their own use for the About field: they use it for specializations. The team is split up into squads that specialize in different product areas. Tickets sent to Tier 2 are kept in the Tier 2 group with views set up based on the About field. The squad responsible for integration tickets, for example, use a view that shows only tickets with the About field set to something integrations-related. Similarly, the squad that handles reporting would get tickets about Explore, and so on across all four squads. This allows for our Tier 2 advocates to pick specialty areas and become gurus on certain types of tickets.
-------
That's how we use the About field here at Zendesk! Do you have an About field or a similar custom field in your Zendesk instance? Do you have another way of accomplishing the same goals described above? Any other questions or thoughts? Let us know in the comments below!
Posted Jun 27, 2016 · Robin Frerichs
0
Followers
16
Votes
19
Comments