A customer replies to a resolved ticket four days later: two words of thanks, then one more question. If the reopen window has expired, that reply does not land on the old ticket. It opens a new one, carrying none of the earlier conversation, at the back of the queue. Whoever picks it up asks the customer to describe the problem from the beginning, and the customer has described it twice already.
Nobody misconfigured anything. That is the ticket model working as designed, and it is the half of the model that most vendor explanations move past quickly.
The short version
- An email ticketing system changes the unit of work. A conversation stops being a thread sitting in a mailbox and becomes a record with an ID, a state, a priority and a clock attached to it.
- Your mail provider, your domain and your address stay exactly where they are. What changes is what happens after the message lands.
- What you buy is a queue that survives someone going on holiday and numbers you can report. What you pay is process weight plus a set of customer-facing side effects: acknowledgement mail, reference numbers in subject lines, and threading that breaks on forwards and address changes.
- Neither Microsoft 365 nor Google Workspace ships one. You can build a rough shared queue out of a shared mailbox, categories and rules, and the walls are documented: 25 users on a shared mailbox, a 256 KB inbox rule budget, and exactly one redirection before a message is dropped with no bounce.
- Under roughly ten people on one channel with no response time written into a contract, the ticket model usually costs more process than it returns.
What an email ticketing system actually is
An email ticketing system takes every message arriving at an address like support@yourcompany.com and converts it into a record. The record has an identifier, a state (new, open, pending, resolved, closed), usually a priority, an owner, and a timestamp that a response target is measured against.
That is the whole idea, and the important word is converts. In a mailbox, the unit of work is a thread, and a thread has no properties beyond what the mail protocol gives it: participants, a subject, a date. In a ticket system, the unit of work is a database row that happens to have email attached to it. Everything the category sells you (queues, priorities, SLA clocks, per-agent reporting, escalation rules) is built on fields that a thread does not have and cannot be given.
You will see the same product described as an email based ticketing system, an email help desk or email ticketing software. The terms are interchangeable in practice. What varies is how much the tool insists on the ticket abstraction: some keep the conversation looking like mail and hide the record behind it, others put the record in the foreground and treat the email as a payload inside it. That difference shapes your team's daily experience more than any feature list does, and it only shows up when you watch someone work a real queue in the tool.
One thing does not change: the mail keeps arriving at your provider and going out from your address. Customers see replies from support@yourcompany.com either way. If the shared address itself is the part you have not set up yet, what a shared inbox is and how the built-in routes work is the ground floor under this whole question.
How an email ticketing system works: what happens to a message
The path has seven steps, and the two that decide whether the system feels reliable are not the ones that get explained.
Capture is the easy part. The system connects to your mailbox over the provider API, or you forward mail to an address it owns, and everything arriving there enters the pipeline. Then comes thread matching, which is where the trouble starts: the system has to work out whether this message is a new request or a reply to something it already knows about. It reads the References and In-Reply-To headers first, falls back to a reference string in the subject line, and sometimes falls back further to sender plus subject similarity. New requests get an ID stamped on them, and whether the customer ever sees that ID is a configuration choice I will come back to.
After that the system applies a category and often a priority, by rule or by model, which is where a request lands in the wrong queue and waits behind work that matters less. It hands the ticket an owner by round robin, by rule, or by someone claiming it. Unassigned tickets age quietly. A first response target starts counting at the same moment, though whether anything visible happens when it expires is a separate setting and a separate question.
The last step is the one that produced the scene at the top of this page. Someone resolves the ticket, and what a later reply does then is governed by a reopen window you configure: inside it, the reply reopens the original; outside it, you get a new ticket with nothing attached to it.
| Step | What the system does | What breaks when it gets this wrong |
|---|---|---|
| Capture | Pulls mail from the connected address | Requests arriving at a second address nobody connected stay invisible |
| Thread matching | Decides new request or reply to an existing one | One conversation becomes two tickets, and two people answer it |
| ID assignment | Stamps a reference, often into the subject | Customer or client strips it, and matching falls back to guessing |
| Classification | Applies category and priority | Wrong queue, and the request waits behind less urgent work |
| Assignment | Gives the ticket an owner | Nobody owns it, and it ages quietly |
| Response clock | Counts against a target | Nobody hears about the breach until the customer mentions it |
| Close and reopen | Ends it, and rules what a later reply does | A reply past the window starts over with no history |
What the ticket model gives you that a mailbox cannot
Three things, and everything else on a features page follows from them.
The first is a queue position that survives absence. In a mailbox, working state lives in people's heads and in who happens to have read what, so when someone goes on holiday their open threads go with them. In a ticket system the state sits on the record: a colleague opening the queue on Monday sees what is outstanding, how long it has been outstanding and who had it, without asking anyone.
The second is a clock you can report on. Median first response time, resolution time, per person, per category, per week. The moment someone asks whether you are getting slower, a mailbox cannot answer and a ticket system can, and if a response time appears in a customer contract this stops being optional.
The third is a countable history. How many refund requests arrived last quarter, and how many of those turned into escalations. That is unanswerable from a mailbox without somebody reading a year of mail, and it feeds most of the staffing and product decisions support ever makes.
A ticket system does not make anyone answer faster. It makes the queue legible, which is what lets you find out why you are slow. The priority order is still yours to define, and a triage process written down before you automate it is the exercise that produces one.
What the ticket model costs you: the limitations vendors skip
Every item here is a real, common, predictable cost of running support as tickets. Knowing them before you buy is the difference between configuring around them and discovering them from an annoyed customer.
Automatic acknowledgements annoy the people who asked a small question. Most ticket systems send an auto-reply confirming receipt. For a customer reporting a complex bug, that is reassurance. For a customer asking "do you ship to Ireland", a robot telling them their case is important arrives as noise, and it arrives before the answer does. Teams that switch acknowledgements on globally and never revisit the wording are the reason the genre has a bad reputation.
Reference numbers in subject lines are fragile. Header-based matching handles the normal case, and real mail is frequently not the normal case. A customer forwards the thread to a colleague who replies from a different address. Someone starts a fresh message rather than replying. A mail client rewrites the subject. When header matching fails and the reference string is gone, the system opens a second ticket, and two agents work one conversation from opposite ends.
Reopen windows create dead ends. Set the window short and legitimate follow-ups start over with no history. Set it long and tickets you thought were finished keep waking up, which makes your resolution numbers fiction. No setting is right for every conversation, so pick the failure you would rather have and tell the team which one you picked.
Agents live in a second interface. Most people are fast in their mail client because they have used it for a decade. Move them into a ticket UI and they are slower for a few weeks, and some of them stay slower. That cost is real and mostly temporary, and it is paid during the exact period when leadership is watching to see whether the purchase was worth it.
Somebody has to own the configuration, permanently. Categories, rules, SLA policies, macros and views all decay. Ship a new product line and the category list stops matching reality; nobody notices for a month because the tickets still get labels, just less true ones. Without a named owner, the system settles into being an expensive mailbox with worse ergonomics than the one it replaced.
The formality changes how customers write to you. Some of that is good: structured forms produce better bug reports. Some of it is not. A conversation that would have been three quick exchanges becomes a case with a status, and the customer starts behaving like a claimant rather than a person you know.
All six are manageable if you know about them before go-live. Most teams meet them in month two instead, from a customer.
Tickets or threads: which model fits your team
The decision underneath the shopping is whether a conversation should stay a conversation with an owner attached, or become a record in a queue. There is a middle option that gets less attention than either extreme, and for teams under about ten people it is very often the right one: keep the thread shape and add the two fields a mailbox lacks. A shared inbox tool like TriageFlow classifies mail on arrival and attaches an owner and a status to the conversation without converting it into a ticket record, so you get a shared queue without the acknowledgement mail and the reference numbers.
| Threads with an owner | Tickets | |
|---|---|---|
| Team size it suits | Roughly 2 to 10 people answering | 10 and up, or a split first line and second line |
| Channels | Email, perhaps one more | Email plus chat, phone and web forms landing in one queue |
| Response targets | Internal goals you want to hit | Times written into a contract you have to evidence |
| Who runs it | Whoever answers mail, part time | Someone who owns the configuration permanently |
| What the customer sees | An ordinary reply from a person | An acknowledgement, usually with a reference number |
| The failure mode | Under-powered: you count things by hand | Over-powered: a third configured, used as a costly mailbox |
Team size is the first row because it is the first question everyone asks. It is also the weakest signal in the table, and the four rows under it should outvote it whenever they disagree.
Once you have picked a side, the purchase itself is a separate exercise: the criteria, pricing mechanics and trial questions that decide the purchase works through it for this whole category.
Does Outlook or Microsoft 365 have a ticketing system?
No. There is no ticket object in Exchange Online or Outlook, no reference number, no response clock and no per-agent queue report. What Microsoft gives you is a set of building blocks that get a small team surprisingly far, plus documented walls that tell you when the construction is finished.
The blocks are a shared mailbox, categories used as a status field by convention, and rules. That combination handles two or three people answering a modest volume, and it costs nothing on top of a subscription you already hold. Four documented limits decide how far it stretches.
Twenty five users, and duplicated messages past that. Microsoft's shared mailbox documentation states that a shared mailbox supports a maximum of 25 users, and that if too many users access it at the same time "they might experience connection failures or duplicated messages". The same page is blunt about three other constraints: only people inside your organization can use a shared mailbox, so an outsourced agent or a contractor cannot be given access; mail sent from one cannot be encrypted, because the mailbox has no security context of its own to hold a key; and you cannot prevent members from deleting messages, which matters the moment your queue is also your record.
Rules run out, and the budget is in kilobytes. Exchange Online's published limits put the inbox rule quota at 256 KB per mailbox across the Microsoft 365 business and enterprise plans, cap transport rules at 300 for the organization with 8 KB per rule, and cap a redirecting rule at 10 recipients. Rule budgets sound generous until a routing scheme built by four different people over two years hits the ceiling mid-Tuesday.
Exactly one redirection, and the second one loses the mail silently. This is the fact worth knowing before you build anything ambitious out of rules. The same limits document lists "Number of times a message is redirected: 1 redirection" for every Exchange Online plan, and the explanation above the table spells out the consequence: if user A's rule redirects to user B, and user B's rule forwards to user C, the message reaches B and stops there. It is "dropped without sending a non-delivery report (NDR)". No bounce, no error, no trace in anyone's inbox. Chained routing on a shared mailbox fails invisibly.
Automatic replies fire once per person, not once per request. Teams reaching for an acknowledgement usually reach for automatic replies first. Microsoft's documentation is explicit that the feature "automatically sends a customized message once to each person who emails you during your absence". Once to each person. A repeat customer's second request gets nothing, so this cannot serve as a per-request confirmation no matter how you word it.
One more Microsoft option is worth ruling in or out early, because teams reach for it by reflex and it behaves differently from a shared mailbox: whether a distribution list is the cheaper answer takes five minutes and occasionally ends the whole project.
Does Gmail or Google Workspace have one?
Also no, and Google's near miss is more interesting than Microsoft's.
Google Groups Collaborative Inbox is the closest thing either platform ships to a workflow layer. Members can assign a conversation to someone, mark it complete, mark it a duplicate, or mark it as needing no action: three states and an assignee, which is most of a ticket under another name. For a small team that can genuinely be enough.
The trap is that none of it works out of the box. Per Google's Collaborative Inbox documentation, assigning a conversation and marking it complete both require the "Who can moderate metadata" permission, while marking something duplicate or no action needed requires "Who can moderate content". Both are permissions a group owner has to grant, and nothing in the interface points at them when they are missing. The common outcome is a team trying the feature, finding that nobody can assign a single conversation, and concluding the product is broken. It is not broken. It is switched off.
What you still will not have: a reference number, a response clock, an escalation rule, or a report showing median first response time. Assignment without a clock is a label with a name on it.
If your plan is to build the routing on the admin side instead, know the ceiling before you design around it. Google's Gmail settings size limits cap the combined size of all Gmail settings in a Workspace account at 5 MB, allow 1,000 settings in total, permit 1,000 regular expressions at 4,000 characters each, and hold the "Also deliver to" setting to 100 recipients. That is a large budget for a small team and a real constraint for a routing scheme that grows for three years.
| What a ticket system does | Microsoft 365 | Google Workspace | What is still missing |
|---|---|---|---|
| One address several people work | Shared mailbox | Collaborative Inbox, delegation | Nothing, both handle this |
| An owner on the record | Categories by convention only | Assign, behind a permission | Microsoft has no assignee field at all |
| A state | Categories and flags | Complete, duplicate, no action | Neither state is enforced or reported on |
| A reference the customer can quote | None | None | No number to put in a subject line |
| A response clock | None | None | No target, no breach alert |
| Reporting | Counting by hand | Counting by hand | No first response time out of the box |
| Routing | Inbox and transport rules | Admin routing rules | Rule budgets, and one redirection before mail is dropped |
What "free" and "open source" actually cost
Two questions come up before any others: is there a free option, and is there an open source one. Both are reasonable, and three different answers hide inside them.
Free because you already paid for it. The shared mailbox and Collaborative Inbox routes above. Genuinely free, genuinely limited, and the right answer for more teams than the category likes to admit. Their limits are published, which is why the sections above can quote them, and hitting one is the honest trigger to spend money.
Free tier of a commercial product. Usually capped on seats, on ticket volume, or on the features that make a ticket system worth having, which tend to be reporting and automation. These are useful for finding out whether the model fits your team. Plan for the cap rather than around it: the tier exists to be outgrown, and a migration at month nine costs more than starting on the paid plan would have.
Self-hosted open source. The licence is free and the cost moves somewhere less visible: a server, upgrades, backups, someone competent to run all three, and email deliverability, which is the part that surprises people. Getting outbound mail from a self-hosted system to reliably reach inboxes rather than spam folders is specialist work involving authentication records, sender reputation and monitoring. If you have an ops person who wants this, it can be an excellent deal. If the plan is that support will run it in their spare time, the plan is that nobody will run it.
The comparison worth doing is the total cost of each option against the cost of the setup you have now, including the hours your team already loses to sorting mail by hand.
Signals you are ready, and signals you are not
Team size and volume make poor triggers, which is why the table above puts team size first and then argues with it. What actually decides this is events that have already happened.
You are ready when:
- A response time appears in a customer contract or a public commitment, and you cannot currently evidence whether you meet it.
- Requests arrive on more than one channel and have to land in one ordered queue, rather than in three places somebody checks in rotation.
- Somebody asks for the history of a single customer's requests over a year and you cannot produce it without reading a mailbox.
- Work is genuinely handed off between a first line and a second line, and things get dropped in the handover.
- Your backlog needs to be worked in priority order rather than date order, and today it is worked in whatever order people open things.
You are not ready when:
- Three people answer one address, nobody has sent a contradictory reply, and no customer has complained about waiting.
- Nobody will own the setup, and the plan is that it gets maintained as you go.
- The real problem is that four people are doing six people's work. No ticket system has ever fixed understaffing, and the two are easy to confuse. A support team size calculator will settle which of them you have before you spend anything.
- What you actually want is reporting, and you have not yet tried getting it out of the setup you have.
That last one is worth sitting with. Plenty of teams buy a ticket system to answer one question about response times, then spend six weeks configuring a platform to produce a number they could have tracked in a spreadsheet for a month first. For the wider picture, how a support system fits the rest of your service setup puts the ticketing decision next to the others you will make around it.
If you do decide to buy, test these four things
The general evaluation criteria for this category, and the pricing mechanics that decide the invoice, are worked through in the shared inbox and helpdesk buyer's guide rather than repeated here. Before you compare quotes, put a figure on what the current setup already costs you: a shared inbox ROI calculator does that arithmetic in a couple of minutes. Four tests are specific to the ticket model, and a generic evaluation will miss all four.
Forward a real thread and watch what happens. Take a genuine conversation with quoted history and an attachment, forward it from a second address, and see whether the system matches it to the original ticket or opens a new one. Then reply with the reference number stripped from the subject line and watch again. This single test tells you more about daily life in the tool than any demo.
Read the acknowledgement as a customer. Ask for the exact auto-reply in its default wording, then ask whether it can be switched off per category. The answer to the second question is often no, which turns the cost described above into a permanent feature of your support experience.
Break a ticket and reopen it. Close a ticket, reply a day later, reply a month later. Establish what the reopen window is, whether you can change it, and what the customer sees in each case.
Ask for an export and look at it. Everyone answers yes to "can we export". Ask for a sample export file instead, and check that ticket IDs, states, owners, timestamps and internal notes survive it. Mail you can export as raw messages without its ticket metadata is a partial export, and partial export is what turns changing tools later into starting over.
Rolling it out without breaking the customer experience
Four decisions, made before go-live rather than during.
Decide whether customers see a ticket number at all. Some tools let you keep the reference internal and send replies that look like ordinary mail, which removes the subject-line fragility described earlier. If your customers are consumers or small businesses, that is usually the better choice. If they are enterprises who quote reference numbers back at you, do the opposite.
Write the acknowledgement yourself. The default is always some variation of "your request is important to us". Say what actually happens next and when, or send nothing at all. Nothing is better than a robot being warm at someone.
Run in parallel for two weeks. Keep the old mailbox receiving a copy while the new system takes the traffic, so anything that slips past capture or routing still lands somewhere a human looks. A cutover with no overlap is how mail gets dropped in week one.
Decide what happens to the open backlog. Importing three hundred open threads as three hundred tickets produces a queue nobody can face on day one. Most teams do better closing the backlog in the old system while working new arrivals in the new one, and accepting a fortnight of two places to look.
Leave automation until after the manual version works. Once requests are reliably landing in one queue with an owner and a state, what to automate first once requests are in one queue is the natural next step, and the answer is usually the sorting rather than the answering.
Frequently asked questions
How does an email ticketing system work?
It connects to your support address, then converts each incoming message into a record with an ID, a category, an owner, a state and a response clock. Replies are matched back to the existing record using mail headers first and a reference string in the subject as a fallback. That matching step is the one to interrogate in a demo, because when it fails you get two tickets for one conversation and nobody notices until both have been answered.
Do we need tickets if we already have a shared inbox?
Usually not yet. A shared inbox with an owner and a status on each thread already gives you the queue and most of the visibility, without the acknowledgement mail or the reference numbers. Tickets add a formal SLA clock, a per-request audit history, and multi-channel intake landing in one ordered queue. If none of those three shows up in a contract, an audit or your actual daily work, the thread model is doing the job.
Can we build one out of Microsoft 365 or Google Workspace?
Partly, and the two sections above give the specifics. Microsoft gets you a shared mailbox with categories and rules; Google gets you assignment and completion states in a Collaborative Inbox. Neither gives you a reference number, a response clock or a report, and both have published ceilings that a growing queue eventually meets.
Is there a free email ticketing system?
Depends which free you mean. Something is already included in your subscription, free tiers of commercial products exist with caps on seats or volume, and self-hosted open source is free of licence cost while moving the bill to servers, upgrades and mail deliverability. The first kind is underrated. The third is only cheap if you already employ someone who wants to run it.
What is the difference between a help desk and an email ticketing system?
Mostly scope. Email ticketing describes the mechanism: mail in, records out. A help desk is the wider product built around that mechanism, typically adding a knowledge base, web forms, chat or phone intake, and a customer-facing portal. In practice you will find the mechanism inside almost every help desk, and you will find plenty of ticketing tools that never grow into one.
How many people do you need before ticketing is worth it?
Around ten people answering mail is where the arithmetic usually tips, though headcount is the weakest of the signals. The ones that carry more weight: a contractual response time you have to evidence, more than one intake channel to merge, real handoffs between support levels, and a named person to own the configuration. Count how many of those four you have before you count heads.