Almost every support team starts the same way: support@company.com, forwarded to three people, or a shared mailbox everyone signs into. It works until the day two agents answer the same customer with different information, or a message sits unanswered for four days because each person assumed a colleague had taken it.
The usual diagnosis is that the team needs a help desk. The more useful diagnosis is that a shared mailbox shares exactly one thing, the messages, and a working support operation needs to share four more.
The five things that have to be shared
| What is shared | Shared mailbox | Shared inbox |
|---|---|---|
| The messages | Yes | Yes |
| A single owner per conversation | No; ownership lives in memory or a chat thread | Yes, as a field, validated against real team members |
| Assignment history | No | Yes: who had it, who took it, when, and why |
| Internal context, kept off the customer | Only by convention | Yes: notes are a different object, not a different button |
| A record that outlives the handler | Only as far as one mailbox’s search | Yes: the conversation belongs to the workspace |
Rows two through five are the whole argument. Everything a shared mailbox cannot do traces back to the fact that an email has no owner field, so every convention built on top of it is a social agreement rather than a property of the system. Social agreements fail at exactly the moment they are most needed: when someone is on holiday, when volume spikes, and when the person who remembered the convention has left.
Ownership is a field, and it has to be validated
Ownership means a conversation has exactly one person accountable for it, stored as data, changeable by an explicit act that leaves a trace.
The subtle requirement is validation. An owner field that accepts any value is barely better than a sticky note, because the failure mode of support assignment is not typos. It is assigning work to people who cannot do it. A teammate who left last month, a colleague from a different department, a user id that belongs to another company’s account: each of these produces a ticket that looks handled and is not, which is worse than a ticket that looks unhandled.
In the Oneop help desk, the owner must be an integer user id greater than zero, must exist in your workspace, and must not be deactivated; anything else is refused with a 422 naming the invalid owner rather than accepted. Status and priority are validated the same way, as closed vocabularies of seven and five values, and a rejected update returns the allowed list so an integration finds out what it should have sent. Every change writes an audit row naming the field, what it was and what it became.
Worth saying plainly, because plenty of products imply otherwise: there is no transition graph. Any state can move to any state, so a closed ticket can be reopened and nothing in the API stops it. If reopening needs a rule at your company, that rule is a person or an automation, not the ticket API.
Collision detection, and why assignment beats indicators
Two agents working the same conversation is the defining failure of a shared mailbox, and there are two ways to prevent it.
The indicator approach shows a live “someone else is viewing this” badge. It is useful and it is fragile: it depends on both browsers being connected, it disappears when a tab is closed, and it tells you about the present moment only. An agent who opened a ticket, drafted a reply, went to lunch and came back has no protection from it.
The assignment approach makes taking a conversation an explicit, persistent act. Unassigned work is visibly unassigned, taking it writes your name to the record, and the queue view distinguishes the three states that matter: unassigned, mine, everyone’s. Assignment survives closed tabs, restarts and shift changes, which is why it is the mechanism to insist on. An indicator is a good supplement to assignment and a poor substitute for it.
Oneop prevents collisions by assignment rather than by presence badges on tickets: a single validated owner, focused queue views, reassignment, and a field-level audit row on every change. In live chat, where conversations arrive in real time and cannot wait for a human to claim them, ownership is assigned by a router instead. It skips agents with no open connection, agents who are not online, and agents already at their concurrent limit, then scores the remainder by current load, recent activity and chat priority. Presence there is real state rather than a guess: the last connection closing is what marks an agent offline, so having three tabs open does not make presence flap.
Internal notes must be a different object, not a different button
An internal note is the most dangerous thing in a support inbox, because its safety in a mailbox rests entirely on a human clicking correctly.
In a mailbox, a note to a colleague and a reply to a customer are the same kind of thing: text in a thread. The separation is one click wide. A reply-all, a forward that quotes the thread, or a later message that includes the earlier chain can all put “this customer has been a nightmare since March” in front of the customer. This is not a hypothetical class of incident; it is the single most common way a support team publicly embarrasses itself.
The fix is structural. A note has to carry a flag in the database, and every path that shows a conversation to a customer has to filter on that flag. Not most paths, every path. The word “every” is doing real work there. Oneop routes all visitor-facing transcript paths through a single projection function, and that design exists because the same leak happened twice on two different code lines: once from a raw row being returned directly, and once from a reconnect replay that tested who wrote a message instead of testing the flag. One filter is not a nicety; it is the only shape that cannot be forgotten at the next new endpoint. Internal notes are never included in outbound mail either.
One honest boundary in the same area, because it cuts the other way: Oneop’s live chat reply suggestion is given the last ten messages of the thread, and those ten include internal notes. Treat a note written during an active chat as something a draft may have read.
The failure case: the mailbox that lost a customer’s history
Here is what a shared mailbox actually costs, and it is not the duplicate reply everyone talks about.
A customer emails support in March with a billing problem. An agent resolves it, promises a credit on the next invoice, and the agent leaves the company in June. In August the same customer writes back asking why the credit never appeared. The mailbox still holds the March thread, technically, but nobody searches for it because nobody knows it exists: the new agent has a name and a complaint, not a history. They ask the customer to explain from the beginning. The customer, who explained it in March, is now dealing with a company that does not remember its own promises.
Nothing was deleted. The history was simply never attached to the customer; it was attached to a folder. A shared inbox that shares ownership and a record fixes this by making the conversation belong to the workspace and to the customer’s record rather than to whoever handled it. In Oneop, the help desk shares a database with the CRM and the ledger, so the ticket screen resolves the customer’s contact and finance record at read time, surfaces up to six related open tickets from the same requester, then the same company, then a shared tag, and shows the orders and invoices on the account. The reason agents ask customers to repeat themselves is almost never that they do not care; it is that the answer is in a different system. The broader argument for that sharing is in why an AI agent needs a system of record.
What to insist on when you evaluate one
Five questions, all answerable in a trial. Can a conversation have exactly one owner, and is that owner validated against your actual team? Does every change leave a record naming the field, the old value and the new one? Are internal notes a different object with a filter on every customer-facing path, or a different button? Do messages arriving by different routes, mail, chat or a form, land in the same queue with the same rules? And can you find a conversation from the customer’s record rather than only from the inbox?
If the answer to any of those is a convention rather than a mechanism, you are still running a shared mailbox with better styling. The Oneop shared inbox, tickets and live chat are on every plan including the free one; the structure to put around them once they are in place is in how to run support on two channels.