Formset is essentially an ability to control the visibility of Zendesk Support fields by means of defining rules that state when they should be visible.
This is a powerful capability that enables a number of use cases. These are explored in a series of further articles in this help section. However, it's worth dwelling first on two very important business concepts that drive the need for field visibility control:
- Context - a frame that surrounds an event and provides resources for its appropriate interpretation.
- Classification/Categorization - an activity that consists of putting things, such as objects, ideas, or people, into categories based on their similarities or common criteria.
Some Zendesk plans have features such as Brands and Ticket Forms, these are good examples of configuring Zendesk for different contexts of use. Contexts can be wide, granular, or both depending on your business. The act of analysing the scope of your help desk will get you to think about collecting data that supports particular contexts. This typically involves a mix of common and unique fields for each context of use you may have for Zendesk Support.
If you have been put off creating too many fields, cluttering the interface or illogical combinations of data, then the ability to configure them within a context of use can free you up to think more creatively about what is needed for each context.
If we consider context to be the macro viewpoint, Classification/Categorization can perhaps be considered a micro viewpoint. Classification/Categorization is a method of standardization that can start off broadly with increasing sub-levels of sophistication.
Lets, take an example:
- A ticket is received for Product A, vs. Product B or Service C
- Product A is a software product which is database based
- The ticket requester is having an issue with configuring the product vs. operational data processing issue
- The issue appears to be bug vs. a question about how to achieve something
- The bug is related to a specific screen/component part of the app
We can now start to see that Product type is an example of a context and that the ticket can be classified down to be a suspect bug for a certain component. If you know your business well, you may well do all this in your head, but codifying this knowledge in a logical way can help all levels of agents to quickly and consistently analyse what the ticket is all about. Indeed, if you also end-user ticket forms, you can get your user community to start to think through describing their issue.
Classification/Categorization is also useful during the lifecycle of the ticket, even the owning agent can get more quickly up to speed on the essence of the ticket without having to read through the comment thread. This is even more relevant if the ticket is escalated to another agent.
A classification/categorization is structured data and as such becomes super useful for all sorts of other things like Views & Reports segmentation, as well as rules for triggers and automations.
The following usage patterns for Formset will help to make this more concrete, but it's vital to see the business drivers of applying context and classification to tickets.
- Embed an analytical mindset with codified knowledge
- Reduce time-to-understanding
- Leverage for automation, findability, and reportability efficiencies