Custom Ticket Fields - Design your system – Available ApS

The foundation of an intelligent support system

In Zendesk, custom ticket fields are not merely additional fields in a form; they form the foundation of an intelligent, scalable and efficient support system. The way the fields are designed and used directly affects how efficiently tickets can be routed, how meaningful the insight that can be created is, how workflows can be automated, and how integration with business systems can take place. Field design is system design. A well-thought-out strategy for custom ticket fields is a central prerequisite for developing customer support from a reactive function into a proactive value creator.

What are custom ticket fields?

Custom ticket fields are user-defined data fields that can be added to Zendesk tickets to collect specific information beyond standard fields such as subject and description. Standard fields support the basic communication, but they rarely describe why the customer is writing, what the context is, or which product the enquiry concerns. Custom ticket fields make it possible to structure this context so that it can be acted upon. The fields function as building blocks for turning unstructured enquiries into structured, action-oriented data.

An in-depth review of field types

Zendesk offers several field types with different strengths and areas of application. Choosing the correct type from the outset is crucial for data quality and future flexibility.

Dropdown – the power of choice

A dropdown presents the user with a predefined list of options, of which only one can be selected.

Use for: Categorisation, choosing a product, priority, department or situations with a closed set of options.
Example: Produkt: (Enterprise, Professional, Basic), Henvendelsesårsag: (Teknisk fejl, Fakturaspørgsmål, Feedback)
Advantage: Ensures high data consistency without spelling errors and ambiguity. Well suited when you need to report and automate reliably based on a value.
Pro Tip: Consider including an option such as "Other" or "Unknown" to capture tickets that do not fit existing categories. This can reveal gaps in the classification.

Text Field – short and precise

A single-line text field for concise information.

Use for: Order numbers, reference IDs, serial numbers, contact names.
Example: Ordrenummer: 12345-ABC, Reference-ID: REF-98765
Advantage: High flexibility for the user.
Warning: Avoid this type for information that needs to be reported on. Values such as "Copenhagen", "cph" and "Copenhagen V" will be treated as different values in reports.

Textarea – room for detail

A multi-line text field for longer descriptions.

Use for: Detailed descriptions, internal notes, steps to reproduce an error, the customer's own words.
Example: Fejlbeskrivelse: "Når jeg trykker på 'gem'-knappen i fakturmodulet, får jeg en 500-fejl. Det sker hver gang...", Interne noter: "Kunden er VIP, prioritér højt."
Advantage: Provides room for necessary context that does not fit in the standard description.

Checkbox – the simple yes/no

A checkbox that represents a true/false value.

Use for: Boolean flags that need to be set. Has the customer accepted the terms? Is the ticket part of a known service incident?
Example: Kunde kontaktet: [ ], Eskaleret til ledelse: [ ], SLA-brud: [ ]
Advantage: Simple and effective for binary states and can be used in triggers to start specific workflows.

Date Field – structured time

A field that ensures data is entered in the correct date format.

Use for: Delivery dates, task deadlines, subscription start dates, the time of a reported incident.
Example: Forventet levering: 25-12-2024, Deadline for opgave: 15-11-2024
Advantage: Enables time-based calculations in reports (e.g. "average time from deadline to resolution").

Decimal / Integer – numeric precision

Fields designed exclusively for numbers.

Use for: Amounts in currency, quantities of items, version numbers, quantitative measurements.
Example: Beløb (DKK): 1499.95, Antal enheder: 5, Softwareversion: 4.2
Advantage: Enables mathematical operations in e.g. Zendesk Explore, including calculating the total value of tickets or the average number of units per ticket.

Regexp – the art of validation

A text field that validates input against a regular expression.

Use for: Ensuring that data follows a specific format, e.g. postcodes, phone numbers, email addresses or specific ID formats.
Example: A postcode field that only accepts four digits. An order number field that requires the format "AAA-99999".
Advantage: A robust method for ensuring data quality when the format is critical.

