Zendesk Side Conversations Report

There is no side conversation dataset in Zendesk Explore. That is not an oversight in your setup — it is a genuine gap in the product, and one of the most consistently requested reporting features Zendesk has.

The consequence is that a real and growing share of support effort is structurally invisible. Every email to a vendor, Slack thread with engineering, Teams message to billing, and child ticket spawned from a conversation is work your team performed, and none of it appears in ticket counts, reply counts, or handle time. Two tickets that both count as one ticket can differ by hours of coordination.

This guide covers the workaround Zendesk itself recommends — triggers that stamp tags so side conversations become reportable — plus the child-ticket technique that gets you actual durations, and how to read the result without over-claiming precision.

What this report should answer

• What share of tickets require internal collaboration to resolve?
• Which issue types, groups, or forms depend on outside help most?
• Do tickets with side conversations take materially longer to resolve?
• Is collaboration load growing while ticket volume stays flat?
• Which dependencies create the longest waits?

For the metric see side conversation rate. For the wider argument about why this load matters, see Zendesk side conversations and internal collaboration. Keep this beside the support metrics dashboard so hidden effort is read next to visible throughput.

Step 1: Instrument with triggers before you can report

Because there is no dataset, you have to create the data. Zendesk’s documented approach is to fire triggers on side conversation events and stamp tags on the parent ticket.

Build a trigger with the condition Object > Ticket > Side conversation | Is | Created, and an action of Add tags with a tag such as sc_created. Then repeat for the other events:

Add a second tag per trigger to record the channel — sc_email, sc_slack, sc_msteams, sc_ticket — if your dependencies span several tools. Knowing who you wait on is usually more actionable than knowing that you waited.

Three constraints to accept up front:

• Tags are binary, not counted. A ticket with one side conversation and a ticket with six both carry sc_created once. You are measuring incidence, not volume. If you need counts, use a numeric custom field incremented by the trigger, or the child-ticket method below.
• This is not retrospective. Tags only appear from the moment the trigger goes live. Every side conversation before that is unrecoverable, so start instrumenting now even if you will not report for a month.
• Tags accumulate on the ticket. They describe what happened at some point in the ticket’s life, not the state at a given time.

Step 2: Build the reports in Explore

Tags are reportable in the standard Support - Tickets dataset. One important detail: filtering on Ticket tags behaves differently from filtering on most attributes, because a ticket holds many tags at once. Prefer calculated metrics with INCLUDES_ANY over tag filters when you need clean percentages.

Side conversation rate

Create two standard calculated metrics:

Collaboration tickets:
IF (INCLUDES_ANY([Ticket tags], "sc_created")) THEN [Ticket ID] ENDIF

Solo tickets:
IF (NOT INCLUDES_ANY([Ticket tags], "sc_created")) THEN [Ticket ID] ENDIF

Report Collaboration tickets as a share of all tickets, trended weekly. That single line is the most valuable output of the whole exercise: it answers whether the work is getting harder even when volume is flat, which is the exact question teams struggle to evidence when asking for headcount.

Where collaboration concentrates

Keep the metric and add one attribute at a time to Rows:

• Ticket form — intake paths that predictably need outside help (Zendesk First Reply Time by Ticket Form Report)
• Ticket tags for issue type — topics with external dependencies
• Ticket group — teams that cannot resolve independently
• Ticket organization name — accounts whose requests always escalate
• Assignee name — read as a routing signal, not a performance one

If one form drives most collaboration, that is a triage design finding: the request is arriving at a team that structurally cannot complete it. See Zendesk Routing and Assignment Metrics.

The cost comparison

This is the comparison that converts a curiosity into a business case. Put your two calculated metrics side by side with:

• Full resolution time (min) — MED aggregator
• On-hold time (min) — where dependency waiting shows up
• Agent wait time (min) — time waiting on someone else
• Replies per ticket
• % Satisfaction score
• Reopens

Use medians throughout; collaboration tickets have long tails that destroy averages, for the same reason median resolution time is the more honest measure generally.

Most teams find collaboration tickets take two to four times longer to resolve and score materially worse on CSAT. Expressed as “18% of our tickets consume 45% of our resolution time,” that is a staffing argument, a triage argument, and a process argument in one sentence.

Whether dependencies actually respond

Compare sc_created against sc_replied. Tickets with a side conversation created but never replied to are dead-end dependencies — the team asked for help and got nothing, and the customer waited anyway.

A high created-without-reply share is one of the clearest signals that internal service expectations are missing. Customer-facing SLAs are usually well defined; internal ones almost never are, which is why the queue quietly waits on people who feel no urgency. Pair with Zendesk Agent Wait Time Report and Pending vs On-hold in Zendesk.

Step 3: Get real durations from child tickets

Tags tell you collaboration happened. For side conversations created as child tickets, you can measure how long it took.

