An address goes on the website. Something like info@, apply@, or support@. For a few weeks it is fine, because volume is low and one person quietly handles everything. Then the volume doubles, a second person starts helping, and the failures begin: two replies to the same sender an hour apart, a message nobody touched for four days, and a request that was answered but cannot be found because it was answered from somebody's personal outbox.
None of that is a volume problem. It is an ownership problem. A Gmail group mailbox can be set up in several different ways, and the ways differ almost entirely in whether a message can belong to a named person. Picking the right one is a matter of deciding how much of that you need recorded, and where the record should live.
Three different things get called a group mailbox
The phrase covers at least three arrangements in Google Workspace, and they behave nothing alike.
A distribution group is the default. Mail sent to the group address fans out to each member's own mailbox. Every member gets their own copy, reads it in their own inbox, and marks it read privately. There is no shared state at all, which is why two people answering the same message is not an edge case here. It is the expected outcome.
Delegated access is the second arrangement. One mailbox exists, and other people are granted access to it from their own accounts without a shared password. Everyone is looking at the same messages, so read state is shared, and the double reply becomes less likely. What is still missing is a name attached to each message. The mailbox knows a thread was opened. It does not know who agreed to finish it.
A collaborative inbox is the third. It is a Google group with an extra layer switched on, and that layer is the only one of the three built specifically around ownership. Conversations can be claimed, handed to a named member, and closed with a stated outcome.
| Arrangement | Where the message sits | Who it belongs to | What gets recorded |
|---|---|---|---|
| Distribution group | A copy in each member's mailbox | Nobody | Nothing shared |
| Delegated access | One mailbox, several people in it | Nobody, though read state is shared | Read and replied state |
| Collaborative inbox | One group conversation list | One assignee at a time | Assignee and resolution state |
| Third party shared inbox | The product's own store, synced to Gmail | One assignee, usually with rules | Assignment, status, internal notes, often reporting |
Read the table as a ladder of how much the system will hold for the team, rather than a ranking. Each step up adds record keeping, and each step up also adds either configuration or cost.
What the collaborative layer actually changes
Once a group owner or manager enables collaborative inbox features, members get two kinds of action on a conversation.
The first is ownership. Take claims a conversation. Assign hands it to a specific member by email address, with a note if there is context to pass on. Drop releases it so somebody else can pick it up. The second is resolution: a conversation can be marked complete, marked as needing no action, or marked as a duplicate of another conversation in the same group.
The practical value shows up in the filters rather than the buttons. The conversation list can be narrowed to what is assigned to the person looking, to what is assigned to anyone, or to what is not assigned at all, and separately to conversations that are still unresolved. The queue a team actually has to clear is the intersection of those two: unassigned and unresolved. Before the feature is on, that queue exists only in people's heads.
One detail sinks more rollouts than any other. Every action above is gated by a group permission. Claiming, assigning, dropping, and marking complete depend on the metadata moderation permission, and marking a conversation as needing no action or as a duplicate depends on the content moderation permission. A member without the right permission sees the inbox, reads it, and finds no way to act on anything, which looks exactly like a feature that does not work. Check permissions before concluding the setup failed.
The failure modes an address has to survive
Four things go wrong in shared addresses, and each has a specific mechanism. Naming the mechanism is what tells you which setup is enough.
The double reply happens because read state is private. On a distribution group, two people can both be composing at once with no signal that the other exists. Shared read state fixes most of it. Assignment fixes the rest, because claiming a conversation is a visible act rather than an assumption.
The silent drop is the expensive one, and it gets worse as the team grows. When four people can answer, each one's estimate of the chance that somebody else already did it goes up. Nothing is refused. It simply waits. The only reliable cure is a queue that shows what is unassigned, because then the absence of an owner is a visible fact instead of a private guess.
Ownership by habit is the quiet failure. The fastest reader becomes the de facto queue for everything, including work that should have gone elsewhere. Nobody decided this and nobody can see it, because volume per person is not recorded anywhere. It usually surfaces when that person takes a week off and the address falls over.
The handover gap appears at exactly the wrong moment. Somebody leaves, or goes on holiday mid thread, and the context lives in a chat message or in their head. Assignment notes help. A record that carries the history of a request, rather than a thread that carries only the messages, helps considerably more.
What no mailbox arrangement can fix
Every option above organises messages after they arrive. None of them has any influence over what arrives, and that turns out to be where most of the lost time actually goes.
An email address accepts free text. The information needed to act on a request is present only when the sender happened to think of it. Every missing order number, date, file, or choice from a list becomes a round trip, and a round trip is rarely an hour. It is a day or two, because the sender has moved on. A collaborative inbox will faithfully track that a conversation is open and assigned for three days. It cannot tell you that two of those days were spent waiting for a field the requester could have filled in at the start.
There is a middle path that looks like a fix and is not. A form that emails its submissions to the group does improve intake, because the questions get asked up front. It also flattens every structured answer into an email body, so the answers exist as text but not as fields. Nothing can filter on them, sort on them, or count them. Teams in that position usually start a spreadsheet next to the inbox to recover the structure, and now the same request lives in three places, with the spreadsheet drifting out of date first.
The question that gets asked three months later
There is a second cost to organising requests as conversations, and it only becomes visible when somebody senior asks how many requests came in last quarter, how long they took to close, and which handler carried the most. Assignment and resolution describe where a conversation stands right now. They are not a history of states with timestamps attached, so the arrival time, the moment it was claimed, and the wait in between are scattered across message headers rather than held as data. Counting them means opening conversations one at a time, which is why the answer to that question is usually an estimate.
The alternative is to keep the response as a record. A form tool that holds each submission with its own owner and status treats the structured answer and the handling state as the same object, so the queue and the data are not two systems that have to be kept in step by hand.
What the paid options cost, as published today
For teams that have decided a shared inbox product is the right shape, the entry prices are public. All figures below are the published rates at the time of writing.
| Product | Entry plan | Second tier | Cap on the entry plan |
|---|---|---|---|
| Missive | 14 dollars per user per month | 24 dollars per user per month | Up to 5 users |
| Front | 25 dollars per seat per month, billed annually | 65 dollars per seat per month | Up to 10 seats, single channel type |
| Help Scout | Free plan, then 25 dollars per user per month | 45 dollars per user per month | Free plan covers 5 users, 1 inbox, 1 documentation site |
| Hiver | 25 dollars per user per month billed annually, 35 dollars monthly | 55 dollars per user per month | All plans start at 2 seats |
Two things in that table matter more than the headline numbers. The first is the cap: entry plans stop at five or ten people, so a team of twelve is not really choosing between entry plans and should compare second tiers instead. The second is that some capability sits outside the seat price. Help Scout charges 75 cents per resolution for its AI answers feature and 10 to 12 dollars a month for an additional inbox. Front lists Copilot at 20 dollars per seat per month as an add-on, included only in its top tier.
All of these price per person, which is worth noticing because it means the bill tracks headcount rather than workload. A tool priced the same way but with no cap on responses behaves very differently in a month when volume triples. Comparing the pricing model rather than the list price is usually the more useful exercise.
Choosing by what the address actually receives
Three reasonable destinations, and the choice is mostly determined by the shape of what arrives.
Stay with a collaborative inbox when requests come from colleagues who know what to include, when the volume fits a list a person can scan, and when nobody is asking for numbers. It costs nothing beyond the Workspace licences already in place, and the setup takes an afternoon.
Move to a shared inbox product when the work is genuinely conversational. Long back and forth with the same sender, sales threads, and support that depends on tone all benefit from tools built around threads, drafts, and internal notes.
Move to a form with response management when the request has a fixed shape. Applications, bookings, repair requests, membership signups, and event registrations all have a set of things that must be known before work can begin. Capturing them at submission removes the round trips, and keeping owner and status on the record removes the parallel spreadsheet.
What to change first
Before changing tools, spend one week recording why each open request is still open, in two buckets: waiting on the team, or waiting on the sender. If most of the delay sits in the second bucket, the answer is better intake rather than a better inbox, and a structured form in front of the address will do more than any assignment feature. Halict shows what that looks like from submission through to reply.
Q1. Does Gmail have a real group mailbox, or is it always a workaround?
Google Workspace offers three genuine arrangements: a distribution group, delegated access to one mailbox, and a Google group with collaborative inbox features enabled. The third is the only one that attaches a named owner and a resolution state to each conversation, and it is included with Workspace rather than sold separately.
Q2. Why can some members assign conversations while others cannot?
Every ownership action is gated by a group permission. Claiming, assigning, dropping, and marking complete require the metadata moderation permission, while marking a conversation as needing no action or as a duplicate requires the content moderation permission. Members without the relevant permission can read the inbox but see no way to act on it.
Q3. Can a conversation in a collaborative inbox be assigned to two people?
Assignment names one member at a time. Passing work along means assigning it to somebody else, or dropping the assignment so another member can take it. Labels are the usual way teams express shared responsibility for a category of request.
Q4. Is it a problem to have a form email its submissions to a group address?
It works, and it costs you the structure. The answers arrive as text inside an email body rather than as fields, so nothing can filter, sort, or count on them, and reporting has to be done by hand. Keeping the submission as a record with fields intact avoids both the manual counting and the spreadsheet that usually appears beside the inbox.
Q5. How much should a small team expect to pay for a shared inbox?
Published entry rates currently run from 14 dollars per user per month to 25 dollars per user per month, with free tiers available from some vendors for a handful of users. The number that decides the real cost is the seat cap on the entry plan, since a team above five or ten people is comparing second tiers at 24 to 65 dollars per seat instead.