Zendesk Explore Recipes

Zendesk Explore recipes are somebody else showing their working. Follow one and you get a report. Read three and you can build anything Explore is capable of.

What a Zendesk Explore recipe actually is

Zendesk publishes recipes in its documentation: short walkthroughs that take one specific question and show the exact dataset, metrics, attributes, filters and formulas that answer it. Community members publish more.

They exist because Explore is a general tool. It can answer almost anything, which means the blank report screen offers you no clue where to start. A recipe removes the blank page.

The mistake is treating them as buttons to press. The value isn't the finished report, it's the pattern. Nearly every recipe is a variation on the same three moves: pick the right dataset, write a formula that turns a condition into a countable thing, then slice it by an attribute.

Worked example: tickets solved without an agent reply

A genuinely useful number. It catches spam being closed silently, duplicates being merged, and tickets that were resolved by someone picking up the phone instead.

The shape is a calculated metric that returns the ticket only when the reply count is zero.

IF ([Agent replies] = 0)
THEN [Ticket ID]
ENDIF

Then count that metric as a distinct count of tickets, and slice it by month.

Exact attribute names differ by dataset, so pick them from the panel on the left rather than typing what you read here. That's true of every recipe you will find, including the official ones, because the names have changed over the years.

What you do with the result: if the number is large and growing, find out which of the three causes it is. Each one means something different.

Worked example: backlog by age band

Backlog size is a bad metric because it hides shape. A backlog of two hundred tickets all raised yesterday is a busy week. Two hundred tickets averaging six weeks old is a failure.

Build a calculated attribute that buckets tickets by age, then count unsolved tickets grouped by that bucket.

IF ([Ticket age in days] < 7) THEN "Under a week"
ELIF ([Ticket age in days] < 30) THEN "One to four weeks"
ELSE "Over a month"
ENDIF

Three bars. Watch the third one. If it never empties, you have a category of work nobody owns, and no amount of throughput reporting will surface it.

Worked example: median first reply time by group

The recipe everybody wants, and the one most often built wrong.

Use the median, not the average. One ticket answered after a long weekend drags a mean into fiction, every single week. Explore offers both aggregators and the default isn't always the one you want.

Filter to business hours if you publish targets in business hours, because otherwise your overnight tickets make the team look worse than they are. Then slice by group and by week, not by day, since daily first-reply figures on a small team are mostly noise.

And exclude tickets tagged closed_by_merge. A merged duplicate typically never got a reply of its own, so it either distorts the median or vanishes from it depending on how the metric handles nulls.

Where recipes mislead

Three failure modes, all common.

The recipe assumes a dataset you're not using. Support Tickets and Support Updates answer differently shaped questions, and a formula copied across between them can run happily and return nonsense.

The recipe is old. Attribute names, dataset structure and available functions have all changed. A recipe that no longer builds is obvious. A recipe that builds but means something slightly different now isn't.

The recipe answers a neighbouring question. "Tickets solved" and "tickets solved by the assignee" are different numbers, and it's easy to ship the wrong one because the chart looked plausible.

Always sanity check against a number you already know. If your new report says you solved four hundred tickets last month and your views say six hundred, stop and find out why before you present it.

When to build your own

Once you have followed three or four recipes, build. The mental model is small: dataset, metric, attribute, filter, and formulas to create the metrics that don't exist yet.

Build your own when the question is specific to how your team works, which is most interesting questions. Recipes are written for a generic support team, and yours has a ticket form, a tag convention and an escalation path nobody else has.

Two habits make your own reports last. Name them so a stranger knows what the number means, including the filters, because "Tickets by group" and "Solved tickets by group excluding merges" are different reports and only one of them is honest. And write the definition into the description field. Six months later, nobody remembers whether the median excluded weekends, and the argument that follows costs more time than the report ever saved.

Keep the recipes for learning the syntax. Keep your own reports for running the operation.

FAQ

Frequently asked questions

Where do you find Explore report examples?

In the Zendesk recipe library. Zendesk Explore report examples there come with the Zendesk Explore formulas written out, which is how most people learn to write a Zendesk Explore custom metric.

Where do I find Zendesk Explore recipes?

In the Zendesk documentation and community, published as step-by-step walkthroughs for specific reporting questions.

Why does a recipe not work in my account?

Usually a different dataset, a renamed attribute, or a plan that doesn't include custom metrics. Pick fields from the panel rather than typing the names from the article.

Do recipes need a paid Explore tier?

Anything involving custom metrics or formulas needs the tier that allows building reports. Viewing prebuilt dashboards does not.

Should I use median or average for reply times?

Median, nearly always. A single overnight outlier moves an average far more than it moves reality.

How do I check a new report is right?

Compare it against a number you already trust, such as a view count for the same period. Investigate any gap before you share it.

Every recipe gets cleaner without duplicates

Filtering closed_by_merge out is a patch. Removing the duplicates at source is the fix.

Start free trial

14-day free trial. No credit card required.