Zendesk on Zendesk: How we use the About field

18 Comments

  • Reagan

    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.

    2
  • Robin Frerichs

    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! 

    1
  • Matthew Free

    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/

    0
  • Robin Frerichs

    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 :) 

    0
  • Mustafa Habib

    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? 

    1
  • Robin Frerichs

    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!

    0
  • Allen Hancock

     

    A screenshot of the setup of the first few options would be an awesome addition to the article.

    0
  • Justin Graves

    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?

    0
  • Robin Frerichs

    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:

    1
  • Allen Hancock

    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 ;-)

    1
  • Justin Graves

    @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.

    0
  • Kim Graf

    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"?

     

    0
  • Brent

    @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".

    0
  • Lettie Ball

    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 

    0
  • James Sanford

    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.

    0
  • Lettie Ball

    Hey James, 

     

    Great thank you for this! The report is looking a lot better already! 

    Thanks, 

    Lettie 

    0
  • Julian Lasser

    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

    0
  • Robin Frerichs

    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

    0

Please sign in to leave a comment.

Powered by Zendesk