A shared mailbox such as info@ or support@ is the first tool most small teams use for incoming requests. It is free, everyone understands it, and it works well while three people share it and the volume is low. Then one day a customer writes twice because nobody answered, and a colleague discovers that two people replied to the same message with different answers.
The mailbox is not the problem. The missing rules are. This article describes a small set of rules that makes a shared mailbox reliable, and the signs that tell you it is time for a ticket queue.
Rule one: every message has one owner
The most common failure is shared responsibility. When five people can see a message, each assumes another one will handle it. The fix is simple to state: within an agreed time, every message has exactly one named owner.
In practice this means a visible way to claim a message. Most mail tools let you assign a message, add a label with a name, or at least mark it with a colour per person. Pick one method and use it every time. If a message has no mark, it has no owner, and anyone triaging the inbox can see that at a glance.
Rule two: one person triages each day
Instead of "whoever sees it first", name one person per day or per half-day who looks at new messages and decides who takes each one. A rotating rota on a shared calendar is enough.
The triage person does not have to answer everything. They do four things:
- Read each new message.
- Remove noise, such as automatic notices and newsletters, or file it.
- Assign the rest to an owner, which may be themselves.
- Flag anything urgent or sensitive, such as a complaint, a legal matter or a payment dispute, directly to the person responsible.
Write down what happens when the triage person is absent. Without a named deputy, the rota quietly fails on the first holiday.
Rule three: a few labels, not a system
Small teams often build a label tree with twenty entries and then stop using it. Start with four states:
- New: nobody has looked at it yet.
- In progress: someone owns it and is working on it.
- Waiting: the owner is waiting for a customer, a supplier or a colleague.
- Done: answered and closed.
Add a topic label only when you have a reason, for example to count how many messages concern invoices. A label that nobody reads is cost without benefit.
The "waiting" state matters most. Without it, messages either clutter the inbox as unfinished or disappear as finished. With it, the owner has a short list to check each morning, and you can see how long things wait for outside answers.
Rule four: an agreed response time you can keep
Decide how quickly a first reply is expected, and write it down. Choose a time your team can actually meet on a normal week. "Within one working day" that is met is better than "within two hours" that is missed every Friday.
Check it once a month with a simple count: how many messages arrived, how many received a first reply within the agreed time, and how many are still open after a week. You do not need special software for this; a quick look through the mailbox is enough for a small team. If the target is missed often, the answer is either more capacity or a more modest target, and the numbers help you decide.
Rule five: private details stay out of shared notes
A shared mailbox is visible to everybody who has access. Agree what must not be in it: passwords, full payment details, and anything personal that not every member needs to see. Decide who has access, and review that list when people join or leave. Our article on who owns an internal tool after its author leaves covers the same principle for tools.
When to move to a ticket queue
A ticket queue gives each request its own record with an owner, a status and a history. It is not an upgrade you need on day one. Consider it when several of these are true:
- You regularly cannot tell who owns a message without asking.
- The same customer is handled by different people because the history is spread across inboxes.
- You need to hand a request between teams, such as support and finance, and keep the context.
- You want to count and review requests, and the mailbox makes this slow.
- More than one person is needed on a single request, and notes are being pasted into email threads.
If none of this is true, improve the rules first. If you do move, take the rules with you: owner, triage, four states and a response time are exactly what a ticket tool will ask you to configure. A deeper look at queue design is in our article on turning inbox chaos into a priority queue.
Common mistakes
- Buying a ticket tool before agreeing who owns what, which only moves the confusion into a new place.
- Letting everyone reply from their own address without saying who is responsible.
- Using many labels that nobody maintains.
- Setting a response time that sounds good but that the team cannot keep.
- Forgetting access reviews when people change roles.
Summary
A shared mailbox can serve a small team well if every message has one owner, one person triages each day, four simple states are used consistently and the response time is realistic. When owners become hard to see or requests need to travel between teams, move to a ticket queue and bring the same rules with you.
Sources
- Our related articles linked above.
- The rules, states and checks are a working practice for small teams, not a standard; adapt them to your company. No client results or market figures are claimed in this article.
