Shared inbox

What is a shared inbox: the term explained, and the thing it is constantly confused with

A shared inbox is a team workspace where incoming work arrives in one queue and each item can be assigned an owner, given a status and tracked to completion, rather than sitting in an individual's personal mailbox. The queue, not the person, holds the work.

The point is not that several people can see the same messages. It is that every item has an answer to three questions at any moment: who owns this, what state is it in, and what is it waiting on.

What does a shared inbox mean in practice?

Work that arrives by email lands in whoever's mailbox it was addressed to. That person becomes a single point of failure for it. They go on holiday, and the case waits. They reply from their own address, and the thread leaves the team's view entirely.

A shared inbox changes where the work lives. Items enter a queue the team owns, someone claims one, the status moves, and anyone can see the whole picture without asking in a group chat whether a case has been picked up.

A shared mailbox is not a shared inbox

This is the confusion worth naming, because plenty of teams believe they already have a shared inbox when what they have is a shared mailbox, and the difference only becomes visible under load.

A shared mailbox is a mailbox that several people are given permission to open. In Microsoft 365 the mechanics are explicit in the documentation: a shared mailbox has sign in blocked by default, access is granted through Full Access, Send As and Send on Behalf permissions, and it usually needs no separate licence. It is a mailbox with delegated access. That is genuinely useful, and it is all it is.

What a shared mailbox does not carry:

• Ownership. There is no assignment. Two people answer the same message, or nobody does, and the mailbox cannot tell you which happened.
• Status. Read and unread is not a workflow. It is a per user flag that says nothing about whether the work is finished.
• Accountability. The reply appears to come from the mailbox, so the record of who actually handled it is weaker, not stronger, than in a personal inbox.
• Measurement. No queue age, no time to first response, no view of what is waiting on a customer versus waiting on you.
• Structure. Everything is a thread with attachments. Nothing is a case with fields you can filter, route or report on.

Calling that a shared inbox is a common mistake, and an expensive one, because the team believes it has solved a coordination problem it has only relocated.

How does a shared inbox work?

• Intake. Items arrive from one or more channels: an address, a form, an API call, or a completed submission from another system.
• Routing. Rules put an item in the right queue based on its content, its source or its type, so triage is not a manual sorting job.
• Assignment. A person claims an item or is assigned one. From that moment the item has an owner and the owner is visible.
• Status. A short, honest set of states. Open, waiting on customer, in review, closed. Statuses that nobody updates are worse than none, because they mislead.
• Internal notes. Discussion attached to the item rather than in a separate chat, so the reasoning survives the handover.
• History. A record of who did what and when, which is what turns a disputed case into an answerable one.

Shared inbox explained: a service intake queue

A workshop receives thirty customer submissions before ten in the morning. Each one enters the queue, is routed by vehicle type, and is claimed by an advisor who sets it to in review.

Four are missing a photo of the identification plate. The advisor sets those to waiting on customer and sends a retake request, which keeps them out of the review count without losing them. By midday the manager can see nineteen closed, seven in review and four waiting, without interrupting anyone to ask.

Where shared inboxes still go wrong

• Everyone's queue is nobody's queue. Without an assignment rule or a claiming habit, a shared queue reproduces the shared mailbox problem with a better interface.
• Too many statuses. Fourteen states means people pick one at random. Five that everyone understands beats a taxonomy that only its designer can apply.
• Ownership without authority. Assigning a case to someone who cannot approve the outcome creates a queue of items waiting on a person who was never able to move them.
• No exit to the system of record. If the outcome has to be retyped into a CRM or a claims system afterwards, the inbox has added a step rather than removed one. Connect it, using the patterns in integration.

The plumbing that makes one workable is ordinary: a webhook to push a status change outward, a REST API to pull cases into a report, single sign on so nobody maintains another password list, and role based access control so that viewing a case and closing one are separate rights.

Where the incoming work is visual, the queue matters as much as the capture. Venta Capture, a product of VentaVid, delivers each completed guided capture into a shared inbox as a structured case with assignment, status, comments and retake requests, so the submission arrives as work with an owner rather than as an attachment in somebody's mail.