Priority Calculation via Triggers

Automatic calculation of priority via triggers is a central part of an effective Zendesk setup. By implementing a system that automatically assigns priority based on predefined, objective criteria, a consistent, fair and efficient handling of incoming enquiries is ensured. This reduces manual errors, shortens handling time and ensures that the most critical tickets are handled first.

Why Is Consistent Prioritisation Crucial?

Manual prioritisation is time-consuming and is often subjective and error-prone. Different agents may assess the same ticket differently based on experience or current workload. This can lead to:

• An inconsistent customer experience: A VIP customer may experience a longer waiting time than expected, while a less critical ticket is handled first.
• Inefficient resource allocation: Experienced agents spend time on tickets of low importance, while critical problems wait.
• Lack of overview: Without a standardised scale, reporting on problem types and focus areas becomes less meaningful.

Automatic prioritisation transforms the process from a subjective assessment into an objective model. It creates a solid foundation for service-level agreements (SLAs), reporting and the agents' daily work.

Understanding Priority Levels

In Zendesk, a standardised scale for priority is typically used. It is crucial that the organisation has a shared understanding of what each level covers.

• Urgent: The highest level of severity. Covers critical problems with a markedly negative impact on the business or the customer's operations, e.g. a total system outage, a security breach or a fault that prevents all users from accessing a core function. Requires immediate attention and escalation.
• High: Important problems with significant, but not catastrophic, impact. May be faults that affect a large part of the user base, or a problem that prevents a single user from carrying out a crucial task. Must be handled quickly and prioritised over standard tasks.
• Medium: The standard level for ordinary support requests. Covers questions, how-to, minor faults with a solution or workaround, as well as general enquiries without a time-critical character.
• Low: Non-critical tasks or suggestions for improvement. May be general enquiries, cosmetic faults or tasks that can wait without a negative impact on the customer or the business.

Methods for Automatic Priority Calculation

Several methods can be combined to establish a more precise prioritisation system. The most common approaches are described below.

1. Form-based prioritisation

A simple method is to base priority on the form the customer selects when creating the ticket. This is well suited to clearly separated categories.

Example: There is a form "Critical System Outage" for reporting outages.

Condition:
  Ticket is created
  AND
  Form is "Critical System Outage"

Action:
  Set Priority to "Urgent"
  Add internal note: "Ticket automatically prioritised as Urgent due to Critical System Outage form."

2. Keyword-based prioritisation

This method scans the subject field and the description for keywords that may indicate a critical problem.

Example: Words such as "nedbrud", "kritisk", "haster" or "emergency" need to be identified.

Condition:
  Ticket is created
  AND
  Subject field contains at least one of the following: "nedbrud", "kritisk", "haster", "emergency", "down"
  OR
  Description contains at least one of the following: "nedbrud", "kritisk", "haster", "emergency", "down"

Action:
  Set Priority to "Urgent"
  Add tag: "keyword_detected"

Important: False positives must be taken into account. The word "ned", for example, can occur in other contexts. Consider more specific phrases or regular expressions (regex) to increase precision.

3. Customer-tier-based prioritisation

Priority can be assigned based on the customer's value. This requires a custom field at the user or organisation level.

Example: A custom dropdown field "Customer Tier" on users with the values "VIP", "Enterprise" and "Standard".

Condition:
  Ticket is created
  AND
  Requester > Custom field "Customer Tier" is "VIP"

Action:
  Set Priority to "High"

Several triggers can be created, e.g. one that sets the priority to "Medium" for "Enterprise", while "Standard" remains at "Low" or "Medium" by default.

4. Field-based prioritisation: Impact and Urgency

A more advanced method is to separate impact (the scope of the problem) from urgency (time-criticality). This is a classic ITIL approach.

Setup:

1. Create two custom dropdown fields for tickets: Impact (Low, Medium, High) and Urgency (Low, Medium, High).
2. The fields can be filled in by the customer via the form or by an agent after a brief assessment.
3. Create triggers that combine the values to calculate the final priority.

Example:

Condition:
  Ticket is created
  AND
  Custom field "Impact" is "High"
  AND
  Custom field "Urgency" is "High"

Action:
  Set Priority to "Urgent"

5. Combined logic: the strongest approach

The greatest effect is achieved by combining several methods. Rules can, for example, upgrade a ticket if it both comes from a VIP customer and contains a critical keyword.

Example: A standard customer who writes "nedbrud" may get "High", while a VIP customer with the same word gets "Urgent".

Condition:
  Ticket is created
  AND
  (Requester > Custom field "Customer Tier" is "VIP" OR Requester > Organization > Tags contains "vip-account")
  AND
  (Subject field contains "nedbrud" OR Description contains "nedbrud")

