KoltrixWhen does a team actually need a shared inbox?
The signals that forwarding hello@ to one person has stopped working, plus a decision table for choosing between staying put, an alias, or a shared inbox.
On this page(8 sections)
Most early teams start with the same arrangement: hello@ forwards to the founder's personal inbox, and it works fine until the day a customer writes back asking why nobody answered their email from last Tuesday. The question isn't whether you will need a shared inbox eventually. It's how to tell when the cheap setup has started costing you more than it saves.
This post gives you the warning signs, a decision table you can apply in five minutes, and a short list of what to set up when you do switch.
What you are really choosing between
There are three common setups for a team address like hello@ or support@:
- Stay as-is. The address delivers to one person's mailbox, either directly or via forwarding. One human reads and replies to everything.
- Alias or forward to several people. The address fans out to two or more personal inboxes. Everyone gets a copy and replies from wherever they happen to be.
- Shared inbox. The address is its own mailbox. Several people log in to the same place, see the same threads, and reply as the team address.
Each of these is the right answer for some team. The mistake is staying on the first or second option long after the team has outgrown it.
Seven signs forwarding has stopped working
You don't need all of these. Two or three is usually enough to justify a change.
- Replies go out from personal addresses. A customer writes to support@ and gets an answer from jamie@. Now the next message goes to Jamie directly, and the rest of the team never sees it.
- Nobody knows if something was answered. You find yourself asking in chat, "Did anyone reply to the person asking about invoices?"
- Two people reply to the same email. Fan-out forwarding gives everyone a copy and no way to see that someone else is already on it.
- History lives in one person's head. When a customer says "as I mentioned last month," only one inbox has the context.
- One person is the bottleneck. The founder is the only one who sees hello@, so every response waits for their calendar to clear.
- Vacations are scary. Someone going offline for a week means either an out-of-office that apologizes or a scramble to share a password.
- Offboarding loses mail. When someone leaves, their copy of customer conversations leaves with them.
The decision table
Use the row that best matches your current situation. If you straddle two rows, pick the one further down; teams rarely regret switching a little early.
| Situation | Volume to the address | People who need to reply | Need shared history? | Recommended setup |
|---|---|---|---|---|
| Solo founder, one product | A handful a day | 1 | Not yet | Stay as-is |
| Two founders splitting work by topic | A handful a day | 2 | Occasionally | Alias is fine, with a clear rule for who replies |
| Small team, one support person plus backup | Steady daily flow | 2–3 | Yes | Shared inbox |
| Any team where customers get replies from different people | Any | 2+ | Yes | Shared inbox |
| Several role addresses (support@, billing@, sales@) | Mixed | 3+ | Yes, per address | One shared mailbox per address, with access per mailbox |
| Regulated or sensitive mail (billing, legal requests) | Low | 1–2 | Yes, restricted | Separate shared mailbox with narrow access |
Two notes on reading the table:
- Volume matters less than you think. A team getting ten emails a day can still need a shared inbox if three people answer them. The number of people replying is the stronger signal.
- "Need shared history?" is the deciding column. If anyone other than the original replier will ever need to read the conversation, forwarding will eventually fail you.
Why the alias stage is shorter than it looks
Forwarding to several people feels like a free upgrade. Everyone sees everything, and nobody has to learn a new tool. In practice it creates the exact problems a team address is supposed to prevent:
- Each person has a separate copy, so read and replied states don't sync.
- Replies come from personal addresses unless everyone remembers to change the From line.
- Internal discussion happens in forwarded copies and chat, splitting the thread.
- Your mail provider has to forward on your behalf, which can occasionally affect how messages authenticate on the way through.
An alias is a reasonable bridge for two people who split work cleanly ("I take billing, you take product questions"). Once there's overlap, it starts generating duplicate replies and dropped threads.
What changes when you move to a shared inbox
A shared inbox replaces copies with a single source of truth. Practically, that gives you:
- One thread, one state. If someone replied, everyone can see it.
- Replies from the team address. Customers keep writing to support@, not to whoever happened to answer first.
- History that survives people. New hires can read old conversations, and departures don't take context with them.
- Access you can control. Not everyone needs to see billing@ or the address where legal and security reports land.
With Koltrix, for example, each team address can be its own shared mailbox on your custom domain, and you choose per mailbox who has access. That last part matters more as you grow; the support team doesn't automatically need the finance mailbox.
A minimum setup checklist
If the table pointed you toward a shared inbox, resist the urge to build a perfect system on day one. Start here:
- Create the shared mailbox for the busiest team address first, usually support@ or hello@.
- Give access only to the people who will actually reply.
- Write a one-paragraph rule for who replies to what (by topic, by rota, or first come first served with a visible claim).
- Add three to five labels at most, for example Waiting on customer, Bug, Billing.
- Turn off the old forwarding once the mailbox is receiving mail, so you don't run both systems at once.
- Send a test from an outside address and reply to it from the new mailbox.
- Put a 15-minute weekly review on the calendar to catch anything stuck.
Add more structure only when a specific problem shows up. It's easy to over-engineer labels and rules in week one and spend month three deleting them.
When staying as-is is the right call
Not every team needs to switch. If one person really does handle every message, the volume is light, and nobody else will ever need the history, a single inbox is simpler and perfectly fine. Revisit the question when you hire your first support or success person, add a second product, or catch yourself asking "did anyone answer this?" for the second time in a month.
Bottom line
- The number of people replying is a better trigger than email volume.
- Forwarding to several people is a short bridge, not a destination; it produces duplicate replies and split history.
- If anyone besides the original replier will ever need a conversation's context, you need a shared inbox.
- Start with one shared mailbox, a simple ownership rule and a handful of labels, then grow from real problems.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