Designing fields = designing the system

The choice of fields and values has a direct impact on how the Zendesk system works.

1. Intelligent routing and automatic assignment

By using custom ticket fields in triggers, an automated routing system can be established.

Product-based routing: A Produkt field can be used in a trigger to assign the ticket to the relevant specialist group.

Condition: Ticket > Custom field 'Produkt' > Is > 'Enterprise Plan'
Action: Assignee > Set to > (Group) Enterprise Support Team

Priority-based routing: A Prioritet field can, in combination with an SLA-niveau field, automatically escalate tickets.

Condition: Ticket > Custom field 'Prioritet' > Is > 'Høj'
AND
Ticket > Custom field 'SLA-niveau' > Is > 'Platin'
Action: Add tags > 'urgent_platinum'

2. Data-driven reporting and business intelligence

Without structured data, reports become primarily counts. With custom ticket fields, insight can be created.

Performance per category: First Reply Time and Resolution Time can be measured per value in the Henvendelsesårsag field. If "Technical errors" take markedly longer to resolve, this provides a concrete insight that can be acted upon.
Business insight: An Ordreværdi field (Decimal) can provide an overview of how many support resources are spent on high-value vs. low-value customers.
Trend analysis: By tracking a Produkt field over time, it can be assessed whether the launch of a new product leads to an increase in support enquiries.

3. Powerful automation and workflow optimisation

Custom ticket fields can change value over time, and the changes can trigger automations.

Automatic follow-up: An automation can check whether the Kunde kontaktet field (Checkbox) is still unticked 24 hours after creation and automatically send a reminder to the agent.
SLA adjustment: If an agent marks a ticket with Kræver eskalering (Checkbox), an automation can set a new, tighter deadline or notify a team leader.

4. Seamless integration with external systems

Custom ticket fields can function as a bridge between Zendesk and other systems (CRM, ERP, logistics systems).

Webhook payloads: When a ticket is created, values from e.g. Ordrenummer and Kunde-ID can be sent as a webhook to a warehouse management system for status checking.
API synchronisation: Via Zendesk's API, an external CRM system can update a Kundetype field in Zendesk so that agents have up-to-date information.
Data mapping: When integrating with e.g. Salesforce, a Case Origin field in Salesforce can be mapped to a Henvendelseskanal field in Zendesk.

Best practices: build a scalable system

Experience shows that a good strategy from the outset can save many hours later.

1. Strategic planning: think long-term

Before creating the first field, map out processes: which data is necessary for routing, and which data is necessary for reporting to management? Both current needs and expected growth should be taken into account. It is easier to design a system with room for another product than to redesign later.

2. The power of dropdowns: ensure data quality

Dropdowns are used where possible, as this is the most reliable way to achieve consistent data for reporting and automation. A text field can be quick to implement, but it can create technical debt in the form of "dirty data".

3. Consistent naming: a universal language

A naming convention is established, e.g. Kategori_Subjekt (Produkt_Linje, Kunde_Segment). This makes fields easier to find and understand, especially in lists of triggers and automations. Abbreviations are avoided unless they are universally understood in the organisation.

4. Optimising the user experience with forms

Related fields are grouped into "field sets" to create logical and clear forms for both agents and end customers. "Conditional fields" are used to hide irrelevant fields. If a customer selects "Invoice query", fields related to "Technical error" are not necessary. This reduces noise and can increase the quality of the data collected.

5. Required fields: use them with consideration

Fields are only made required if the information is critical for case handling. Too many required fields can lead to frustration and abandoned forms. A field can be considered made required only when a particular condition is met.

Case study: designing an e-commerce system

For a typical e-commerce business, a system can be designed that provides control over order- and product-related enquiries.

Field Set: "Order information"

Ordrenummer (Text, Required for agent form): The key to all communication.
Henvendelsestype (Dropdown: Question about order, Return, Complaint, Tracking): Defines the primary workflow.
Forventet leveringsdato (Date): Important for managing expectations.

