What is a shared inbox? (and when you need one)

Two people answered the same customer this morning. One said the refund would take three days, the other said five. Neither knew the other had replied, because both were looking at support@ in their own Gmail, and neither reply was visible to anyone else.

That’s the problem a shared inbox exists to solve.

A shared inbox is a single email address, like support@yourcompany.com, that a whole team can read and reply from in one place, where everyone sees the same messages and who is handling what. Mail arrives once. Everyone can see it. Replies go out from the address itself.

That’s the definition. The useful part is what comes next: how it differs from the workarounds you’re probably using, and how to tell whether you’ve outgrown them yet.

What a shared inbox is not

Three things get called shared inboxes and aren’t. The differences are where the pain comes from.

A distribution list or email alias. support@ set up as a group that forwards to three personal mailboxes. Everyone gets a copy, so everyone assumes someone else has it, or two people answer at once. Replies come from personal addresses, so the customer’s next message goes to one inbox instead of the group. There’s no shared record of what was said.

A forwarded mailbox. One person receives everything and forwards what they can’t handle. Now the history lives in a forwarding chain, the customer’s reply lands with the wrong person, and one human is the routing table.

Shared credentials. One support@ login, password in a password manager, two people signed in at once. Nobody knows who’s typing. Read and unread states fight each other. Then someone leaves. You change the password, and the whole history goes with it.

A real shared inbox keeps one copy of each conversation, visible to the team, with assignment and status built in. The mailbox behaves like a workspace.

What you get

The mechanics vary by tool, but the useful parts are consistent:

One threaded view per customer. Every message and reply in a conversation sits together, in order, with the whole history attached.
Assignment. A conversation belongs to one person, so “is anyone on this?” has an answer you can see.
Status. Open, waiting, closed. Open is a queue you can work through, and closed means someone finished it.
Replies from the shared address. The customer emails support@ and hears back from support@, whoever wrote it. Your reply also stays in the thread they started, instead of opening a new one.
A history that outlives people. When a teammate leaves, the conversations stay. So does the answer they gave a customer eight months ago.
Basic reporting. How much is coming in, how fast you respond, what people ask about. (Which of those numbers are worth watching is its own question.)

The threading detail that makes it work

Here’s something we learned building this. Keeping a conversation together is harder than it looks, and it’s the difference between a tidy inbox and a mess.

When a customer replies, matching that reply to the right conversation takes a cascade, because any single method fails often enough to matter. Supora tries four in order: the In-Reply-To and References headers first, which is the clean case; then a short bracketed token in the subject line; then the tokened marker we append to the bottom of every reply, which doubles as the point where quoted text gets stripped; and finally the normalised subject plus the sender’s address, but only within a 14-day window, so an unrelated “Question” from the same person six months later doesn’t get stapled onto an old thread.

You’ll never see any of that if it works. You’ll notice immediately when it doesn’t, because your customer’s answer appears as a brand-new ticket with no context, and someone asks them to explain their problem again. This is the plumbing a shared inbox tool buys you, and it’s why “we’ll just use a Google group” quietly stops scaling.

Signs you need one

You’ve outgrown personal mailboxes and forwarding when any two of these are true:

Sign	What it looks like
Duplicate replies	Two people answered the same customer, differently.
Dropped messages	”Following up on my email from last week…” and nobody has it.
Constant status pinging	Slack fills with “did anyone answer Priya?”
Knowledge in one head	One person knows what you told that customer, and they’re on holiday.
More than one answerer	Two or more people reply to customers, at all.
A departure risk	Someone leaving would take conversation history with them.

The tipping point is people, not volume. One person handling 300 emails a month is fine in a normal mailbox. Two people handling 40 is already a coordination problem, because coordination is what breaks first.

When you don’t need one

If you’re a solo founder answering everything yourself, from your own inbox, with no one else to hand off to, a shared inbox buys you less. You still get threading and a history that isn’t tangled up with your personal mail. But nobody is duplicating your replies, so the loudest problem isn’t yours yet.

Two things change that. A second person starting to answer customers, or you reaching the point where you can’t tell what’s still open. If neither has happened, labels and a filter will hold. Wait until the pain is real.

Shared inbox, help desk, or ticketing system?

These names overlap and vendors use them loosely. The practical distinction:

Shared inbox. Email-shaped. Conversations look like email, customers get normal replies, and the interface is familiar on day one. Best when support means “people write to us.”
Help desk. A shared inbox plus the support-department apparatus: knowledge base, SLA policies, routing rules, automation, deeper reporting. Useful once support is a function rather than something everyone does between other work, which is roughly where support stops being service.
Ticketing system. Ticket-shaped. Reference numbers, forms, statuses, queues. Powerful, and impersonal enough that customers notice.

Most startups need the first and buy the second. The apparatus is only worth it when someone has time to configure and maintain it, which is rarely true at three people. If you’re weighing the actual products, our guide to the best Help Scout alternatives for startups compares the small-team options.

Setting one up without regretting it

Whatever you choose, a few decisions pay off later:

Pick the address before the tool. support@ or help@, on your own domain, and don’t change it. It ends up printed in docs, invoices, and old email. Migrating it later is worse than choosing it carefully now.
Don’t route it through a personal mailbox. Mail should reach the shared inbox directly, so no single person is a dependency.
Agree who takes the queue. Even informally. “Whoever’s around” works until it doesn’t; a rota or an assignment habit stops the queue becoming everyone’s slight responsibility.
Write down your five most common answers. A small library of canned responses beats a knowledge base you’ll never finish, and it makes replies consistent across people.
Keep the tone human. A shared address shouldn’t sound like a machine. Our guide to writing a support email covers the mechanics.

Worth knowing up front: Supora runs one operator per workspace today, with multi-seat still on the roadmap. If two of you are already answering, that’s a real limit to weigh.

The bottom line

A shared inbox is one address and one view of it, for everyone who answers. It’s worth setting up the moment more than one person replies to customers, because that’s when duplicate replies and dropped messages start, and both cost you more trust than the tool costs money.

If you’re still the only person answering, you have time. Choose the address now, and move when the second person joins.