Creating Your Own Metric with a Hard-Coded Filter - Zendesk Explore Calculated Metric

Creating Your Own Metric with Hard-Coded Filter

Support - Tickets Calculated Metric

Counts only tickets that meet a specific condition by embedding the filter logic directly into the metric.

Business value & use cases

Hard-coding a condition "locks" the filter inside the metric, avoiding conflicts or overlap that occur with dashboard filters. Useful when comparing subsets of tickets side by side in the same chart, especially where conditions differ across attributes. Ensures results are isolated and accurate without relying on UI filters that may return unwanted overlaps.

Dataset and dependencies

Dataset: Support - Tickets
Type: Calculated Metric
Dependencies: None (standalone attribute)

The code

Unlock to view full code

Not sure how to work with the code? Check our getting started guides.

Implementation steps

Go to Explore > Report Builder > Support - Tickets Dataset > Start Report.
Select the Calculator icon for Calculations.
Choose Standard calculated metric.
Paste in the code above.
Replace [Attribute] with the attribute you want to check, and "Value" with the condition.
Hint: use the "Select a field" drop-down to correctly pick out the attribute you want to use - avoids errors caused by spelling mismatches.
Validate and save.
Create one metric per condition and display them together in your report.

Validation tips

Spot-check a sample of tickets to confirm they match the intended conditions.
Compare against UI filters to confirm your metric isolates only the subset you expect.
Test multiple variations side by side to ensure they don't overlap.

Caveats and considerations

Each condition requires its own metric. This can mean creating multiple metrics if you want to compare many values. Works best when conditions are mutually exclusive or complex enough that the UI filter cannot achieve the same result.

Example use case - comparing one-touch tickets across channels

In Explore, a one-touch Email ticket will have VALUE(Agent replies) = 1, since the agent's first public reply is the resolution.

In Voice, we consider answering the call itself the first "touch", but Explore doesn't. No public webform reply is sent, so a one-touch Voice ticket shows VALUE(Agent replies) = 0. Even though the agent has handled the request on the call, there is no text reply recorded in Explore.

This difference makes it impossible to use a single UI filter to compare one-touch Email and Voice tickets. If you try Agent replies = 0 OR 1, you end up including both call and email tickets that don't match the intended definition.

Instead, you need to create two separate hard-coded metrics (see True One-touch Talk Tickets and % True One-touch Talk Tickets for the library versions):

IF ([Ticket channel] = "Email"  
AND VALUE(Agent replies) = 1)  
THEN [Ticket ID]  
ENDIF  
  
IF ([Ticket Channel] = "Voice"  
AND VALUE(Agent replies) = 0)  
THEN [Ticket ID]  
ENDIF

Note that this example voice metric is accurate, so long as voicemails or missed calls don't create tickets. If they do, you'll need to exclude these from your code, as they shouldn't count as a one-touch ticket. If wanting to use this data, it's also worth filtering for solved and closed tickets, to ensure you're not capturing tickets that may yet have another touch added.

Example chart

Example comparing one-touch tickets across channels using hard-coded filters

Related metrics / attributes

[% True One-touch Talk Tickets \
\ Support - Tickets Calculated Metric\
\ Shows the percentage of Talk tickets that were resolved in a single call without requiring a follow up reply via webform.\
\

[True One-touch Talk Tickets \
\ Support - Tickets Calculated Metric\
\ Counts Talk tickets solved without requiring a follow-up reply via webform.\
\

Now share real-time data with your team

Give agents a real-time view of key data from all your tools to help them win the day.

Learn how