A shared support@ mailbox stops scaling long before anyone admits it. Here is what actually changes when the mailbox becomes a tracked queue — and the three ways to connect one.
A shared support@ mailbox is the most common ticketing system in the world, and nobody chose it. It appears because one address is easier than a tool, and it works right up until the day two people reply to the same customer with different answers.
This is what actually changes when that mailbox becomes a tracked queue, and what to watch for when you connect one.
What breaks in a shared mailbox, specifically
The failure is never "email is bad". Email is excellent at delivery. It is bad at four things a support team needs:
- Ownership. A message in a shared inbox belongs to everyone, which means it belongs to nobody. Read receipts and flags are conventions, not state.
- History. When a customer replies three weeks later, the context lives in whoever happens to still have the thread.
- Deadlines. Nothing in a mailbox knows that a critical issue should be answered in four hours and a routine one in three days.
- Reporting. You cannot answer "how many requests did we take last month, and how many missed target" from a folder.
Every one of those is a state problem. A ticket is just a place to keep the state that the mailbox has nowhere to put.
What a ticket queue actually adds
When mail arrives at a connected mailbox, Ticku opens a ticket in a project, and from that point the message has somewhere to live:
- It has one assignee and a status that everybody can see.
- It has a deadline derived from its priority — four hours for Critical, eight for High, 24 for Medium, 72 for Low — with a countdown on the ticket and a notification to the assignees and project stakeholders if it is missed.
- Later replies thread onto the same ticket instead of opening a new one.
- People CC'd on the original mail become followers, so they keep seeing the conversation without being given access to your whole support project.
The customer notices none of this. They email an address and get replies by email. The change is entirely on your side of the conversation, which is the point — a migration that asks your customers to learn a portal is a migration most of them will ignore.
Threading is the part that quietly matters
Most of the value of a ticket queue evaporates if replies fragment into new tickets. A queue with three tickets for one conversation is worse than a mailbox, because now the fragmentation is recorded and reported on.
Ticku stamps its outbound mail with a Message-ID that embeds the ticket id, then reads In-Reply-To and References on the way back in. A reply is matched to its ticket either by the ticket id parsed out of one of our own message ids, or by matching the referenced ids against stored thread roots and previously processed messages — which is what catches a customer replying to their own earlier email rather than to your reply.
Anything that resolves to neither is treated as a genuinely new conversation. That is the correct default: inventing a link between unrelated mails is a worse error than opening one extra ticket.
Three ways to connect a Microsoft 365 mailbox
Connection mode is set per mailbox, and one organisation can run different modes on different addresses.
| Mode | Delivery | Consent needed | Access granted |
|---|---|---|---|
| Microsoft Graph (app-only) | Push, arrives in seconds | One tenant-wide admin consent | Every mailbox in the directory |
| Sign in with Microsoft | Polled | The mailbox owner signs in | Only that mailbox |
| IMAP / SMTP | Polled | None | Only that account |
Microsoft Graph is the only push mode. Graph holds a subscription against the mailbox and calls Ticku when mail arrives, so a ticket appears within seconds rather than at the next polling interval. It authenticates with the same app registration used for web sign-in, against your organisation's Entra directory — there are no per-tenant client secrets to collect or rotate. It does require Mail.ReadWrite and Mail.Send application permissions with admin consent; without them, every mail call returns 403.
Sign in with Microsoft is the delegated alternative. An administrator enters the support address, signs in as that mailbox, and Ticku keeps the resulting refresh token as the only long-lived secret. Choose this when a directory-wide grant is more than you want to give up for one support address, or when Global Admin consent is not available to you.
IMAP and SMTP with a stored password exists for Gmail app passwords, Zoho, and on-premises hosts.
The trap: IMAP with a password does not work with Microsoft 365
This is worth stating plainly, because it is the single most common way a mailbox connection fails on the first attempt.
Microsoft has retired basic authentication for IMAP, and SMTP AUTH, in Exchange Online. If you connect a Microsoft 365 mailbox by typing a username and password into an IMAP form, it will not authenticate. Not intermittently — at all.
If the mailbox is Microsoft 365, you want Graph or delegated sign-in. The IMAP mode is for everything else.
One mailbox, several queues
Most teams start with one address and later discover they need several destinations behind it. Routing rules handle that without asking customers to learn a new address.
A rule matches on one of two things, and the match type is itself the precedence order:
- Recipient address — each address in the
Toheader. This wins, because it is the address the sender deliberately wrote to. - Sender domain — the domain of the
Fromaddress. A reasonable guess about who somebody is, which fails exactly when a customer writes in from a personal address. - Fallback — the inbox's default project, for anything that matched nothing.
Recipient rules match mailbox aliases and plus-addressing, which is the practical way one mailbox serves several customers: give each of them their own alias, acme@, contoso@, and route on that.
Two properties make this safe to change on a live queue. Adding a rule is additive — mail that matched nothing before still lands in the default project, so a new rule never silently redirects traffic that was already flowing somewhere. And rules can be disabled rather than deleted, so parking one does not mean retyping it later, which is how routing gets retyped wrong.
Before you connect anything
Three things worth deciding first, because they are annoying to change once mail is flowing:
- Which project is the default destination. Everything unmatched lands there, so it should be a queue somebody actually watches.
- What happens to the source message — marked read, moved, deleted or left alone. Pick this deliberately; leaving mail untouched in a mailbox somebody also reads manually is how a request gets answered twice.
- Whether you can get admin consent. If yes, Graph gives you push delivery and no stored secrets. If no, delegated sign-in gets you the same mailbox with a narrower grant.
None of this is difficult. It is just easier to decide before a customer's escalation is the message testing your routing rules.
Ticku is help desk and project management software from Analytics Aura that runs as a Microsoft Teams tab app and as a standalone web application. Email-to-ticket works with Microsoft 365, Gmail, Zoho and on-premises mailboxes.