The Real Reasons Email Fails as a Ticketing System

Email has no unique identifier, no ownership field, and no shared status. Those three missing pieces are the actual reason it fails as a ticketing system, not just “things get lost sometimes.” A request forwarded three times becomes three disconnected threads. Nobody owns a message sitting in a shared inbox until someone decides to claim it. And nothing tells the next person checking in whether the issue is open, assigned, or already fixed, unless someone manually says so in a reply that not everyone on the thread will see.

This isn’t a productivity tip piece about inbox zero. It’s a structural explanation of why email specifically breaks down as a request-tracking tool, what a real ticketing system replaces it with, and the actual signs a workplace or facilities team has outgrown it.

The Cost Before You Even Add Ticket-Tracking

Email already eats a large share of the workday on its own, before it is asked to double as a request-tracking system. The widely cited McKinsey Global Institute research found that knowledge workers spend roughly 28% of the workday on email, close to 2.6 hours, managing around 120 messages. That figure is now over a decade old, but it remains the standard reference point because more recent estimates land in a similar range.

That baseline matters because every workplace or facilities team that tracks requests through email is asking an already-strained inbox to also function as a database, an assignment system, and an audit log. It was never built to do any of those three things.

What a Ticketing System Has That Email Doesn’t

Every row on the right side of that table is a structural feature. Every row on the left is something email simply does not have a field for, which is why bolting “ticketing” onto email always ends up as a workaround, not a fix.

A Concrete Example of How a Request Actually Gets Lost

An employee emails facilities@company.com about a broken conference room screen. The facilities coordinator forwards it to IT, since it might be a display driver issue, not a hardware failure. IT replies to the coordinator, not the original employee, assuming the coordinator will relay the update. The coordinator is out the next two days. The employee, having heard nothing, emails facilities@company.com again, creating a second thread with no link to the first. A different facilities team member picks up the second email, has no idea IT already looked into it, and starts investigating from scratch. Four people have now touched this one broken screen, across three separate email threads, and none of them can see what the others already did.

Nothing in that sequence was anyone’s individual mistake. Each person acted reasonably given what was in front of them. The failure is structural: no unique ID tied the two threads together, no ownership field said whose request this actually was, and no status field told the second facilities team member that IT had already been looped in. A ticketing system fixes this by making all three of those things a required part of submitting the request in the first place, not something four different people have to reconstruct from memory.

Why a Shared Inbox Doesn’t Fully Fix This Either

Moving from personal inboxes to a shared inbox like facilities@company.com is usually the first fix teams try, and it does solve one real problem: multiple people can now see incoming requests instead of one person’s inbox being the only visibility anyone has. But a shared inbox does not solve ownership. Every message in it still belongs to everyone and no one until a specific person actively claims it, which is exactly the condition that produces orphaned requests, several people see a message and each assumes someone else will handle it.

A shared inbox also does nothing to prevent two people replying to the same message without knowing the other already did, since there’s no built-in field marking who has claimed it. And it inherits every other structural gap email already has: no unique identifier that survives forwarding, no visible status, and no reporting on how long requests actually take to resolve. The commonly cited threshold in support and operations teams is that once you’re handling more than a handful of requests a day across more than a couple of people, a shared inbox stops being a fix and becomes its own bottleneck, just a shared one instead of an individual one.

The Structural Failures, One at a Time

No unique identifier. A ticketing system gives every request a number the moment it’s submitted. Forward it, reply to it, escalate it, the identifier stays constant and everything attached to it stays linked. Email has no equivalent. Forward a request to someone else and you’ve created a second, disconnected thread with no reference back to the original.

No ownership field. In a shared inbox, a message belongs to everyone and no one until a specific person actively claims it. That gap is exactly how requests go orphaned: several people see it, each assumes someone else will handle it, and nobody actually does. A ticketing system closes this by making ownership a required field, not an assumption.

CC doesn’t assign responsibility, it just adds spectators. Copying someone on an email does not make them responsible for the outcome. It adds a person who now has the message in their inbox and no clearer instruction than anyone else about whether they’re expected to act on it.

BCC actively breaks the thread. A person who was BCC’d stops receiving replies the moment the other party responds, since a reply naturally goes to who was visibly on the email, not who was hidden on it. That person still believes they’re part of the conversation. They aren’t anymore, and nothing tells them so.

No shared status. Nothing in an email marks a request as open, in progress, or resolved unless a specific person types that out in a reply, and only the people still on that specific thread see it. A colleague checking six weeks later has no way to tell if an issue was fixed or forgotten without re-reading the whole chain, if they can even find it.

No searchable single source of truth. The history of a recurring issue ends up split across whoever happened to be on each individual email thread. When someone who handled a lot of those requests leaves the company, a real chunk of institutional memory about what happened and how it was resolved leaves with them, since it lived in their personal inbox, not a shared record.

