A customer writes on Tuesday to ask whether the replacement shipped. The thread has an owner and a label, because the team agreed on that convention months ago, so nothing about it looks broken. The owner is on holiday until the following Monday. The last entry on the thread is an internal note reading "waiting on warehouse", and nobody else knows who at the warehouse, what was asked, or what delivery date this customer was already promised. The thread sits there for six days, correctly assigned the whole time.
Nothing failed technically. Assignment worked, the label was right, the message was visible to five people. What was missing was an agreement about what happens to an assigned thread when the person holding it walks away from it. That gap is what team email management is, and it is the part no settings page can give you.
The short version
- Team email management is a process layer on top of whatever mailbox you already have. Access is a setting your admin flips in minutes. Everything after that is an agreement.
- The highest-value artifact is a one-page document naming who owns the address, what counts as picking a thread up, the response target in working hours, and who breaks a tie on priority.
- Most dropped threads are handover failures rather than triage failures. A thread waiting on somebody needs three things written on it: what the customer expects, what has already been promised, and what the next action is.
- Parts of your agreement run on trust because the platform cannot enforce them. A Microsoft 365 shared mailbox does not keep replies in a shared Sent Items folder by default, and a Gmail delegate's own address shows on messages they send.
- Three or four people on one address, with the agreement actually written down, do not need to buy anything. The trigger to move is a rule you cannot enforce, not a headcount.
What is team email management?
Team email management is what several people agree to do with one address so that every message arriving there gets answered once, by someone, inside a time the team has committed to.
That is a process definition, because the thing itself is a process. Search results for the term will hand you software lists, and the software is real and sometimes necessary, but it sits underneath the question instead of answering it. You can give five people access to support@yourcompany.com this afternoon without buying anything. What no setting decides for you is who picks up the thread that arrives at 16:55 on a Friday.
The reason it needs an agreement at all is structural. Email was built around one person owning one mailbox. An owner, a state, a due time, a record of who said what: none of those are properties an email thread carries on its own. Teams supply them with a convention or with software, and a convention that was never written down decays in exactly the situations where it matters most. Someone is sick, volume spikes, the person who knew the context is on a plane.
If you are still deciding which setup to run on, what a shared inbox is, plus the routes for setting one up covers that question. This article assumes the address exists and several people are already working in it.
The agreement: what has to be written down
This is the part most guides skip by saying "set clear guidelines". Here is the actual list: eight decisions, each with a default that works for a team of about five, and the specific thing that breaks if you leave it implicit.
| Decision | A default that works at five people | What breaks without it |
|---|---|---|
| Who owns the address | One named person, permanently. They hold the admin rights, the filters, the signature and this document. | Settings change and nobody can say who added the rule that is now eating half the mail. |
| What "picked up" means | Assignment happens before the reply is written, and it is visible to everyone. | Two people write the same answer and the second one finds out after sending. |
| The response target | A number stated in working hours, with the working hours defined. "Four working hours, 09:00 to 18:00, Monday to Friday." | Nothing is ever late, so nothing is ever escalated. |
| Who breaks a priority tie | One named person decides when two things are both urgent. | The loudest customer wins, which is rarely the most damaged one. |
| Where internal discussion happens | On the thread as a note. Chat is fine for speed, but the decision gets written back onto the thread before the day ends. | The reason you refunded someone exists only in one person's memory of a conversation. |
| What a waiting thread must carry | Three fields: what the customer is waiting for, what has been promised, what the next action is. | Handover turns into an interview, and the customer ends up explaining their problem twice. |
| Who may delete, and what gets archived | Nobody deletes. Archive on close. | Microsoft states plainly that you can't prevent users from deleting messages in a shared mailbox, so the written rule is the only control you have. |
| When this document gets reviewed | A date in the calendar. Monthly for the first quarter, then quarterly. | It becomes a snapshot of the week it was written, and people quietly stop following it. |
Two practical notes about the document itself. Keep it to one page, because a two-page version does not get read by the person who joins in March. And put it where the work is: pinned in the team channel, or linked from the mailbox signature template, so that "what does the doc say" is a five-second question.
You can fill this in during a single thirty-minute meeting. If one of the eight rows causes a real argument, that row is what the meeting was for.
Roles: who owns what, and who owns it today
Four roles are enough, and they are deliberately small. Two are permanent, two rotate.
The address owner is permanent and named. They own the configuration, the permissions, the automatic replies and the agreement document. This is a maintenance role rather than a management one, and it exists so that questions about how the mailbox behaves have exactly one destination.
The duty person handles today's triage. Their job is to make sure every arriving message is claimed, categorized and either handled or handed to whoever should handle it, which is a smaller job than answering everything. What a triage pass actually involves covers the per-message decisions; what matters here is that the role exists, is visible on a rota, and rotates. Whoever holds it permanently ends up absorbing every problem instead of reporting it.
The escalation contact is named, has a phone number, and is a different person from the duty person. If a thread needs a decision above the duty person's authority (a refund past policy, a legal-sounding complaint, an outage), the path is a name, not a judgment call.
The reviewer runs the weekly. Often this is the address owner, and at five people that is fine.
Coverage is the part that gets skipped, and it is where a rota either holds or does not:
- Meetings. If the duty person is in a block longer than your response target, duty passes for that block. Write down who it passes to.
- Sickness. Same-day cover is whoever is next on the rota, decided in advance rather than at the moment somebody calls in.
- Holiday. Duty is reassigned before the holiday starts, and every thread the person owns is handed over. Put both on the pre-holiday checklist.
- Two time zones. Duty follows the clock and the handover happens at the overlap. If there is no overlap, the handover has to be written rather than spoken, which raises the standard for what a handover note contains.
The life of one message, from arrival to close
Most teams have a rough version of this in their heads and no two versions match. Writing the states down forces the two nobody defines into the open: waiting on internal, and parked.
| State | Who is responsible while it sits here | What moves it on |
|---|---|---|
| Unclaimed | The duty person | Assignment, which happens before any reply is drafted |
| Being worked | The assignee | The reply going out, or a deliberate move into a waiting state |
| Waiting on customer | The assignee, with a follow-up date | A customer reply, or the follow-up date arriving |
| Waiting on internal | The assignee, never the internal team | The internal answer, chased by the assignee at an interval they set |
| Parked | The duty person, reviewed weekly | A decision at the weekly review: revive it or close it honestly |
| Closed | Nobody | A customer reply, which reopens it with its history attached |
The distinction that matters most is between "waiting on customer" and "waiting on internal". They look identical in a mailbox and behave completely differently. A thread waiting on a customer is healthy and can sit for days. A thread waiting on your own warehouse, developer or finance person is an internal debt that ages badly and is invisible to everyone except the assignee. If you watch one thing beyond the obvious, watch how long threads sit in "waiting on internal".
"Parked" is the honest name for the thread nobody will ever answer: the feature request with no owner, the complaint that resolved itself, the message that was never really a question. Give them a state, review them weekly, and close the ones that are not coming back.
Handover: the part that actually breaks
Dropped threads in a small team almost always trace back to one of four handovers going wrong.
End of day. Anything in "being worked" is either finished, moved to a waiting state with a note, or reassigned. An open thread with no state at 18:00 is the classic overnight casualty.
End of shift, across time zones. Same rule, higher standard for the note, because there is no conversation to fill the gaps.
Holiday. The person going away hands over every thread they own before they leave. Not the inbox: the threads. This is the step that prevents the six-day silence in the example at the top.
Offboarding. When somebody leaves the company, their assigned threads need a new owner before their account is disabled, and their access to the address is removed on the last day. Both halves get forgotten roughly equally often.
The note itself needs three fields, and three is genuinely enough:
- What the customer is waiting for, in the customer's terms. "A refund date", not "pending finance".
- What has already been promised, including any date or amount. This field is what stops a customer being told two different things by two colleagues.
- What the next action is, and when. "Chase warehouse Thursday if no tracking number by then."
The receiving person should never have to read the whole thread to pick it up. If they do, the note failed. And when a thread does change hands, do not announce it to the customer. They wrote to a team address precisely so they would not have to care which human is holding it this week; a "your case has been transferred to a colleague" email tells them the opposite.
Speaking with one voice
The rule is simple: customers see the team, not the individual. What is worth knowing is how differently the two big platforms behave underneath that rule.
On Microsoft 365, the platform is on your side. Microsoft's guide to using a shared mailbox in Outlook states that "whenever you send a message from a shared mailbox, your recipients will only see the shared email address in the message". Replies then come back to the team address instead of to whoever answered.
On Gmail delegation, the platform is not. Google's documentation on delegating access to a Gmail account is explicit that when a delegate sends a message from your account, "their email address appears". A delegate can read, send and delete mail on the account's behalf, but the individual's identity travels with what they send. If your team runs on delegated access and you assumed a single voice, look at what your last five replies looked like from the outside, because your single-identity rule may not have been in force at any point.
Beyond the address, agree on two small things: whether replies are signed with a first name (usually yes, it reads better than an anonymous team signature) and whether the signature carries the individual's job title (usually no, because it invites customers to route around the address next time).
Where the internal conversation lives
The rule is that discussion attaches to the thread rather than to a chat channel. Here is the number that makes the case, and it surprises people.
Slack's own documentation on feature limits on the free version states that you are "limited to the most recent 90 days of message and file history", and that data older than a year is deleted outright. So the conversation where three of you agreed to make an exception for a customer, and why, is out of reach after three months. When that customer disputes a charge in month five, the reasoning does not exist anywhere.
Chat is faster than notes and people will use it regardless. Rather than pretending otherwise, write the compromise into the agreement: chat is fine for the working-out, and the decision goes back onto the thread as a note before the end of the day. One or two sentences, covering what got decided, by whom, and why.
What your platform enforces, and what runs on trust
This is where the agreement meets reality. Native setups enforce some of your rules and leave others to memory, and knowing which is which is more useful than any feature comparison.
Microsoft 365 shared mailbox. Sending identity is enforced, as covered above. The audit trail is not. Microsoft's shared mailbox configuration guide is blunt about the default, which still stands as of 2026: "by default, messages sent from the shared mailbox aren't saved to the Sent Items folder of the shared mailbox. Instead, they are saved to the Sent Items folder of the person who sent the message." Until an admin changes that, your team has no shared record of what was sent to customers, which means half your handover notes describe replies nobody else can read. The fix takes two minutes: in the Microsoft 365 admin center, go to Teams & groups > Shared mailboxes, select the mailbox, then select Edit under Sent items and turn the copies on. The same configuration guide also notes that automatic replies from a shared mailbox are text only ("you can't add images, only text"), which is worth knowing before you design an acknowledgement mail with a logo in it. There is a documented ceiling of 25 users on a shared mailbox as well, covered alongside the built-in limits and where they bind.
Google Collaborative Inbox. Assignment exists, and it is gated behind a permission that group membership does not grant. Google's documentation on taking action on Collaborative Inbox conversations specifies that assigning a conversation and marking it complete each "requires the Who can moderate metadata permission", with marking a conversation duplicate or no-action-needed sitting behind a separate content permission, and a group owner or manager has to enable the features first. The practical consequence for your agreement: the rule "every thread gets an owner" is unenforceable until somebody opens group settings, no matter how clearly you wrote it down.
A plain address plus filters. Nothing is enforced. Ownership, state and the response clock all live in people's heads and in whatever convention you agreed on. That is workable, and the honest threshold is lower than most vendors would like you to believe.
So: with three or four people, one channel, an agreement in writing and somebody who owns the configuration, the native setup is enough. Do not buy anything. The trigger to move is not a headcount, it is a rule you keep having to enforce by hand. When you find yourself asking every day who owns a thread, or reconstructing what was sent from three different Sent Items folders, the rule has outgrown the setup. That is the point where TriageFlow and other dedicated tools in the category earn their place: they attach the owner and the state to the conversation itself, so the rule holds without anyone remembering it.
The weekly review, and what to change when a number moves
Fifteen minutes, same slot every week, three questions. Which threads have been sitting longest, which ones came back after you closed them, and where did somebody have to be told the same thing a second time. For the numbers behind those questions, use the five numbers worth tracking.
What a metrics list does not tell you is which rule to change when a specific number moves, and that is the step where most reviews stall. A metric that does not point at a rule is decoration.
| Symptom | The rule that is failing | The smallest change that fixes it |
|---|---|---|
| Threads sat unclaimed for hours | The duty rota, or an invisible pickup signal | Name a duty person per day and make claiming visible to everyone |
| Two people replied to one customer | Assignment is happening after the reply is drafted | Move the claim to before drafting, no exceptions |
| A customer explained the same thing twice | The handover note, or its absence | Enforce the three fields on any thread entering a waiting state |
| Reopens rising after a push on speed | Your definition of closed is too loose | Define "closed" as the customer's problem being solved, not the reply being sent |
| One label has a long resolution tail | A missing written answer, which no amount of staffing fixes | Write the answer down once and link it, instead of rewriting it weekly |
| Threads aging in "waiting on internal" | Nobody owns chasing your own colleagues | The assignee sets a chase date at the moment they enter that state |
Run this for a month and the review stops being a status meeting. Each session should end with one line of the agreement rewritten, or with a deliberate decision that nothing needs changing this week.
The first 30 days
Rolling this onto a team that already has habits works in stages. Doing it all at once produces a document everyone nods at and nobody follows.
Week 1: the document and one rule. Fill in the eight decisions. Enforce exactly one of them, the one about claiming a thread before replying. Expect week 1 to feel slower, because it is: claiming is an extra step before anything else happens, and the payoff of nobody duplicating work is not visible until the habit is automatic.
Weeks 2 and 3: the rota and the note. Add the duty rotation and the three-field handover note. This is usually when the first genuine argument shows up, normally about the response target, and settling it is worth the meeting.
Week 4: the first review and the first change. Run the fifteen minutes, pick the symptom that appeared most, and change the rule it points at. Then put the review in the calendar as a recurring slot.
When something has to give, drop the labeling scheme first. Teams invent more labels than they will ever apply, and a label nobody applies is worse than no label at all, because your reporting then reports on a fraction of the work while looking complete.
When the agreement outgrows the setup
Every rule that survives only because people remember it is a rule waiting for a bad week. Moving is rarely as clean as a demo suggests, though: the address has to be cut over carefully, everyone relearns where their work lives, and every line of your written agreement has to be re-expressed as a setting, which is the step that exposes the rules you never really agreed on.
The decision then splits in two, and they are genuinely different questions. One is whether you need software that holds ownership and status for you, which comes down to the criteria and pricing mechanics that decide the purchase. The other is whether these conversations should become ticket records with IDs and states of their own, a heavier model with customer-facing costs attached that a five-person team often does not want.
Either way, spend one month first with every rule enforced by hand and a tally of how often you enforce each one. The rules you enforced daily are your requirements, in priority order, and they will tell you more than any feature list.
If the case has to be made to somebody who controls the budget, running your volume and handling time through a shared inbox ROI calculator converts those hours into a number a finance conversation can use.
Frequently asked questions
How do you manage a team email inbox?
Write down who owns the address and what counts as picking a thread up, put one named person on duty each day, require a short handover note on any thread that goes into a waiting state, and review what is still open once a week. Those four cover most of the failure modes; everything else is refinement.
What is the difference between a shared mailbox and team email management?
A shared mailbox is access: a setting that lets several people open the same address. Team email management is what you agree to do with that access, and none of it is configurable. If you want the access side first, what a shared inbox is and how to set one up covers the options.
How many people can access a shared mailbox?
Microsoft supports up to 25 users on one shared mailbox, and the built-in limits and where they bind are worth reading before you plan around that number. The practical ceiling is lower anyway, because an agreement held in people's memory starts slipping well before any documented cap does.
Can a small team run a shared address without paying for anything?
Yes, under four conditions: roughly three or four people, one channel, the agreement genuinely written down rather than assumed, and one named person who owns the configuration. The last condition is the one that gets skipped, and without it permissions and filters accumulate with nobody accountable for them.
How do I manage team email in Outlook or group email in Gmail?
Both platforms will give several people access to one address, and neither enforces most of your process. On the Microsoft side, the big default to change is shared Sent Items, otherwise nobody can see what was sent. On the Google side it is the Collaborative Inbox permissions, without which the assignment buttons do nothing useful. Fix those two and the native setups carry a small team a long way.
What happens to threads assigned to someone who has left?
They need reassigning before the account is disabled, which is the step that gets missed. Reassign each open thread by name, remove the person's access to the address on their last day, and check for anything sitting in "waiting on internal" that was waiting on them personally. That last category is the one that goes quiet without anybody noticing.