Designing your ticket forms for a better agent and end user experience

A ticket form, also referred to as a contact form, is available in all Zendesk Support plans and provides your end users with an easy way to request support by entering data into a simple form.

You can create custom ticket fields to customize your ticket form. This means that you can tailor your ticket form to collect the kinds of data you want when an end user requests support. For example, you might want to prompt them to select the product they’re using from a predefined list.

You can also create multiple ticket forms and use conditional ticket fields. Having multiple ticket forms enables you to present different forms to your end users who can then choose the ticket form that best suits the type of support they are requesting. Conditional fields allow you to control the appearance and behavior of ticket fields in your ticket forms.

This article explains how ticket forms and custom ticket fields work, what your end users see when they use a ticket form, what your agents see in the ticket interface, and how to use the data captured by ticket forms and custom fields to automate your support workflow.

This article covers the following topics:

• What ticket forms look like to your end users and agents
• Customizing the default ticket form
• Using custom ticket fields to route and view tickets

• What ticket forms look like to your end users and agents
• Customizing the default ticket form
• Using custom ticket fields to route and view tickets
• Using multiple ticket forms
• Using conditional ticket fields in your ticket forms

What ticket forms look like to your end users and agents

Creating custom ticket fields and customizing a ticket form is an excellent way to gather the type of support request information you need to best serve your end users and then manage and route your incoming tickets. For example, having data in a custom field makes it easier to route the incoming tickets to the appropriate support team.

When using multiple ticket forms, you can create even more customized and targeted prompts for support information details. For example, you can present your end users with a drop-down list of support categories that, when selected, displays the ticket form that has been customized for that request type. A support request for a Product issue could then be much more detailed, containing custom fields relevant to that type of support issue.

An example of this is a custom form specifically for billing issues, which would include custom ticket fields such as a Purchase Order Number, Account Number, and Account Name.

Compared to simply providing your customers with an email address to send an email message to, the ticket form imposes a structure on the support request (in other words, here are the data fields that you need to complete to submit a support request to us). Using the ticket form, you can eliminate the email channel altogether, if you prefer this method of requesting support.

How end users see your ticket form

Your ticket form can be presented to your end users in two ways: via your help center on Submit a request page and by using the Zendesk Web Widget to place your ticket form on any website you choose.

This example shows the default ticket form, showing the default (system) fields. This is the version you have in your Zendesk Support account before you’ve added any custom ticket fields to it.

Web Widget (Classic) displays your ticket form embedded into your website. It also enables you to include other help center features such as access to your knowledge base and live chat.

For more information about the features of Web Widget (Classic), see Using Web Widget (Classic) to embed customer service in your website.

What your end users see when you’re using multiple ticket forms

When you’re using multiple ticket forms, your end users are first presented with a drop-down list with options. Each option displays a separate ticket form.

After they’ve chosen an option, the ticket form is displayed and they can enter and submit their support request.

Web Widget (Classic) also displays these options as a list that end users must select before a ticket form is displayed.

For more information about using multiple ticket forms with Web Widget (Classic), see Using custom ticket fields and ticket forms with Web Widget (Classic).

How your agents view ticket form data in Support

The data that was collected when the ticket form was submitted becomes elements of the ticket that is created. The subject field becomes the subject in the ticket, the description becomes the body of the message, the requester’s name and email address (if not matched to an existing end user in your Support account) becomes a new user record that is paired with the ticket.

When your ticket form contains a custom field, that data is added as additional data in the ticket (added to the ticket sidebar). For example, if you added a custom drop-down field for your end users to select from, that field is also shown in the ticket sidebar for agents to see.

When you’ve captured this data, you can use it in your business rules, to create views, and to include in reports. See Using custom ticket fields to route and view tickets below.

When using multiple ticket forms, the ticket form that was used to submit the request is displayed in the ticket forms drop-down in the ticket interface.

Any custom fields that were included in the selected form are also shown in the ticket sidebar, same as the example above.

Customizing the default ticket form

You customize what data to include on your ticket form by creating custom ticket fields and adding those fields to your ticket form. You also have a number of options for if and how your custom fields are displayed to end users and agents.

The first step is to access the Ticket Fields admin settings page (Admin > Manage > Ticket Fields - see Adding custom fields to your tickets and support request form). Here you’ll see all the system fields, which you can read about in more detail in About ticket fields.

The system fields include essential support request data such as the subject and description. These two fields are required and cannot be removed from the ticket form, although you can rename them.

The other system fields are used after the support request has been submitted via the ticket form and a ticket is created. For example, after a new ticket is received, it is assigned to an agent or group, its priority can be set and so on. These are not shown to end users on the ticket form.

Adding end user facing custom ticket fields

To add custom ticket fields that you want end users to enter data into, you create a new custom field and make it visible to end users.