No audit trail for compliance-sensitive requests. Facilities, security, and compliance-related requests often need a defensible record of what was asked, by whom, and when it was resolved. A scattered set of email threads across different inboxes is a weak answer to “show us your record of that,” compared to a centralized, timestamped ticket log.

Signs a Workplace or Facilities Team Has Outgrown Email

The same issue gets reported by three different people. Nobody can see the request is already logged, because there is no shared, searchable place to check before reporting it again.

A departing employee takes months of history with them. Whatever they resolved, however they resolved it, and what they were told by other people, none of it is visible to whoever inherits their inbox.

Nobody can answer how long requests typically take. If leadership asks how long a facilities request usually takes to close and the honest answer is “we’d have to go check individual email threads,” that’s not a reporting gap, it’s the absence of a reporting function entirely.

One person has become the informal router. All requests funnel through someone who manually decides who handles what. That person is functioning as the ticketing system, and the whole process stops the day they’re out sick or on vacation.

Employees keep following up because they have no visibility. A request with no status field means the only way to check on it is to ask again, which produces exactly the “just following up” reply chains everyone already hates.

When Should You Actually Switch

There’s no single, universal number of daily requests that marks the line, since it depends on how many people submit requests and how many people fulfill them, not just volume. But the practical test is already hiding in the signs above.

The clearest one is the informal router. The moment a specific person, whether that’s officially their job or not, has become the one who decides who handles what, you’ve already crossed the threshold. That can happen at five requests a day in a ten-person office just as easily as fifty in a large one. The volume isn’t the trigger. The dependency on one person’s memory and availability is.

A second, more measurable test: try to answer how many open facilities or workplace requests exist right now, across the whole team, without checking multiple inboxes. If that number takes more than a minute to produce, or can’t be produced at all, email has already stopped functioning as a tracking system, whatever the daily volume happens to be.

What Switching Actually Fixes

Moving off email doesn’t just make requests look tidier. It fixes the specific structural gaps above: every request gets an ID that survives forwarding, an explicit owner instead of an implicit one, a status anyone involved can check without asking, and a history that stays with the organization instead of one person’s inbox. None of that requires employees to change how they submit a request in the first place, only what happens to it afterward.

Run the broken-screen example from earlier through a ticketing system instead. The employee submits it once, and it gets a ticket number. It gets assigned to facilities, and reassigned to IT with the ticket ID intact, not forked into a second thread. The status updates to “in progress” the moment IT picks it up, visible to the employee, the facilities coordinator, and anyone else looking at that ticket, without a single person needing to relay an update manually. If the coordinator is out for two days, the ticket doesn’t go quiet, it’s still sitting there, owned, with its current status visible to whoever checks next. Four people touching one request becomes one request, one thread, one visible outcome.

The Objections, Answered Honestly

“People will just keep emailing us anyway." Some will, especially at first, and that’s a real adoption cost, not a myth. Most modern ticketing systems are built to accept email as one submission channel and still create a proper ticket behind it, so the fix isn’t forcing everyone onto a new portal overnight. It’s making sure whatever channel someone actually uses still produces a ticket with an ID, an owner, and a status, instead of just landing in an inbox again.

“We’re too small for this to be worth it." Team size isn’t the real test, the informal-router sign is. A five-person facilities team where nobody can say who’s handling what right now has already outgrown email, regardless of headcount. A twenty-person team where everyone genuinely tracks every open request from memory hasn’t, yet.

“Our team doesn’t want to learn new software." This is a legitimate concern, not one to wave away. The honest answer is that adoption friction is real for any new tool, and it’s worth weighing against the cost of the current system, which is also real, just less visible because it shows up as missed requests and repeated follow-ups instead of a training session on a calendar.

“We already pay for email, why pay for something else." Email isn’t free once you count what it costs in missed requests, duplicated work, and the institutional knowledge that walks out the door when someone leaves. The comparison isn’t email’s cost against a ticketing system’s cost, it’s the visible cost of one against the hidden cost of the other.

Where Vizitor Fits

Vizitor’s ticketing system is built for workplace operations and facilities teams specifically, the group most consistently stuck using email or a shared inbox because most ticketing platforms are built for IT, not for a broken thermostat or a room setup request. A request submitted through Vizitor gets logged, assigned to a specific owner, and tracked through to resolution with a visible status the requester can check without sending a follow-up email. For teams already using Vizitor for visitor management or space management, ticketing sits in the same platform instead of becoming a sixth inbox to check separately.

Vizitor isn’t an enterprise ITSM platform for complex IT ticketing, and doesn’t try to be. For the specific problem this article covers, facilities and workplace requests currently trapped in email, it’s built for exactly that gap. For a broader look at ticketing systems generally, including the four common types and how to choose one, see our complete guide to internal ticketing systems.

Book a demo to see a request move from submission to resolution without a single reply-all.