Eight rules cover almost everything: claim before you write, never mark read as a signal, one topic per owner rather than one hour per person, notes go on the conversation and not in chat, close explicitly, hand over before you leave rather than after, never delete on behalf of someone else, and answer from the shared address. Anything longer stops being followed within a fortnight. The reason a charter fails is rarely disagreement, it is length.
Why the long charter always fails
Most teams write their rules the day something goes wrong. A customer got two answers, or nobody answered at all, and by the afternoon there is a document with fifteen conventions in it: colour codes, folder naming, a rule about who handles what on Fridays.
Three weeks later nobody opens it. Not out of laziness: fifteen rules is more than anyone recalls under pressure, and email is answered under pressure. The rules that survive are the ones you can state at the coffee machine without looking anything up.
So the goal is not a complete set. It is the shortest set that removes the failures you actually have.
The eight rules
1. Claim before you write, not after. The moment you decide to answer, say so in whatever way your tool allows: assign it to yourself, or announce it. The damage happens in the ten to twenty minutes between opening a message and sending the reply, so a claim posted after the fact prevents nothing.
2. Read is not a signal. Never treat a read message as a handled one, and never expect others to read it that way. Read only means somebody opened it, possibly on a phone, possibly to check one detail before a call they are now stuck in. This cuts both ways, and it is the single most common cause of a message nobody ever answers.
3. Split by topic, not by time slot. Quotes to one person, scheduling to another. Time slots look tidier and break on every conversation that crosses the handover, which is most of the ones that matter. Topics survive absences too: a colleague can cover “the quotes” without being briefed on each thread.
4. Notes belong on the conversation. “The customer called, I quoted 450” goes on the message, not in a chat thread. Anything you put in chat is invisible to whoever picks the conversation up next month, and to the person who joins next year. If your tool has no internal notes, the least bad substitute is a reply to yourself in the thread.
5. Close explicitly. A conversation is done when someone says it is done, with a status, not when it drifts off the first screen. Without an explicit closed state, your inbox tells you what has been glanced at rather than what remains, which is the wrong question.
6. Hand over before you go, not after you return. Before a holiday or a day off, reassign what is open. The alternative, coming back to forty conversations that waited for you specifically, is how a small team turns one person’s absence into a week of customer silence.
7. Never delete or archive on someone else’s behalf. In a Microsoft 365 shared mailbox, this is not just impolite: Microsoft documents that you cannot prevent users from deleting messages, and there is no undo shared across the team. In a Microsoft 365 group, a member who deleted their own copy has not touched the group’s. Two people can hold contradictory beliefs about what still exists.
8. Answer from the shared address. Not from your own. This one is a setting more than a habit, and it needs checking rather than agreeing: with Gmail delegation, when a delegate sends, their own email address appears. A customer who receives a reply from marie.dupont@ and then writes back to marie.dupont@ has just left your shared history for good.
The three rules people ask for that you should refuse
A response-time target for everyone. Tempting, unenforceable in a team of four where two people also do the actual work. Set a target for the first acknowledgement if you want one, not for the resolution.
A tag taxonomy. Almost every team invents twelve to fifteen tags in the first week and uses two by month three. Start with none. Add a tag the second time you wish you could filter on something specific.
A rule about tone or signatures. It belongs in your templates, not your etiquette. A rule you enforce by reading other people’s replies is a rule that makes people resent the mailbox.
How to introduce them so they stick
One rule per week, in this order: claiming first, then closing. Those two remove most of the pain, and they are the two people forget when given all eight at once.
Say them out loud rather than writing a document. A charter nobody reads is worse than no charter, because it lets everyone believe the problem is solved. When someone new joins, the rules should be transmissible in one conversation.
And review after a month with one question: which rule did we break, and did it actually cost us anything? A rule nobody breaks is either doing its job or was never needed. A rule everybody breaks is badly designed, not badly followed.
When rules are not the answer
There is a threshold past which etiquette stops working, and it has nothing to do with discipline. Rules that require each person to signal something manually are fragile in proportion to how busy the team is: they are forgotten exactly when they matter most, which is on the busy mornings.
Below three people answering daily, rules are usually enough. Above that, what you need is for the signal to be automatic: the claim visible in the list without anyone announcing it, the “someone is already replying” appearing on its own, the closed state built in rather than agreed.
That is what a shared inbox provides, and the honest way to put it is that it does not make a team more disciplined. It removes the moments where discipline was the only thing standing between you and a duplicate reply. With Trupeo you connect the mailbox you already have, Gmail, Outlook, Microsoft 365 or IMAP, and rules 1, 4, 5 and 8 become behaviour rather than convention.
See the features or our pricing. For the mechanics behind rule 2, read how to avoid duplicate replies; for the wider subject, the complete shared inbox guide.
Frequently asked questions
What rules should a team share a mailbox with?
Eight cover it: claim a conversation before writing, never treat read as handled, divide by topic rather than by time slot, keep notes on the conversation rather than in chat, close explicitly, hand over before an absence, never delete for someone else, and reply from the shared address. A longer list stops being followed within a fortnight.
How do you stop two people replying to the same email?
By making the claim visible before the reply is sent, not after. The collision happens during the ten to twenty minutes it takes to write, so any convention that signals after the fact prevents nothing. Splitting by topic reduces the overlap, and a tool that shows when a colleague is typing removes it.
Should we assign emails by time slot or by topic?
By topic. Time slots break on every conversation that spans the handover, and they leave nobody responsible for a thread that started in the morning and continued in the afternoon. Topics also survive absences, because a colleague can cover a category without being briefed thread by thread.
Where should internal notes go?
On the conversation itself. Notes in a chat app are invisible to whoever handles the thread next month, and to anyone who joins later. If your current setup has no internal notes, a reply within the thread is the least bad substitute, though the customer must not be on it.
How many people can share a mailbox before rules stop working?
In practice, around three people answering daily. Below that, spoken conventions hold. Above it, rules that depend on someone remembering to signal something fail precisely on the busy days. Microsoft’s own ceiling for a shared mailbox is 25 users, but coordination breaks long before capacity does.
Sources:
- About shared mailboxes in Microsoft 365: the impossibility of preventing users from deleting messages in a shared mailbox, and the 25-user maximum.
- Compare types of groups in Microsoft 365: the independent deletion behaviour between a group member’s personal copy and the group mailbox.
- Delegate and collaborate on email: the fact that a delegate’s own email address appears when they send, and what a delegate can and cannot do.
- Use a group as a Collaborative Inbox: the assignment and completion states available on a Google Group, and the permissions each one requires.