Your goal is to focus on the essential data that will help you best determine what exactly your end users need help with. Therefore, you don’t want to overload your form with lots of fields because that might prevent your end users from completing the form. Your ticket form should be as short and simple as possible. We recommend no more than 10 or 12 fields in total and name your custom ticket fields with your customers in mind (don’t use industry jargon in your ticket field titles).

Choosing your custom field type

You’ll first be prompted to choose what type of data field you want to create. These are standard form fields for collecting typical kinds of data.

Here’s a description of your custom field type options.

Drop-down - This field type allows you to create a list of options that the end user can choose from. For example, a list of products, what kind of support issue they need help with, and so on. The selected item is also added as a ticket tag, which can be used for routing the ticket, setting ticket priority, and so on (you’ll learn more about this in Using custom ticket fields to route and view tickets below).

Note: Drop-down field lists can contain multiple levels of organization (see Organizing drop-down list options).

Multi-select - This field type also allows you to create a list. However, the items in this type of list can be multi-selected, meaning that end users can choose more than one item in the list. This field type is useful when there are multiple conditions that might affect the type of support that is required. The items that are selected also become ticket tags.

Text - This field holds a small amount of information (for example, a subject line).

Multi-line - This is also a text field, but it allows more text on multiple lines (this is used, for example, as the field type for the Description field).

Checkbox - This field is used for a single data point and the end user can choose it or not. The field selection is shown to agents in the ticket interface (it’s either selected or it’s not).

Numeric - This field is used to capture a string of numbers (an account number, for example). For common types of number data that follow fixed patterns (phone numbers, zip codes, etc. you use the Regex field).

Decimal - This field, also a numeric field, allows you to add a decimal point. You could use this field to prompt end users for currency values.

Date - When the end user clicks this field, a date picker appears and a date can be selected. You can use this to prompt for a purchase date or appointment date, for example.

Credit card - This field accepts credit card numbers in standard formats. If the number entered is not in a valid credit card format, the end user is warned and the data is not accepted.

Regex - This field uses regular expressions to prompt for standard types of data such as URLs, zip codes, and date formats. For example, this is a regular expression used to validate a five digit zip code: \b[0-9]{5}(?:-[0-9]{4})?\b. You can create your own regular expressions using Rubular.

For more information about the best uses of some of the field types, see Some useful examples of end user custom fields used for routing below.

Setting field visibility permissions

When you’re setting up a new custom ticket field, you also need to set its visibility permissions. For fields that you want your end users to see and enter data into, you need to make it visible to them on the ticket form.

The permissions setting you need to select is Editable by end users. This displays the field on the ticket form and allows end users to enter data. You also need to enter a field name into Title shown to end users.

The other permission related to end users, Read-only for end users, is used when you have a field that is controlled by agents, but that you also want end users to see when they’re viewing their tickets in the Support Portal in your help center. For example, you may want your end users to see what the ticket status is. This setting does not affect what end users see on the ticket form.

If you create a custom field but don’t want it to be displayed to end users, you just need to make sure that you’ve not selected the Editable by end users permission setting.

Requiring that end users enter data

The other important end user setting is Required to submit a request, which requires that end users enter or select data for the field.

When you set a field as required, the end user is not able to submit the form until all the required data has been entered or selected. Fields that are not set as required will be labeled as (optional) on the ticket form.

Note: When you create a new ticket field and select the Required to submit a request checkbox, this only applies to end user created tickets. Agents can still create a ticket regardless of whether the custom field is configured.

Making a custom field required to solve tickets

Just as you can require end users to enter data into a field, you can also require agents to do the same as a requirement for solving the ticket. For this, you select the Required to solve a ticket setting.

The custom field is marked as required in the ticket interface and the ticket cannot be solved until the data has been selected or entered.

Using custom ticket fields to route and view tickets

Custom ticket fields help you to capture the data you need to help you solve your customers’ support requests. After you’ve got that data, it can be used to create views and reports of your tickets and to automatically route incoming requests to the team or person who can best serve their support needs and solve the ticket as quickly as possible.

The drop-down list, multi-select, and checkbox custom ticket fields can be used for routing your tickets. This is because each of these fields create tags that are also inserted into the ticket. You can add tags to your triggers, automations, and views. This is how you can automatically route incoming tickets to a specific group or agent, for example.

The drop-down and multi-select fields automatically generate tags as you enter field options for your custom ticket field. With the checkbox field, you have the option of adding a tag to the field. When the ticket form is submitted, the data from these custom fields also generate tags in the ticket.

You use your tags as a condition in your business rules and then take action when those conditions are present.

In this example (a trigger), the ‘refund’ tag was generated by a custom drop-down ticket field that prompts end users to enter the type of support issue that they are contacting you about. Knowing that the support request is about acquiring a refund, the trigger actions can be used to automatically route the ticket to a Group or assigned to a specific agent.

