Two people answered the same customer four minutes apart. One promised a refund, the other promised a replacement. Neither knew, because each was reading their own forwarded copy of the same message and nothing in either copy said "someone is on this".
That's the moment most teams go looking for the phrase "shared inbox". If your team is small and the address is calm, you'll find permission here to stay exactly where you are.
The short version
- A shared inbox is a single email address (
support@,info@,billing@) that several people read and reply from, where each conversation carries an owner and a state. - "Shared mailbox" is Microsoft's name for its own feature. "Shared inbox" is the category. The two get used interchangeably, which causes most of the confusion in this space.
- Google Workspace and Microsoft 365 both include something workable at no extra cost. Both have documented ceilings, and one of them is a hard cap of 25 users.
- Most shared inboxes fail for organizational reasons rather than technical ones. If nobody owns a thread, everybody assumes somebody else does.
What is a shared inbox (and what it is not)?
A shared inbox is one email address that several people work from together, where every message lives in one place and carries two pieces of information a normal inbox doesn't have: who owns it, and what state it's in.
That second half is the part people skip. Five people with access to the same mailbox is just a crowd. What makes it a shared inbox is that a thread can be assigned to Maria, marked as waiting on the customer, annotated with an internal note the customer never sees, and closed when it's done. Without assignment and status you have shared access to a pile of mail, which is exactly the setup that produced the duplicate refund.
Three terms get mixed up constantly, so let's separate them once:
- Shared inbox is the category: any setup where a team works one address collaboratively.
- Shared mailbox is a specific Microsoft 365 feature. Microsoft describes it as what you use "when multiple people need access to the same mailbox", for example a company information or support address.
- Shared email account means everyone logs in with the same password. That's not a shared inbox. It's a security problem with an inbox attached, and we'll come back to why.
The four ways teams share email, ranked by how they fail
Almost every team arrives at one of four setups. They're not equally bad, but each breaks in a specific and predictable way.
One login, one password, everyone. Somebody creates support@ as a normal account and the password goes in a group chat. It works on day one and nowhere after that. There's no record of who sent what, you can't revoke access for one person without changing the password for everyone, and two people opening the same account at once is how you get the duplicate reply. Microsoft is blunt about this for its own product: a shared mailbox "isn't intended for direct sign-in" and you should block sign-in on the account and keep it blocked.
Forwarding and CC. The address forwards to three personal inboxes, and people CC each other when they pick something up. This setup has the highest tolerance for small volume and the worst behavior under load. Every reply thread splits into private copies, the CC discipline collapses the first busy Friday, and nobody can answer "what happened with that customer in March" without asking three people to search their own mail.
A distribution list. One message fans out to every member's inbox. Distribution groups exist "for sending notifications to a group of people", which is what they're good at and why they're wrong for support: they broadcast, they don't collect. Replies go back to the individual, so the conversation leaves the shared space at the first response. A list is still the right call for announcements, and it's worth reading when a distribution list is still the right call before you rip one out.
A shared inbox, built in or dedicated. One mailbox, per-person permissions, assignment, status. It fails too, just later, and for reasons that live in the team rather than the tool: no ownership rotation, no tagging convention, no rule for what happens when a thread goes quiet.
| Setup | What it's good for | Where it breaks first |
|---|---|---|
| One shared login | Nothing, past week one | No audit trail, no per-person revocation, collisions |
| Forwarding and CC | Two or three people, low volume | Threads split into private copies, history is unsearchable |
| Distribution list | Announcements, one-way notices | Replies leave the shared space immediately |
| Shared inbox (built in) | Small teams that need one address | Documented user and storage ceilings, thin workflow |
| Shared inbox (dedicated) | Teams past the ceilings | Costs money, needs operating rules to be worth it |
How a shared inbox actually works day to day
Strip away the marketing and there are six mechanics, and if you're evaluating anything, these are what you're evaluating.
It starts with assignment. A thread gets an owner, either picked up manually or routed by a rule, and that owner is who the rest of the team asks about it. One owner, never two. Attached to the thread is a status: open, waiting on the customer, waiting on someone internal, closed. Status is what stops a thread from silently aging, because a mailbox where everything is either read or unread can't express "I answered, the ball is with them".
Collision detection is the piece that prevents the failure in the opening paragraph: something visible that tells you a colleague already has this thread open or is typing into it right now. It's also the mechanic the built-in routes give you least of, which is why it gets its own paragraph later.
The remaining three are quieter and you'll miss them when they're gone. Internal notes are comments on the thread that the customer never receives; without them, context moves into chat and gets lost, or somebody hits reply-all with an internal remark attached. Canned replies are saved answers for the questions you get twenty times a week, with the fields that change left blank on purpose so nobody sends a template with the wrong name in it. And the audit trail records who replied, when, from which address, and what changed, which is what makes a Monday morning handover possible and what your compliance people will eventually ask for.
Do you need one yet? A threshold, not a pitch
Plenty of teams don't need a dedicated tool yet, and buying one early just adds a login to the pile.
Stay where you are if all of these are true:
- Three people or fewer touch the address.
- Under roughly 20 to 30 messages a day, and it isn't growing month over month.
- Nobody has yet asked "did you already reply to this?"
- Coverage isn't a problem: when one person is out, the mail still gets answered.
Move to a built-in shared mailbox or Collaborative Inbox when the address outgrows one person but the volume is still modest. That's the free tier of this problem, and it solves most of it.
Move to a dedicated tool when at least two of these are true:
- More than five people work the same address, or you're heading toward the built-in ceilings described below.
- Duplicate or contradictory replies have happened more than once.
- You need to answer "how long are we taking to respond" with a number.
- Threads regularly need to move between people, which means routing rules rather than a duty roster in someone's head.
- Something has to be escalated on a clock, and the clock currently lives in someone's memory.
Volume growth is the signal that matters most, because it's the one that doesn't reverse. If your daily count has doubled in six months, the setup that's straining today will be broken in another six. That's also the point where scaling support past the first hire turns into a staffing conversation, and a support team size calculator will tell you whether the problem is your tooling or simply too few people.
Mapped onto the four setups, the routes come out roughly like this:
| People on the address | Daily volume | Route that fits | What pushes you off it |
|---|---|---|---|
| 1 to 2 | Under 20 | Delegation or plain forwarding | A second person starts replying |
| 2 to 5 | 20 to 50 | Built-in shared mailbox or Collaborative Inbox | Duplicate replies, no response times |
| 5 to 25 | 50 to 200 | Dedicated shared inbox tool | Routing and SLAs stop fitting in one rota |
| Over 25 | 200 plus | Dedicated tool, no longer optional | The Microsoft 25-user cap, per-queue reporting |
Setting one up with what you already have
Both major platforms include something usable. Neither is a full workflow tool, and both are the right first move.
Microsoft 365: a shared mailbox
An admin creates the shared mailbox in the Microsoft 365 admin center and adds members. There's no separate license for the mailbox itself, though everyone accessing it needs their own licensed Exchange Online mailbox. Members can send as the address or on behalf of it, and the mailbox comes with a shared calendar.
To open it in new Outlook, Microsoft's instructions are to select Mail in the navigation pane, then "right-click your account name, and select Add shared folder or mailbox" and type the address. In classic Outlook it's File > Account Settings > Account Settings > Email, highlight the account, then Change > More Settings > Advanced > Add.
Two things to know before you promise it to the team. Automatic replies on a shared mailbox aren't self-service: Microsoft states that only a Microsoft 365 admin has permission to set them up. On the upside, access isn't desk-bound, because Microsoft supports shared mailboxes in the Outlook apps for iOS and Android as well as Outlook on the web, so on-call coverage works from a phone.
Google Workspace: delegation or a Collaborative Inbox
Two different routes, and picking the wrong one wastes a week.
Delegation grants named people access to a mailbox from their own Gmail. It's quick and it's fine for two or three people covering an address. Delegates read and reply, but Google's delegation documentation is clear that a delegate can't chat as you or change your password, and that delegated access drops a set of features including Smart Compose, Smart Reply and Drive attachments.
A Collaborative Inbox is a Google Group with workflow features switched on. Members can assign a conversation to themselves or someone else, mark it complete, mark it as needing no action, or mark it duplicate, and filter down to what's unresolved. The catch is permissions. Google's Collaborative Inbox documentation puts assigning and marking complete behind the "Who can moderate metadata" permission, and marking duplicate or no-action-needed behind "Who can moderate content". A group owner has to enable the features and set those permissions before any of it works, which is why so many teams try a Collaborative Inbox, find that nobody can assign anything, and quietly give up on it.
If Gmail is your platform, the full Gmail shared inbox setup walks the configuration in more detail than belongs here.
Where the built-in routes break
Here are the ceilings, with the documentation that states them.
A Microsoft shared mailbox supports a maximum of 25 users. Microsoft's shared mailbox documentation sets that number and adds a separate warning about concurrency: if too many users access the mailbox at the same time, they "might experience connection failures or duplicated messages". If you're a growing support team, that's a wall with a date on it.
Storage stops at 50 GB without a license. Microsoft's warning describes the failure sequence precisely: at the limit you can still receive mail for a while but can't send, and after some time the mailbox stops receiving and senders get a non-delivery receipt. Raising it to 100 GB requires an Exchange Online Plan 2 license, which quietly turns the free option into a paid one.
Mail from a shared mailbox can't be encrypted. Microsoft's reason is structural: the mailbox has no security context of its own, so no encryption key can be assigned to it. If members encrypt with their personal keys, other members may not be able to read those messages. For teams handling anything regulated, that's a design constraint you have to work around.
Access is internal only, and deletion can't be prevented. People outside your organization can't be given access to a shared mailbox, and Microsoft states you can't stop members deleting messages in one.
Gmail delegation caps out too. Personal @gmail.com accounts allow up to 10 delegates; work or school accounts allow up to 1,000, but Google notes that with typical use about 40 delegates can work in an account at the same time, and heavy use by some of them reduces that number.
Neither platform gives you collision detection worth the name. A Collaborative Inbox shows an assignee once someone has assigned the thread. Nothing tells you that a colleague is composing a reply at this second, which is the moment the duplicate gets created.
Microsoft's own answer to most of these limits is the same: use a Microsoft 365 group instead. That's a different collaboration model rather than a setting you flip, and it's a one-way door, because Microsoft's group comparison states it isn't possible to migrate a shared mailbox to Microsoft 365 Groups. Worth knowing before you pick a lane.
None of this makes the built-in routes bad. It makes them a stage, and most teams should pass through it.
Moving the address without dropping mail
Cutover is where good migrations go wrong, and it's the part nobody writes about because it happens once. Four rules keep the gap at zero.
Run the old and new setups in parallel for two weeks. Point the address at the new inbox and keep the old mailbox receiving a copy, so anything that slips through routing still lands somewhere a human looks. Two weeks covers a full billing cycle for most small teams, which is where the odd recurring thread hides.
Take the history with you, or decide out loud that you won't. Importing years of mail is usually worth it for the search alone, but if the new tool can't import cleanly, keep the old mailbox read-only rather than shipping a half-migrated archive. A partial history is worse than a clearly bounded one, because nobody knows which side to search.
Leave the old distribution list running until the traffic to it stops. Watch it for a couple of weeks, then set an auto-reply on it pointing at the shared address, then turn it off. Deleting a list on day one is how you find out which supplier still has the 2019 address in their system.
Tell people who send to the address what changed, in one line, before it changes. Internal senders adapt instantly. External ones never read it, which is exactly why the forwarding overlap exists.
What to look for when you move to a dedicated shared inbox
Once the ceilings start binding, the question stops being "which tool" and becomes "which criteria". Seven things separate the options that matter from the ones that market well, roughly in the order they'll matter to you.
Assignment model. Manual pickup only, or rule-based routing by sender, keyword and time of day? Manual works at low volume and becomes the bottleneck exactly when you're busiest.
Status and SLA handling. Can a thread carry a due time, and does something visible happen when that time passes? A status field nobody gets alerted about is just a label.
Automation and triage. This is where the built-in options genuinely have nothing to offer: sorting incoming mail by topic and urgency before a human reads it. A shared inbox tool like TriageFlow does this with AI classification, so the refund request and the outage report don't sit in the same undifferentiated queue waiting for whoever opens the mailbox first.
Reporting. First response time and resolution time per person and per tag, exportable. If you can't get the numbers out, you won't run the weekly review described below, and the tool will decay into a nicer mailbox.
Migration. Can it import the existing mailbox with history intact, and can you run it in parallel with your current setup for two weeks? A cutover with no overlap window is how mail gets dropped.
Pricing shape. Per seat is the norm. What matters is what happens to occasional users: the person in finance who touches billing@ twice a month shouldn't cost a full seat, and whether they do is worth asking before the trial.
Data residency and retention. Where the mail is stored and how long it's kept. Easy to ignore now and expensive to fix later.
Notice what's missing from that list: a feature count. Every product in this category has a long feature page. The seven above are the ones that change how your Tuesday goes.
Running it well: the rules that decide whether it works
A shared inbox doesn't fail because the software is bad. It fails because "everyone owns it" resolves to nobody owning it. Five rules cover most of the failure modes.
One owner per thread, always. Assignment happens at pickup, before the reply is written. If a thread sits unowned for more than an hour during working time, that's the defect to chase.
A daily owner for whatever is unassigned. Someone is on inbox duty each day, and their job is triage rather than answering everything: they assign, they escalate, they clear the noise. How to run an email triage pass covers what that person actually does with each message. Rotate the duty, because whoever does it permanently burns out and stops telling you.
A tagging convention short enough to survive a bad week. Five to eight tags, chosen so a tired person picks the right one without thinking. Twenty tags is a taxonomy nobody applies, and an unapplied tag is worse than no tag because your reporting quietly lies to you. The habits in inbox management strategies that survive a busy week transfer directly here.
An escalation rule with a number in it. "If it's still open after X hours, it goes to Y." Write down X and Y. An escalation path that lives in someone's judgment isn't one.
A rule for the side channel. Someone will always ask a support question in chat or directly to a colleague. Decide what happens: either it gets forwarded into the inbox or it doesn't count. Half-enforced is the worst option, because your metrics then describe a fraction of the work.
Then hold a fifteen-minute weekly review of what's still open, what got reopened, and what the same customer had to ask twice. That review is where the process actually improves.
How to tell it is working
Five numbers are enough. Measure your own baseline for two weeks before you set any targets, because a target imported from a blog post tells you nothing about your team.
- First response time. Use the median. One nightmare thread will bend the mean and hide a good week.
- Resolution time. Time from first contact to closed, split by tag. A single tag with a long tail is usually telling you the documentation is missing, not that you're short-staffed.
- Reopen rate. How often a closed thread comes back. Rising reopens after a speed push mean you got faster at answering the wrong thing.
- Duplicate replies. Count them by hand if you have to. This is the number that justified the whole exercise.
- Coverage gaps by hour. When does mail arrive, and when does anyone answer? Most teams find one recurring window where nothing moves.
If you're building the case internally, running your volume and handling time through a shared inbox ROI calculator turns those hours into a number your finance lead will actually read.
Frequently asked questions
What is the difference between a shared inbox and a shared mailbox?
"Shared mailbox" is the name of a specific Microsoft 365 feature. "Shared inbox" is the general category, which covers that feature, Google's Collaborative Inbox, and every dedicated tool built for the job. If someone says shared mailbox and they aren't talking about Microsoft, they almost certainly mean the category.
How many people can use a shared mailbox?
Microsoft documents a maximum of 25 users per shared mailbox, with a separate warning that too many people accessing it simultaneously can cause connection failures or duplicated messages. Google's limits are shaped differently: up to 10 delegates on a personal Gmail account, up to 1,000 on a work or school account, with roughly 40 able to work in it at the same time under typical use.
What do customers see when we reply from a shared inbox?
They see the shared address, not your personal one, provided the admin has granted send-as or send-on-behalf permission. Microsoft's documentation gives the example of replies going out as "Contoso Support", which is usually what you want: the customer replies to the team, not to whoever happened to answer, so the next message lands back in the shared inbox instead of one person's mail.
What happens to the mailbox when the person who created it leaves?
Nothing, and that's the point. A Microsoft shared mailbox has its own underlying account with a system-generated password that nobody uses, so it isn't tied to any employee. You remove that person's permission and the address keeps working. Compare that with a shared login, where one departure means a password change for everyone and no way to tell which of the old messages were theirs.
Is a shared inbox secure?
More secure than a shared password, because access is granted and revoked per person. The trade-off worth knowing on the Microsoft side is encryption: mail sent from a shared mailbox can't be encrypted, since the mailbox has no security context of its own to hold a key.
What is the difference between a shared inbox and a distribution list?
A distribution list copies each incoming message into every member's personal inbox and then forgets about it. A shared inbox keeps one copy of the conversation in one place, with an owner and a state attached. The practical test: if someone has to reply and you care who, you want a shared inbox. If you are broadcasting and no reply is expected, the list is cheaper and simpler, and the full comparison covers the edge cases.