A support ops manager posted to r/helpdesk. They had inherited a queue with 1,200 open tickets. Spent three months triaging — bringing it down to around 400. Felt good about the progress.

Then they found a second inbox.

A contact form they hadn't known about. No routing rule, no queue owner, no SLA clock. It had been receiving tickets the entire time, sitting completely outside every report they'd ever run. Three months. Hundreds of tickets. Zero alert.

"We have been losing customer tickets for three months and nobody noticed."

If you run support operations for any team with more than one intake path, this is not an edge case. It is a system failure waiting to happen. Here is exactly how it works — and why the standard helpdesk tools don't catch it.

How tickets disappear without a trace

The phrase "lost tickets" suggests something dramatic. A deletion. A bug. An outage you'd know about.

The reality is more mundane and more dangerous. Tickets don't vanish. They go somewhere — just not somewhere anyone is watching.

There are three mechanisms behind nearly every case of tickets disappearing undetected.

Unmonitored intake paths

Most support teams have more intake paths than they think. The primary helpdesk inbox. A second email alias from a product relaunch two years ago. A contact form someone built for a campaign and never decommissioned. A chat widget that routes to email on weekends. An integration from a tool you replaced.

Each one of these is a potential blind spot.

Routing rules in most helpdesks assume the ticket arrives in the right place. They don't validate whether the intake path it came from is still active or monitored. If a contact form sends email to an alias that nobody has checked since the last ops manager left, those tickets exist — they just don't show up in any queue, any SLA report, or any dashboard.

Your helpdesk is counting tickets that made it into the system. It has no mechanism to count the ones that didn't.

Routing rules that lead nowhere

Helpdesk routing rules accumulate faster than they get cleaned up. A rule created for a product line that no longer exists. A group assigned to a team that reorganised six months ago. A view scoped to agents who've since been deactivated.

When a ticket matches a stale rule, it often routes to a group that exists in name only — no active members, no SLA assignment, no notification on arrival. It doesn't bounce. It doesn't error. It just sits.

These tickets are technically in the system. They show up in your total open count. But they're invisible to the agents doing actual work, and they rarely surface unless someone manually audits group-level queues.

No queue depth thresholds

This is the structural gap that makes the other two invisible.

Every major helpdesk platform — Zendesk, Freshdesk, Help Scout — measures what happens to tickets after they're opened. Response time. Resolution time. CSAT score. SLA compliance against the tickets an agent touched.

None of them, by default, alert you when a specific intake path or routing group has gone silent. No notification when no tickets have arrived through a contact form in 48 hours. No warning when a group's queue age is climbing because nobody has been assigned to it.

Silence reads as success. "No alerts" means everything is fine. It doesn't.

The 90-day version of this problem

The r/helpdesk post described three months of lost tickets before discovery. That's not unusual.

The pattern runs the same way almost every time. A new intake path is created or inherited. Initial traffic is low, so nobody notices the absence of tickets flowing through. The dashboard numbers look reasonable — total open count, SLA compliance, CSAT — because the tickets that are in the system are being handled. The missing tickets don't create a visible gap. They create an invisible one.

By the time someone finds the problem — usually when a customer escalates, or when a new ops manager audits the queue structure, or by accident during a tool migration — the backlog has been growing for weeks or months.

"847 lost tickets over 90 days" is a number from a real team doing a real audit. It wasn't a system failure they could point to. It was a routing gap nobody had thought to check.

What to look for in your own setup

You don't need a tool to do a basic audit. You need to know what to look for.

Start with intake paths. List every email address, contact form, chat widget, and integration that is supposed to send tickets to your helpdesk. Then verify each one — send a test ticket and confirm it arrives in the right queue, with the right SLA, assigned to the right group.

Audit your routing rules. Look specifically for rules that route to groups with fewer than two active agents, groups that haven't had a ticket resolved in 30 days, or groups created more than 12 months ago. These are your highest-risk blind spots.

Check for queues with no SLA. In most helpdesks, SLA policies require explicit assignment. A ticket in a group with no SLA policy attached is invisible to your compliance reporting — even if it's been sitting there for days.

Look at queue silence, not just queue activity. If an intake path normally generates 10 tickets a day and you haven't seen one in 72 hours, that's a signal worth investigating.

This is tedious to do manually. Most teams only do it after something has already gone wrong.

Why this happens to careful teams

The support ops managers dealing with this problem aren't operating sloppily. They're working from the information the platform gives them. And the platform tells them what happened to the tickets it processed — not what happened to the ones it didn't.

Helpdesks measure from arrival forward. They don't tell you what arrived versus what should have arrived. They can't tell you about an intake path that's silent because something upstream broke, versus one that's silent because it's having a quiet week.

This is the version of the lost-tickets problem that catches careful people. Not negligence — a structural information gap the tools don't address.

The same dynamic plays out inside the queue itself, in a different form. A ticket arrives, routes correctly, and then gets buried — not lost, just invisible under volume. That version of the problem is worth understanding separately.

What a daily audit catches

A daily automated scan of your open tickets doesn't replace a full audit of your intake architecture. That routing work is yours to do. But it addresses the second half of the problem: once a ticket is in the system, making sure nothing ages in silence.

The Buried Ticket Audit runs against your current open queue, scores every ticket by urgency — combined signal across unassignment age, SLA breach, and inactivity — and delivers the ranked list to your inbox before you open your helpdesk.

It doesn't prevent tickets from disappearing into an unmonitored inbox. But it catches everything inside your queue that's at risk right now, before a customer escalates.

The first audit is free. No card required.