Four people open the same list at nine in the morning. Twenty three new messages. Nobody has said who is taking which, so each person scans the list making a private calculation: this one looks quick, that one needs the manager, somebody else has probably got the awkward one. Thirty minutes later two of the twenty three have been answered twice, four have been answered once, and seventeen are still sitting there because each of the four assumed one of the other three would get to them.
The tooling is not the problem in that scene. The problem is that the question of who answers was left to be decided at read time, in four separate heads, with no way for any of them to see what the others concluded. A Gmail shared inbox becomes reliable at the point where that decision moves earlier: into a written rule that applies before anyone opens the list.
Why the decision gets expensive when it is made at read time
Leaving assignment to the moment of reading creates three costs, and none of them appear as a line item anywhere.
The first is hesitation. Deciding whether to take a message requires a guess about what everyone else is doing. Guessing takes a few seconds, happens on every message, and produces the wrong answer often enough that some messages get two replies and others get none.
The second is selection. When people choose their own work from an open list, easy items go first. That is not laziness, it is the rational response to an unstructured pile, and the effect is that difficult requests age while simple ones are cleared. The ageing is invisible because nothing in the list shows how long anything has been waiting for an owner.
The third is concentration. In almost every team that runs an address this way, one person ends up handling the majority of it, usually whoever reads fastest or cares most. Nobody decided that, nobody is tracking it, and it stays hidden until that person is away for a week and the address quietly falls over.
A policy decided in advance removes all three at once. It does not have to be sophisticated. It has to be written down, and it has to be checkable by looking at the list rather than by asking people.
Four assignment policies that hold up
Most working teams land on one of four arrangements. The differences matter less than picking one deliberately.
| Policy | Works best when | Fails when | What the tool must support |
|---|---|---|---|
| Duty owner on a rota | Volume is modest and requests are similar | One rota day is unexpectedly heavy | A shared calendar and a name on each item |
| Round robin on arrival | Volume is steady and work is interchangeable | Requests vary widely in effort | Assignment, ideally automatic |
| Split by category | Requests fall into clear types with different skills | Categories are ambiguous at first glance | Labels or rules, plus assignment |
| Claim within a fixed window | The team is small and sits together | People are in different time zones | A visible unassigned queue |
Duty owner is the simplest that works. One named person owns everything that arrives on their day, including deciding what to hand on. Everyone else stays out of the list unless assigned something. The cost is a heavy day now and then, and the benefit is that the answer to who is dealing with this is known before the message arrives.
Round robin distributes evenly and is the natural fit where the work is genuinely interchangeable, such as booking confirmations. Doing it by hand requires somebody to act as dispatcher, which is a real job when volume is high. Products in this category automate it with rules, and that automation is often the reason teams pay.
Split by category matches the way most teams already think. Applications to one person, billing questions to another, technical problems to a third. It depends on the category being obvious from the message, which is precisely where an email address is weakest, because the sender writes prose rather than choosing from a list.
Claim within a fixed window keeps the flexibility of self selection while removing the hesitation. The rule is that anything unclaimed after a stated interval becomes the duty owner's problem, so the unassigned queue has a deadline attached even though the individual messages do not.
What Gmail can actually enforce
Having chosen a policy, the next question is how much of it the tooling will hold and how much stays in people's memory.
Delegated access to a single mailbox gives shared read state, which is enough to stop most double replies, and nothing else. There is no field that records a name against a message, so a rota or a round robin has to be remembered rather than recorded. The audit trail is thin: the mailbox knows a reply was sent, and who sent it is not something anyone will want to reconstruct later.
A Google group with collaborative inbox features enabled is the first arrangement that holds a policy. Conversations can be taken, assigned to a named member with a note, or dropped back to the unclaimed pile, and the list can be filtered to what is assigned to the person looking, assigned to anyone, or not assigned at all. That last filter is the one that makes a policy checkable, because the unassigned and unresolved list is exactly the set of messages the policy has failed to cover so far today.
Two constraints are worth knowing before building a process on it. Every one of those actions is gated by a group permission, with claiming, assigning, dropping, and marking complete depending on the metadata moderation permission, so a member without it sees the queue and cannot act on it. And assignment is manual. There is no rule engine, so round robin and category routing both require a person to do the routing, every time.
Labels fill the gap for category routing, and filters can apply labels automatically based on words in the message. That works for reliable markers such as a sender domain or a subject line generated by another system. It works poorly for human prose, where the same request arrives worded twenty different ways.
A rota is only as good as its handover
Every assignment policy has a failure mode at the edges, and the edges are holidays, illness, and people leaving.
The mechanics are simple enough to state. Anything assigned to somebody who is away is, in effect, unowned while still looking owned, which is worse than being unassigned because it will not show up in a check of the unclaimed queue. A weekly scan filtered to assigned to anyone, sorted oldest first, catches these. So does the habit of dropping assignments before going on leave rather than after coming back.
The deeper problem is context. When a request has been going back and forth for a week, most of what matters about it is not in the messages. It is in what was promised on the phone, which internal decision is pending, and what the sender is actually trying to achieve. If that lives in one person's head, the handover is a conversation that may not happen. The note field on an assignment is the cheapest fix available, since it travels with the work into the new owner's notification rather than sitting in a separate chat.
Teams that need more than that generally want the record itself to carry the history: who held it, what changed, what was sent, in order. That is a different data model from a thread of messages, and it is the point at which a mailbox stops being the right container.
Ownership cannot make a request answerable
There is a limit to what any assignment policy can achieve, and it is worth stating plainly because it explains a lot of frustration.
Assigning a message decides who will work on it. It does not decide whether the work can start. A request missing an order number, a date, a file, or a choice from a list cannot be actioned no matter how promptly it is claimed, and the reply that asks for the missing piece costs a day or two because the sender has moved on to something else. In most queues that deal with people outside the team, this waiting is the majority of the elapsed time on a request, and no amount of rota discipline touches it.
The structural fix is to stop accepting free text as the front door. A form can require the fields that make a request actionable before it will accept a submission, which moves the missing question to the moment when the requester is still engaged. A form tool that keeps each submission as a record with its own owner and stage also makes the assignment policy easier to run, because routing can key off the answers rather than off somebody reading the message and deciding.
The half measure to avoid is a form that emails its answers into the shared inbox. Intake improves, and the structure is flattened back into an email body, so nothing can be filtered, sorted, or counted, and the routing still depends on a person reading prose.
When the policy needs the tool to do the routing
If the chosen policy is round robin or category based, and volume has grown past the point where a dispatcher is reasonable, automatic routing becomes the thing being purchased. Published rates at the time of writing give a sense of the floor: Missive starts at 14 dollars per user per month for up to 5 users, Front starts at 25 dollars per seat per month billed annually for up to 10 seats with a single channel type and a limit of ten automation rules, Hiver starts at 25 dollars per user per month billed annually with all plans starting at 2 seats, and Help Scout offers a free plan for 5 users with one inbox before its paid tier at 25 dollars per user per month.
Each of those prices a seat, so the bill follows headcount rather than the number of requests. For a team whose volume swings by season, comparing what the price is counted on matters more than comparing the headline figure, and a tool that does not meter responses at all behaves differently in a heavy month.
Check the policy against last month rather than against opinion
One cheap test settles most arguments about which policy to run. Take the last thirty requests, write down who answered each one, and count. If a single name holds more than half of them under a policy that was supposed to spread the load, the policy is not being followed, and the reason is usually that it was never written anywhere a person could check it. If the names are spread but the slowest items all came from one category, the answer is category routing rather than a rota. The count takes twenty minutes and is more reliable than any discussion about what the team feels is happening.
What to change first
Write the assignment policy as one sentence, name the person it applies to today, and put the unassigned and unresolved filter on a screen somebody looks at twice a day. Run it for a week, then check whether the remaining delay is people waiting to claim or people waiting for missing information, because the second one is fixed in front of the inbox rather than inside it. Halict shows how a structured submission carries its own owner from the start.
Q1. Is a shared inbox the same thing as a shared Gmail account?
No, and sharing an account password is the arrangement to avoid. Google Workspace supports delegated access, where several people work one mailbox from their own accounts, and Google groups with collaborative inbox features, where conversations carry a named assignee. Both keep individual sign in, which matters when somebody leaves the team.
Q2. How many people can work a shared inbox before it needs real assignment?
Two people who sit together can often run on conversation alone. At three the double replies start, and at four the silent drops start, because each person's estimate that somebody else has handled it rises with team size. A written policy and a visible unassigned queue are worth putting in place before that point rather than after.
Q3. Can Gmail assign incoming messages automatically?
Not as an assignment. Filters can label or forward messages based on their content, which covers routing by sender domain or by a subject line generated by another system, but assigning a conversation to a person in a collaborative inbox is a manual action. Automatic round robin and rule based routing are features of paid shared inbox products.
Q4. What happens to messages assigned to someone who goes on holiday?
They stay assigned and therefore stay invisible to any check of the unclaimed queue, which makes them the most likely items to be forgotten. Dropping assignments before leave, and running a weekly scan of everything assigned to anyone sorted oldest first, catches them.
Q5. Should form submissions go into the same shared inbox as email?
Only if the answers survive as fields. A form that mails its results into the inbox turns structured answers back into prose, so routing and reporting have to be done by hand. Keeping submissions as records with an owner and a stage lets the routing rule read the answers directly, which is what makes a category based policy practical.