A request lands at an address like help@ or apply@, four people receive it, and the question of who is answering gets settled somewhere else: a chat message, a hallway, or nobody, which is the expensive case. Google Groups has a feature that addresses exactly this, it costs nothing extra on a Workspace account, and a surprising number of teams running shared addresses have never switched it on.
A collaborative inbox turns a group from a distribution list into something with ownership. Conversations can be claimed, handed to a named person, and closed with a reason. That is a genuine upgrade over an alias that forwards to four mailboxes. It is also a fixed set of moves, and knowing where the set ends is the difference between using it well for years and discovering the ceiling in the middle of a busy month.
What the collaborative layer adds to an ordinary group
Once a group owner or manager turns the feature on, members with the right permissions get two kinds of action on every conversation: ownership and resolution.
Ownership works three ways. Take claims a conversation for yourself. Assign hands it to another member by email address, with an optional note. Drop removes the assignment so somebody else can pick it up. When a conversation is assigned, the assignee gets an automated notification, and anything typed into the note field appears inside the body of that email. That note field is worth using. It is the only place where context travels with the handoff rather than sitting in a separate conversation.
Resolution has three states: Mark as complete, No action needed, and Mark as duplicate. Each one shows next to the subject in the conversation list. Marking a conversation as a duplicate locks it, so no further action is possible on it, and a conversation can only be marked as a duplicate of another in the same group, and only if it is not already a duplicate and does not itself have a duplicate pointing at it. Conversations that are already assigned stay assigned when they are marked complete, which matters when somebody later asks who handled a request.
On top of those, the search bar filters on both dimensions. Assigned to gives three choices: assigned to me, assigned to anyone, not assigned. Resolved status filters down to unresolved conversations only. Those two filters are most of the daily value, because the list of unassigned and unresolved conversations is the only queue the team actually has to clear. Labels sit alongside, letting conversations be categorised across assignment and resolution status.
One behaviour deserves a warning in advance. Resolved conversations can be deleted from the list, and deleting them is permanent with no restore. The safer habit is to filter the list to unresolved instead of clearing it out, and to treat deletion as something that never happens.
Turning it on, and the permissions that gate every action
The setup is short but has two steps, and skipping the second is the usual reason a team concludes the feature is broken.
First, a group owner or manager either creates a group with collaborative inbox features or enables them on an existing group. Second, the permissions have to be set, because every action listed above is gated by one of two settings. Assigning, taking, dropping, and marking complete all require Who can moderate metadata. Marking a conversation as needing no further action, or as a duplicate, requires Who can moderate content. A member without the metadata permission sees the inbox and can read it, but cannot claim anything, which looks exactly like a feature that does not work.
Two details from group creation are worth knowing before the address is printed on a website. Group names can run up to 73 characters. The email address itself can be up to 63 characters before the domain, some words are reserved and cannot be used, and in a work or school account the address may come back with a suffix such as -user-created appended, depending on how the administrator has configured group creation. A group called training can end up as training-user-created@ the company domain, which is not an address anybody wants on a business card. After creating a group, wait a few minutes before sending anything to it, or the first message may bounce.
If Google Groups is not available in a work or school account at all, an administrator has to turn on Groups for Business first.
Where it holds up, and where the shape starts to strain
The honest way to judge it is against what the work actually needs, rather than against a longer feature list.
| What the team needs | Collaborative inbox |
|---|---|
| One address, many handlers | Covered |
| A named owner per request | Covered, one assignee at a time |
| A closed state with a reason | Covered, three fixed states |
| A queue of what is still open | Covered, through the unresolved filter |
| Categories across the queue | Covered, through labels |
| Required information at intake | Not covered |
| Custom statuses such as waiting on requester | Not covered |
| Due dates or reminders on a request | Not covered |
| Reporting on volume, handler, or time to close | Not covered |
| A record per request rather than per thread | Not covered |
Read that table as a fit test rather than a verdict. A team handling a modest number of well formed requests from colleagues will sit comfortably inside the covered rows for a long time. The strain shows up under two conditions, and both are common.
The first is volume of a particular kind. The three resolution states describe outcomes, not stages. There is no way to express that a request is open but blocked on the person who sent it, which is the single most common state in any queue that deals with outsiders. Teams work around it with labels, and the workaround holds until the labels multiply past the point where anybody applies them consistently.
The second is the nature of what arrives. A group receives email. Email is free text, and free text means the information needed to act on a request is present only when the sender happened to include it. Every missing order number, model, date, or file is a round trip, and round trips are where days go.
What the inbox cannot tell you later
A third limit only becomes visible when somebody senior asks a question. How many requests came in last quarter, how long they took to close, which handler carried the most, and how many were duplicates of the same underlying issue are all reasonable questions, and none of them can be answered from the conversation list without counting by hand.
The reason is structural rather than a missing report screen. Assignment and resolution are states on a conversation right now, not a history of states with timestamps attached. Once a conversation is marked complete, the record says complete, and the trail of when it arrived, when it was claimed, and how long it waited is spread across individual message headers rather than held as data. Exporting the group does not fix that, because the export carries messages.
Teams that need those numbers usually build a spreadsheet next to the inbox and log each request into it by hand, which works for a few weeks and then quietly stops being accurate. The moment that spreadsheet appears is a reliable signal that the queue has outgrown what a group can hold.
The part that happens before the inbox
This is the gap that is easy to miss, because it does not look like an inbox problem.
A collaborative inbox is excellent at organising messages after they arrive and has no influence at all over what arrives. If the published route into the team is a bare email address, the quality of intake is whatever each sender decided to type. If the published route is a form, the intake is whatever the form insists on: required fields, a file, a date, a choice from a list that maps to how the work is actually sorted.
The difference compounds. Requests that arrive structured can be routed on the answers rather than read and then routed. They can be counted, because the same question was asked of everyone. And the follow up question that would have cost a round trip was asked at submission time, when the requester was already paying attention, rather than two days later when they have moved on.
There is a common middle path that carries a hidden cost: a form that emails its submissions to the group. That does improve intake, and it also flattens every structured answer back into an email body. The fields exist in the message but not as fields, so nothing can filter or count on them. Teams that go this route usually end up maintaining a spreadsheet alongside the inbox, which is a third place for the same request to live. A form tool that keeps the response as a record with its own owner and status removes that split, because the structured answer and the handling state are the same object.
For a sense of where the alternatives sit on price, three shared inbox products publish their rates openly. Front starts at 25 dollars per seat per month on annual billing for up to ten seats, with a single channel type and up to ten automation rules. Help Scout starts at 25 dollars per user per month and also offers a free plan limited to five users, one inbox, and one documentation site. Missive starts at 14 dollars per user per month on annual billing for up to five users. All three price per person, as does the collaborative inbox, indirectly, through Workspace licences.
Choosing what to run
Three reasonable destinations, depending on what the queue looks like.
Stay on the collaborative inbox when requests come mostly from colleagues who know what to include, the volume fits in a list a person can scan, and nobody is asking for reports. The setup cost is close to zero and the feature is already paid for.
Move to a shared inbox product when the work is genuinely conversational, when the same requester writes back repeatedly, and when the team needs stages beyond complete. These tools are built around threads and are good at threads.
Move to a form with response management when the request has a shape. Applications, bookings, grant submissions, repair requests, and membership signups all have a fixed set of things that must be known before work can start. Capturing those at submission and keeping owner and status on the record itself removes both the round trips and the parallel spreadsheet. Pricing models differ enough here to matter, and a tool priced by the number of people using it rather than by response volume behaves very differently in a busy month. The use cases page shows which request shapes this suits.
What to change first
Turn on the collaborative inbox features and set the moderate metadata permission for everyone expected to claim work, then run a week filtering the list to unresolved and assigned to anyone. If that week shows conversations sitting open because information was missing at the start, the problem is intake rather than the inbox, and the next move is to put a structured form in front of the address. Halict shows what that looks like end to end.
Q1. Is a collaborative inbox the same thing as a shared mailbox?
No. A shared mailbox is a mailbox that several people open. A collaborative inbox is a Google group with an extra layer that lets members claim conversations, hand them to a named person, and mark them complete, needing no action, or duplicate. The underlying object is still a group conversation rather than a mailbox.
Q2. Why can some members assign conversations while others cannot?
Assigning, taking, dropping, and marking complete all require the Who can moderate metadata permission on the group. Marking a conversation as needing no further action or as a duplicate requires Who can moderate content. A member without the relevant permission can read the inbox but sees no way to act on it.
Q3. Can a conversation be assigned to more than one person?
Assignment names one member at a time, by email address. Handing work on means assigning it to somebody else, or using Drop to unassign it so another member can take it. Labels are the usual way teams express something closer to shared responsibility.
Q4. What happens to conversations that are deleted after being resolved?
They are removed permanently and cannot be restored. Filtering the conversation list to show only unresolved conversations achieves the same clean view without losing the history, and is the safer default for any group whose records might be needed later.
Q5. Can the collaborative inbox capture required information from the sender?
No. A group receives ordinary email, so the content is whatever the sender wrote. Requiring specific fields, files, or dates before a request can be submitted needs a form in front of the address, and the structured answers are only usable as data if the tool receiving them keeps them as fields rather than flattening them into an email body.