Zendesk side conversations are great when you want a quick thread alongside a ticket, without changing the core workflow. And now that side conversations can create child tickets, it’s even more useful for internal handoffs.
But there are still plenty of moments where a side conversation child ticket is the “easy button” and Escalator is the “keep-this-clean” option.
Use side conversation child tickets when the work is mostly a conversation
Side conversation child tickets shine when you need a formal, trackable request to another internal team or agent, and the main value is the back-and-forth.
A few things Zendesk calls out about how they behave:
Child tickets are created from side conversations and assigned to an agent or group (not an external address).
They inherit replies from the originating side conversation, but they don’t inherit other ticket updates (status changes, tags, CC/followers changes, etc.).
There usually isn’t a “two-way sync” between parent and child beyond a couple of exceptions (like public comments becoming part of the side conversation, and showing the child’s status/assignee on the parent).
There are also platform quirks: notification emails and side conversation triggers can fire twice when child tickets are enabled.
If your workflow is “ask Team B a question and track it,” side conversation child tickets can work great.
Use Escalator when you need structured work, not just a thread
Escalator is better when you want the ticket split to behave like an actual workflow step, with guardrails and consistency.
Here are the big differences that still matter in real teams:
1) External partner escalation (vendor style)
Side conversation child tickets are internal by design (assigned to agents/groups).
Escalator supports escalation patterns where the “child” ticket can be set up for a vendor style process, including using a different requester for the escalated ticket (your guide even calls out adding the vendor as the requester).
2) Admin-defined paths instead of ad-hoc choices
With Escalator, admins can pre-build escalation routes (fields, tags, macros, subject/body templates, sent-from address choices). That means agents pick the right path and go, rather than reinventing the setup each time.
3) Cleaner control over what gets copied
Side conversation child tickets can copy a defined set of fields at creation time (tags, followers, form/fields, requester), but it’s still a “copy once” model.
Escalator goes further with copy controls (including include/exclude logic, unsaved fields, comment + attachment selection), which is where a lot of teams save time and avoid messy sub-tickets.
4) Ticket relationship management is the whole point
Side conversation child tickets are tied to a side conversation relationship, including reliance on the child ticket’s external ID staying intact.
Escalator is built around ticket relationships: linking existing tickets, splitting into multiple sub-tickets, showing siblings, and guardrails like “warn when attempting to add grandchild.”
A simple rule of thumb
Need a parallel conversation with internal accountability? Side conversation child tickets are usually enough.
Need repeatable escalation workflows, external partner handling, or stronger controls over what gets created/copied/linked? That’s where Escalator earns its keep.
If you’re curious how this looks in practice, the Escalator user guide sections on Escalation process and Sub-ticket customization are the best places to start.
Try Escalator in Zendesk
If side conversation child tickets are feeling a bit “almost, but not quite” for your workflow, you can try Escalator without committing up front.
Try Escalator free for 14 days from the Zendesk Marketplace and see how escalations and sub-tickets fit into real Zendesk workflows.
Comments