Field Set: "Product information"

Produktkategori (Dropdown: Clothing, Electronics, Home & Garden): High-level categorisation.
Specifikt produkt (Dropdown, dependent on category): Enables tracking of problems with specific items.
Antal enheder (Integer): Relevant for returns and complaints.

Workflow in practice

A customer writes via the contact form, where the "Order information" set is visible.
The customer fills in Ordrenummer and selects Return in Henvendelsestype.
A trigger catches the creation and registers that Henvendelsestype = "Return". The trigger adds the tag returnering and assigns the ticket to the "Returns team".
An agent on the Returns team opens the ticket. Because Henvendelsestype is "Return", the "Product information" set becomes visible (via conditional fields).
The agent fills in Produktkategori and Specifikt produkt.
In Zendesk Explore, a report can be created that shows: "Number of returns per specific product", which gives the purchasing department valuable data about product quality.

Advanced techniques: dynamic forms and dependencies

Cascading dropdowns

Chains of dropdowns can be built, where the choice in one field determines the options in the next. In the e-commerce example, the choice of Produktkategori can dynamically update the list in Specifikt produkt so that it only shows products from the selected category. This creates a clearer and more user-friendly experience.

Validation with regexp

Regexp fields can be used to reduce input errors. A Telefonnummer field can be configured to only accept Danish 8-digit numbers. An EAN field can be validated to exactly 13 digits. This can save time for both customer and agent.

Integration in practice: triggers and automations

A more advanced example of a trigger that uses several fields:

Trigger: VIP Enterprise Eskalering

Conditions: ALL
- Ticket: Is | Created
- Custom field 'Kundetype' | Is | 'Enterprise'
- Custom field 'SLA-niveau' | Is | 'Platin'
- Custom field 'Prioritet' | Is | 'Høj'

Actions:
- Assignee: Set to (Group) L2 Enterprise Support
- Priority: Set to Urgent
- Add tags: vip_escalation, platin_high
- Notification: Notify user "teamlead@company.dk" with subject "VIP Eskalering: {{ticket.title}}"

The trigger ensures that important customers with critical problems quickly receive high attention.

From data to insight: reporting in Zendesk Explore

In Zendesk Explore, custom ticket fields can be used to:

Create dashboards that show the volume of tickets per Produktkategori.
Build a "Cost of Support" report by combining Agent arbejdstid with Kundetype and Ordreværdi.
Analyse First Contact Resolution (FCR) based on Henvendelsestype to identify enquiries that require follow-up.
Create custom metrics, e.g. a metric that counts the number of tickets where the Kunde kontaktet field is empty after 8 hours.

Troubleshooting: common challenges and solutions

Problem: A new field does not appear in the agent form.
- Solution: Check whether the field has been added to the correct "Ticket Form" in Admin > Ticket Forms. Note that changes to a form do not affect existing tickets unless they are edited.
Problem: Reports are unreliable because agents misspell in a text field.
- Solution: Convert the text field to a dropdown. Collect existing values from the field and use them as the basis for the dropdown options. The process can be time-consuming, but it can pay off in the longer term.
Problem: A trigger does not activate when an agent updates a custom ticket field.
- Solution: Check that the trigger's condition listens for changes in the field, e.g. Ticket > Custom field 'Produkt' > Changed. A trigger that only listens to "Ticket is Created" does not activate on subsequent changes.

Next steps: from design to implementation

Once custom ticket fields have been designed, the following steps can be used for implementation:

Implement: Create the fields and add them to the relevant forms in Zendesk.
Automate: Create triggers, automations and macros that use the fields.
Report: Configure relevant dashboards and reports in Zendesk Explore.
Train: Ensure that the team understands the purpose of the fields and uses them correctly.
Iterate: Review data and processes on an ongoing basis to assess the need for adjustments or new fields.

A strategic approach to custom ticket fields supports a helpdesk system that functions as an effective engine for customer service with a focus on efficiency, insight and business value.