Custom ticket fields, tags, and business rules used together can create automated workflows for handling incoming support requests and creating views of your tickets. For more information, see Understanding custom ticket fields in business rules and views and Using custom ticket fields in business rules and views.

When creating reports that include your custom ticket fields, it’s best to select the fields themselves, not the tag that they generate. For more information, see Reporting with custom fields.

Some useful examples of end user custom fields used for routing

Here are some ideas for custom ticket fields that you might want to add to your ticket form to use for routing your tickets.

Reason/How can we help? - Use a drop-down field to provide your end users with a list of the types of support that makes sense for your business (for example: Billing, Cancellation, Complaint, Inquiry, Feedback, Sales, Update My Account, Change My Subscription).

Product - Use a drop-down field to ask your end users to select the product they’re having a problem with.

Device - Use a drop-down field to ask your end users to select the device they are using, which might be relevant if they’re having trouble accessing your site or using your mobile device app.

Internet browser and version - Similar to the device field, you can use a drop-down field to prompt for the internet browser name and version they’re using, which may be very useful in understanding their support issue.

Do you have an account? - This is simply two options in a dropdown field: Yes and No. The dropdown field tags for these would be something like “account_yes’ and ‘account_no’. You could also use a checkbox field and add the ‘account_yes’ tag (tags are only added to a ticket when the checkbox is selected).

Note: An excellent example of many of these fields in use is the Dashlane submit a request page, which you can review here.

Using agent only custom fields for routing and follow up

You can create agent only custom ticket fields (not visible to your end users on the ticket form) that can also be used for routing and following up on tickets. There are two that we recommend: an ‘About’ drop-down field and a ‘Resolution’ drop-down field.

The ‘About’ field

The ‘About’ field is similar to the end user visible ‘Reason/How can we help’ drop-down field that was described above. It provides categorized support issues to help you gather more specific data. You might use both fields simultaneously, but the advantage of the agent only ‘About’ field is that it can be, and usually is, much more detailed and contains internal categories that you would not want your end users to see.

After a ticket is received and triaged, the agent can select the About category and the ticket can be routed using an automation. Having this detail in tickets is also good for creating views and reporting on tickets. For example, you can monitor and analyze open and resolved tickets based on these categories to identify what areas are giving end users the most trouble and so on.

For more information about the internal use of the ‘About’ field, see The 'About' Field. To use custom fields in reports, see Reporting with custom fields.

The ‘Resolution’ field

The ‘Resolution’ field is useful for tracking how tickets are resolved and what type of action was necessary to solve the ticket. It’s the how to the ‘About’ field’s what.

Knowing how an issue was solved, generally, can help you determine what actions you can take to help deflect these types of support issues becoming tickets. For example, tickets that were solved by explaining how to use the product, for example, indicate that you should probably be providing more documentation in your knowledge base so that the end user doesn’t need to request support.

For more information about the ‘Resolution’ field, see Using the 'Resolution' field.

Using multiple ticket forms

You can create up to 300 active ticket forms. You create other ticket forms on the Ticket Forms admin settings page (Admin > Manage > Ticket Forms - see Managing your ticket forms.

After you’ve defined all your custom ticket fields on the Ticket Fields settings page (see Adding custom fields to your tickets and support request form), you create a new ticket form (in addition to the default ticket form) and select the custom fields you want added to the new form.

You use multiple forms to create more specific and useful ticket forms, prompting your end users to enter data for different types of support issues and requests.

Note: You can review an example of how multiple forms are used here.

All of your active ticket forms are displayed to your end users on the Submit a request page (see Presenting ticket forms to end users) and in Web Widget (Classic) (see Using custom ticket fields and ticket forms with Web Widget (Classic) and Enabling multiple ticket forms in Web Widget (Classic)).

For more detailed information about using multiple ticket forms, see Creating multiple ticket forms to support different request types.

Using conditional ticket fields in your ticket forms

Conditional ticket fields allow you to control the appearance and behavior of ticket fields on your ticket forms. As an example, you can set up a custom ticket field to display another custom ticket field when end users select a specific value in a drop-down list.

To make that example easier to understand, imagine that you’ve got a drop-down field prompting end users for the type of support issue they need help with (a ‘Reason/How can we help?’ field). When an end user selects ‘Can’t log in’ from that list, a new drop-down field appears on the ticket form. This new field prompts them to select the internet browser they’re using.

You set conditions on your ticket forms from the Ticket Forms settings page and then define a simple when, if, then formula for how the form is displayed when the conditions are met.

You can also define conditions for agents, which affects how they interact with ticket field data in the ticket interface in Support.

Conditional ticket fields can also be set as required to complete the form. See Making conditional ticket fields required.

For more information about using conditional ticket fields see Creating conditional ticket fields in Zendesk Support and Creating ticket forms to support multiple request types.