Action:
  Set Priority to "Urgent"
  Add tag: "vip_critical"

The Priority Matrix: A Decision-Making Tool

When using Impact and Urgency, a matrix is a useful tool for defining the rules clearly and visually. The matrix can form the basis for priority triggers.

Escalation of Priority Over Time

A ticket's priority is not necessarily static. Triggers can be set up to automatically escalate a ticket if it is not handled within a given time frame.

Time-based escalation

Condition:
  Ticket has been created for more than 24 hours
  AND
  Status is "Open", "Pending" or "Hold"
  AND
  Priority is "Medium"

Action:
  Set Priority to "High"
  Add internal note: "Priority escalated from Medium to High after 24 hours of inactivity."

SLA-driven escalation

SLA measurements can be used to escalate before a deadline is exceeded.

Condition:
  Ticket is created
  AND
  Time remaining to "First reply SLA" is less than 30 minutes
  AND
  Priority is not "Urgent"

Action:
  Set Priority to "Urgent"
  Add tag: "sla_breach_warning"

Best Practices for Implementation

To support a successful implementation, the following principles should be applied:

1. Define objective and measurable criteria

Subjective assessments should be avoided. Use data that can be verified.

• Good: Customer Tier is "VIP", Form is "Critical Incident".
• Bad: Subject "sounds stressed".

2. Document the prioritisation logic

An internal document should describe:

• The definition of each priority level.
• All rules and triggers used.
• The order of priority for triggers (one trigger can overwrite another).
• Guidelines for when and how an agent can manually change the priority.

3. Start simple and build on it

Start with the most obvious rules (e.g. form-based prioritisation for outages). Once the system is running stably, more complex logic can be added, e.g. the Impact/Urgency matrix.

4. Review and adjust regularly

A priority model should be evaluated on an ongoing basis. Plan quarterly or half-yearly reviews to assess:

• Whether the distribution of priorities is appropriate (e.g. whether too many "Urgent" tickets are being created).
• Whether the rules are still relevant to the business.
• Whether new customer types or products require new rules.

5. Allow manual override (with responsibility)

Agents should be able to override an automatically assigned priority if the context requires it. When making a change, an internal note with a reason should be added, since this can be used as input for future adjustments to the rules.

Troubleshooting and Common Challenges

Even with a well-thought-out setup, challenges can arise.

Problem: The trigger runs, but the priority does not change.

• Solution:
  1. Check the trigger order: Another trigger that runs afterwards may overwrite the priority. Triggers run in order from top to bottom.
  2. Verify the conditions: Confirm that the conditions are met. Test with a real ticket and check fields, tags, form, etc.
  3. Check the action: Confirm that the action "Set priority to..." is configured correctly.

Problem: Too many "Urgent" tickets are being created.

• Solution:
  1. Make the conditions more restrictive: Add an AND condition, e.g. that the ticket must both contain "nedbrud" and come from a VIP customer in order to become "Urgent".
  2. Refine the keyword list: Identify words that create false positives, and replace them if necessary with more specific phrases.
  3. Introduce a negative condition: Subject contains ... AND Subject does not contain "spørgsmål om nedbrud".

Problem: The priority is inconsistent between different ticket types.

• Solution: Ensure that there are comprehensive triggers for all forms. If a form is not included in any priority triggers, the ticket keeps the default priority, which can create inconsistency.

Implementation Plan: Next Steps

Rolling out an automatic prioritisation system requires a structured approach. The following steps can be applied:

1. Phase 1: Analysis and design

   • Hold a workshop with key people from support, product and management.
   • Define the priority levels (Urgent, High etc.) and their meaning.
   • Decide which criteria (form, keywords, customer tier, fields) are to be used.
   • Prepare the priority matrix and document the overall logic.

2. Phase 2: Technical setup

   • Create the necessary custom fields (e.g. Customer Tier, Impact, Urgency).
   • Build the triggers one at a time. Start with the simplest and gradually add more complex logic.
   • Name the triggers clearly, so that they are easy to administer (e.g. "Priority: Urgent for VIP + Critical Keyword").

3. Phase 3: Testing and validation

   • Create test tickets for all scenarios and verify that the correct priority is assigned every time.
   • Let selected agents use the system during a pilot period and gather feedback.

4. Phase 4: Rollout and training

   • Roll the system out to all agents.
   • Hold a training meeting where the logic is reviewed, the documentation is presented, and the framework for manual override is explained.

5. Phase 5: Monitoring and optimisation

   • Create views in Zendesk that group tickets by priority, so that agents and managers can quickly form an overview.
   • Build reports that track the distribution of priorities over time and compare with SLA compliance.
   • Plan the first review meeting with a view to adjustment and optimisation based on real data.