One user, two emails about the same problem. One email, two unrelated problems. DaemonLayer catches both during triage, so technicians only ever see one ticket per real issue.
Two Problems, One Pipeline
Real requests don't respect ticket boundaries. The same issue gets reported twice. One email bundles three unrelated asks. Both patterns waste technician time and both are caught automatically, before routing ever happens.
A user emails twice about the same outage, or two users report the same failure independently. Ticket Merge recognises the match and folds the new ticket into the original, so your team works one incident instead of two, three, or ten.
"Reset my password, and our new hire starts Monday" is two unrelated work items in one email. Ticket Split breaks genuinely independent requests apart so each one gets its own category, priority, and routing decision.
Ticket Merge
Triage compares every new ticket against recent history. When it finds a high-confidence exact duplicate, the ticket is handed to the Ticket Merge workflow instead of being routed normally.
Triage flags the ticket as a likely duplicate of a specific earlier ticket, with concrete evidence: same reporter, same error, raised minutes apart. A confidence score decides what happens next.
The match must clear every guardrail before anything happens. If approval is required, an admin sees both tickets and the evidence side by side before the merge is applied.
The duplicate is closed and cross-linked to the surviving ticket in your PSA. The requester gets a reply pointing to the ticket that's actually being worked. Nothing is silently dropped.
Ticket Split
Before any routing decision is made, triage checks whether a ticket actually contains more than one independently actionable request. If it does, each one is split out and triaged on its own.
A candidate only splits if it's independently actionable, has a different root cause, and needs a different resolution path. Sequenced steps and shared-cause symptoms stay as a single ticket.
Too many detected issues and DaemonLayer leaves the ticket whole rather than over-splitting. Where approval is required, an admin reviews the proposed breakdown before any child ticket is created.
A ticket is created per additional issue, inheriting the reporter and client. Every resulting ticket, original and new, goes back through triage independently and gets its own category and routing.
Biased Against Splitting
"I can't log in and Outlook won't open" stays one ticket — one root cause, two symptoms. "Reset my password, and separately, new hire Anna starts Monday" splits — different people, different work, different queues.
Sequenced work never splits either. "Reset my password, then add me to Finance" stays one ticket — splitting it would only cut one request into two half-finished pieces, not resolve anything faster.
A rejected merge or a skipped split never loses a ticket or degrades routing. Every failure mode falls back to normal triage.
Configuration
Both workflows are opt-in and independently configurable, so behaviour can match how cautious or aggressive each client needs you to be.
Set the confidence threshold, the lookback window for what counts as recent, and which duplicate classifications are allowed to merge automatically.
Cap the maximum number of issues that can be split out of a single ticket before the overflow guard steps in and leaves it whole.
Choose whether the original requester is told their ticket was recognised as a duplicate or split into separate requests.
Related
Connect your PSA, and DaemonLayer starts triaging, resolving, and routing, no scripting, no setup calls. Cancel anytime.
Prefer a walkthrough? Book a demo →