Child tickets carry a default external ID in the form zen:side_conversation:<uuid>:<parent ticket id>. A standard calculated attribute extracts the parent:

REGEXP_EXTRACT([Ticket external ID], "^zen:side_conversation:.*:(\d+)$")

Add that attribute to Rows, exclude null values, and you can report:

• Child tickets per parent — an actual count rather than a binary tag
• Full resolution time (min) summed by parent — total time spent on collaboration for that ticket
• Open status time or time in status per child — where dependency work stalls

Two limits worth stating plainly. This only covers side conversations created as tickets — email, Slack, and Teams side conversations are invisible to it, so keep the tag method running alongside. And while the attribute identifies the parent ticket ID, you cannot report on the parent’s own metrics through it; the parent must be reported separately.

How to interpret the patterns

Collaboration rate rising while volume is flat

The work is getting harder without getting more numerous. This is the pattern behind teams that feel underwater while their volume chart looks calm, and it is usually driven by product complexity, policy changes, or a shift toward larger accounts. See Why support work feels heavier even when ticket volume is flat.

One form or tag dominates

A triage problem, not a capacity problem. Requests are landing with a team that cannot finish them. Either route them to the team that can, or give the frontline the permissions and knowledge to resolve without asking.

Side conversations created but rarely replied to

Internal response expectations are missing. Define them, measure them, and make the waiting visible to the teams causing it. Nothing else in this report is fixable until this is.

High collaboration with high reassignment

The team is both asking for help and handing tickets off — usually a sign that ownership is unclear. Every transfer adds context loss on top of the delay. Cross-check Zendesk Group Reassignment Rate Report.

Collaboration tickets have normal resolution time

Genuinely good news, and worth confirming rather than assuming. It means dependencies respond fast and the process works. Check whether that holds across all dependency channels, or whether one fast path is masking a slow one.

Reopens concentrated in collaboration tickets

Answers assembled from second-hand information are not sticking. The frontline is relaying an explanation it does not fully own, and the customer comes back. Pair with Zendesk Reopened Tickets Report.

Common mistakes

• Waiting for Zendesk to ship a dataset. There is none. Instrument now — the data only starts existing when the triggers do.
• Treating tag presence as a count. One tag equals at least one side conversation, never exactly one.
• Comparing periods across the instrumentation date. Pre-trigger tickets have no tags and will read as zero collaboration.
• Filtering on tags instead of using calculated metrics. Tag filters behave unexpectedly on multi-value fields and quietly distort percentages.
• Reporting only creation. Created-without-reply is where the actual delay lives.
• Using averages. Collaboration tickets have heavy tails by nature.
• Relying only on the child-ticket regex. It misses every email, Slack, and Teams side conversation.
• Blaming assignees. High collaboration usually reflects the work routed to someone, not how they handle it.

What to do when collaboration load grows

1. Confirm the instrumentation has been live long enough for a clean comparison window.
2. Measure the rate as a share of tickets, trended weekly.
3. Quantify the cost gap: median resolution time and CSAT, collaboration versus solo.
4. Find the concentration — one form, tag, or group usually explains most of it.
5. Check the reply rate on side conversations to separate slow dependencies from unresponsive ones.
6. Set an internal response expectation for the slowest dependency and report against it.
7. Decide between routing the work elsewhere or enabling the frontline to finish it.
8. Re-measure the rate and the cost gap after a month.

Where this report fits in your dashboard

• Zendesk Touches per Ticket Report — visible effort per ticket
• Zendesk Agent Wait Time Report — waiting on others
• Pending vs On-hold in Zendesk — how blocked time is recorded
• Zendesk Group Reassignment Rate Report — handoffs as the other dependency pattern
• Zendesk Escalation Rate Report — formal escalation next to informal help
• support metrics dashboard — the hub

FAQ

Is there a side conversation dataset in Zendesk Explore? No. Zendesk’s documented workaround is to use triggers that add tags on side conversation events, then report on those tags in the Tickets dataset.

Can I report on side conversations retrospectively? Not through tags — they only exist from when the trigger is created. Side conversations created as child tickets can be analysed retrospectively using the external ID pattern.

How do I count side conversations per ticket rather than just flag them? Either increment a numeric custom field from the trigger, or use the child-ticket external ID method, which gives a genuine count for ticket-type side conversations.

Which side conversation channels can I report on? Tags work for all of them if you stamp a channel tag per trigger. The external ID method only covers side conversations created as tickets.

Why do my tag-based percentages look wrong? Tag filters behave differently from single-value attribute filters because a ticket carries many tags. Use calculated metrics with INCLUDES_ANY instead.

Should side conversation tickets count in ticket volume? Exclude them from customer demand reporting — they are internal work, not customer requests — but include them in capacity reporting, because they consume real agent time.

See the collaboration load hiding inside your Zendesk tickets - start free