I’m always amazed at the number of truly successful support organizations that don’t use any custom fields in Zendesk Support- or maybe just 1 or 2. I think in some ways it really speaks to the fact that simplicity often works. If you are giving great support, your customers are happy, and you are handling your volume, I say don’t rock the boat. There is absolutely no reason to introduce complexity in this type of scenario.
If you fit that description, carry on! This article isn’t for you.
However, if you are one of our many customers who already have a lot of custom fields or you support several different products or processes, our ticket forms feature will help you simplify your screens and really let your agents focus in on a targeted set of fields.
At Zendesk, we recently kicked off a project to combine all of our “internal” Zendesk Supports into a single corporate Zendesk Support. In our case, we want IT, HR, and Facilities requests to all come in through a central account to make it easier for employees to know where to go. But, as you can imagine, IT, HR, and Facilities all have very different types of requests that come in. IT has a lot of help tickets, but they also use Zendesk Support to log and track their change requests. Facilities, on the other hand, needs to let people report electrical issues or plumbing issues, request event help, or make kitchen requests.
We already know that with this many cooks in the proverbial kitchen, we’re going to need to use ticket forms so that each team can collect the information that they need for their own processes. But it’s not obvious to anyone how, exactly, we should configure the forms.
Should we slice forms by team alone? What about team and process? Which types of facilities requests do we think we could combine into a single form? Does HR even need a form?
The truth is, there’s no straightforward answer to how we should construct our forms, so we’re stepping back to analyze the current landscape and thinking about near-term future expansion.
When you start the process of defining ticket forms in your own instance of Zendesk Support, these are some questions you might want to ask yourself:
- How many fields do we have today?
- How many different organizations are using Zendesk Support?
- How many different processes are being managed in Zendesk Support?
- Do we see commonalities in the information required among different processes or products?
- How many forms do we want our customers choosing from? (less than 5?)
- How many forms are we comfortable with our agents selecting from?
- Do we have use cases for forms that are for agents only?
You may come away from this exercise knowing that you just need a different form per process, or a different form per product. If you’ve got multiple teams using Zendesk Support, you might have several forms per team. Whatever you choose, make sure you consider the customer and agent impact. If you are going to have your customers choose a form when they submit a request, make sure you also provide a generic form that can allow for requests you may not anticipate.
Once you’ve decided on the basic breakdown of your forms, it’s time to do some grunt work and make sure all of your fields are ready to go. You may find it helpful to create a quick spreadsheet of the different forms you want and what fields they’ll need. Identify which fields are reusable on multiple forms in the spreadsheet, and note which fields should be agent-required, end-user visible, end-user editable, and end-user required. Remember, fields maintain these properties, no matter which form they’re on.
This is also a really great opportunity to reassess existing fields. (Do you really need that category drop-down? Are you doing anything with the data, or are you just collecting it for the sake of collecting it?) I find a lot of organizations try to collect granular information for “future” reporting needs, but the future never happens. Lean and simplify!
Go ahead and create or update your custom fields in Zendesk Support according to your plans. If you're on Support Enterprise, you can test this in a sandbox before making production changes.
Now it’s time to take the plunge and create your ticket forms . By now you should have a spreadsheet handy with the forms you need to create and which fields belong on each form, which means the heavy lifting is done.
Once created, make sure you test out each form both from an end-user’s perspective and an agent’s perspective. You’ll want to test the following items:
- Are the field-level settings correct? (Are you forcing an end-user to fill out a field that’s not necessary?)
- Are the correct forms displaying to the end-user? Are they in a logical order?
- Does each form display fields in a logical order for your process?
- Are your forms missing any fields that are critical to your process?
That’s it! Your new ticket forms are ready for prime time. If you’re feeling extra productive, think about incorporating forms into your business rules or macros as well.
Happy ticket form-ing!
Ticket forms is available as a Professional Add-on and on Enterprise.