Zendesk on Zendesk: How we use the About field
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!
-
What do you choose if the ticket involves multiple features? We have a lot of different features across our app, and every time I think about doing this, I think that it might be better for us to have "About" based on Concepts rather than features, since trying to do one task in our app could involve three or four features.
-
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!
-
Sounds great. How do you create an About field?
<edit> I think I have found the answer to my own question - https://www.zendesk.com/blog/tip-of-the-week-nesting-fields/
-
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 :)
-
We are using Macros as pre-prepared answers.
What we would love to do is to see if we can measure how much time we take to solve tickets by each macro and compare it to other tickets that don't use Macro. We already sat up the avg time spent metric and we tried assigning tags for each macro but it didn't work!
Can we use the about custom field to report on the average time spent per ticket according to a value assigned by this custom field in every ticket?
-
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!
-
A screenshot of the setup of the first few options would be an awesome addition to the article.
-
Has anyone considered using the Ticket Form field instead of an About field. Since we use the Form field to display the custom ticket fields relevant to the ticket already, it seems like we should be able to set up a Form for each category we might otherwise put into an About field -- and thereby save our agents time selecting the About drop-down field. Has anyone tried this yet? I'm mostly wondering if the Form field has the same reporting options as the About field. That might be the deal-breaker for us.
The other option is to do both I guess -- create the About field and the Forms and then set a trigger for each form to set the About field. Then hide the About field with something like Field Marshall. http://www.lovestockleaf.com/zendesk/zendesk-apps/field-marshal.html
Thoughts?
-
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:
-
Awesome, thanks! It's what I assumed you meant, but the formal "About" title had me wondering if it was a hidden feature I'd not yet discovered.
How we use the About field
vs
How we use a Ticket Field we call "About"
I think that image make a great addition to the main body of this article, lest it get lost in comment-history ;-)
-
@Robin - Thanks for the feedback. I think I'm going to use an 'About' field after all since Forms are not searchable. I'm glad you brought that up because it would definitely get cumbersome.
What I've decided to do is create Forms for each area of knowledge like IT, Medical Records, Accounts Receivable, etc. Then I set up a Trigger to change the Group to match and change the About field to navigate that area.
For example, if the IT form is selected and then the ticket is submitted (our triage person does this), the trigger will assign it to the IT Group and also set the About field to:
IT:: IT (select option below) <-- note the space before the second 'IT'. That will sort this to the top of this level in the list of About option as long as you sort that list alphabetically.
Then the options below are something like:
IT::Password Reset
IT::New User Account
IT::Troubleshooting::Hardware
IT::Troubleshooting::Software
We might, at some point in the future, also disallow our agents from solving a ticket set to the generic About option like 'IT:: IT (select option below)' if we see too many tickets left like this.
-
We currently have a field like this that we call "Key description." It has been a real help in our reports.
Currently I'm not using multi-level menus. So, for example, I have "Defective after install" and "Defective at install."
If I change this field to be multi-level, and have "Defective::After install" and "Defective::At install" will my reports still report two key descriptions or only one, "Defective"?
-
@Kim - apologies for the delay in getting back to you! In Insights, there will be two different attribute values. One will be "Defective::After install" and the other will be "Defective::At install".
-
Hey!
Could you please let me know if there are any recipes I can use to regularly analyse the 'About' field so I can see the top issues on a weekly basis?
I have tried to set up a report but I chose 'Ticket Event Update' which I feel wasn't the correct attribute to use.
I'm also interested to know more about the 1-touch solution tickets and finding out which 'About' fields are connected to these.
Thanks!
Lettie
-
Hey Lettie!
When building reports it's important to keep in mind how the date dimensions that you use to slice or filter your report align with the data you're looking to report on. Since the 'About' field may get updated throughout the course of a ticket before finally settling to the selection that best fits the nature of the inquiry you will normally want to report on this field's value after a ticket has been solved.
Reviewing the Insights Date Dimensions for attributes that align with solved tickets and a week interval indicates that a selection from the Date (Ticket Solved) folder such as "Week (Sun-Sat)" or "Week (Mon-Sun)" best aligns with the data you're looking to report on. As a general recommendation I would normally advise using "Week (Mon-Sun)/Year (Ticket Solved)" or "Week (Sun-Sat)/Year (Ticket Solved)" to ensure that your report shows you only the data you want to report on from the weeks in this year.
Insights: One-touch tickets is a great guide to get you started on 1-touch tickets reporting. If you needed to include the About field as a slice on this dataset you would just select the name of your About field from the attributes under How when building your report. You can reference Reporting on custom fields in Insights (Professional and Enterprise) for additional information on including your custom About ticket field in your reports.
-
Hey James,
Great thank you for this! The report is looking a lot better already!
Thanks,
Lettie
-
Hi Robin,
It seems I can't add more than one tag to the "field options" section of the about custom field, right? This is what I want to do:
I've set up several categories with subcategories in the about field and I want to create reports based on the tags assigned to each one, but you can only report on the "end point" of a category branch. For example:
System::Agreement::Notifications::Email::Notification not sent
Has an "email_not_sent" tag assigned and I can make a report that will show me all tickets classified in this branch, but if I want to make a report that shows all tickets in the following partial branch: System::Agreement::Notifications, how would I go about it? any ideas?
I was thinking about adding different tags representing each of the categories/subcategories of that branch you selected but I think I can't add more than one tag.
Thanks,
Julian
-
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
Please sign in to leave a comment.
18 Comments