Shared inbox handover: pass emails on without losing context

To pass an email on from a shared inbox without losing context, keep the original message as it arrived, write a short working note alongside it, name who owns the next step and record the handover as a clear event. Forwarding with ‘FW: can you take this?’ moves the email, but not the context.

An email arrives at office@. Someone opens it, reads it, decides it isn’t theirs and clicks ‘forward’. On the surface everything worked: the email didn’t get lost, and someone received it. In reality a gap has just opened. A shared inbox solves the access problem, since everyone can see everything, but not the ownership problem: nobody knows who is now running the case or what should happen next. Another ‘FW:’ with ‘maybe you know this?’ adds a recipient but no context. The conversation thread is cut off, a phone call note sits with one person and a guess sits with another.

Shared access to one mailbox by several people is a standard use, and Microsoft describes it plainly for company, support or reception addresses. But access alone does not answer the question of who is running the case. This article describes a pattern that any team sharing one address can use: keep the original message, maintain a short working state beside it, name the owner of the next step, name what you are waiting for, and leave a readable trail after the handover.

The original message and the working state are different things

The first temptation after reading an email on a shared address is to turn it into a summary: ‘customer asks about X, sort it out’. From that point the original stops being a point of reference. Only someone’s interpretation remains, and each person who passes it on makes it a little less accurate. If there is a doubt, there is nothing to go back to.

An email has a source structure that is not accidental. RFC 5322, the standard describing message format on the internet, defines it as a header section and an optional body, and fields such as In-Reply-To and References link replies to the conversation thread. This describes a technical format, not a company policy, but it reminds us of something practical: the source holds more information than any summary. Who wrote it, when, in reply to what, in which thread.

That is why it is worth separating two layers of the same case:

• Original: the source message with its content and thread links, kept in the form it arrived in. Do not turn it into someone’s summary; keep the source you can go back to. If the thread matters, do not cut it off with a bare ‘FW: to X’.
• Working state: a short, current description of the work on the case. The summary exists to shorten the next person’s start, not to replace the original message. The case record shows the current state of the work; the original message shows what arrived.

This separation also has a practical side, which the documentation states without hedging: a Microsoft 365 shared mailbox does not let you stop messages being deleted. That does not mean every shared mailbox loses messages. It means that if the original is to remain a point of reference, the business should deliberately decide where it stays available, rather than hoping it is ‘somewhere in there’. Do not assume that moving, deleting or flagging a message by one person will be obvious to the rest of the team.

Minimum context: four questions instead of the full history

Once a working state is kept on a case, there is a temptation to collect everything about the customer. Do the opposite: record only what lets the next person start without rebuilding the basics. Four questions usually do it:

• What is the case about? Customer, subject and, if relevant, a reference number, specific enough to recognise the case without asking.
• What is already known and done? What comes from the original, plus actions taken since it arrived.
• What is missing? Information, access or a decision without which the next step cannot start.
• Who takes the next step, and what is the action? The person or role, plus one named task.

This record does not need to be a system. It just needs to live in one predictable place, where the team looks for a case when they come back to it after a week. Google Workspace’s Collaborative Inbox also supports an optional note when a conversation is assigned, but that is one tool’s mechanics, not a recommendation or proof that sitco uses it.

Who owns the next step, and what are we waiting for?

A shared inbox gives access to messages; the owner says who takes responsibility for the next step. Without that second part, the address spreads responsibility thin: everyone can see it, so someone will deal with it, and ‘someone’ is usually nobody. Google’s documentation shows this distinction in its own tool: a conversation can be assigned to yourself or to another member of the group, and conversations can be searched by assignment status. Again, this is an example, not a universal taxonomy. Carried into a team’s work, the rule is: at every handover, name a person or role, one expected action and the current state.

The second element is the state of waiting. ‘Waiting’ on its own means nothing; it is a label that can hide anything. It only becomes useful when it answers the question: what is the case waiting for information or a decision from, and who will do the work once the reply arrives? A note such as waiting for the customer to confirm the date; once they reply, Sarah prepares the quote says three things at once: what the case is waiting for, from whom and what happens next. The status ‘in progress’ does none of this. It suggests an action that may not exist.

It is also worth closing a case explicitly. Google’s documentation describes marking a conversation as closed. For a team, the equivalent is recording the outcome against the case once it is finished, rather than leaving only a read message in the inbox.

Make the handover a visible event

The moment a case changes hands is not just another message; it is an event worth recording clearly. A handover that states the recipient, the reason and the next action has three parts:

1. Recipient: a named person or role, not ‘the team’ as a collective.
2. Reason: why the case changes hands. One sentence is enough.
3. Next action: one named task with the current state, not ‘deal with this’.

The difference between ‘FW:’ and a handover with context is that the second does not make the recipient guess. It does not guarantee a reply or a timely response, since too many factors affect that to promise anything, but it removes one specific source of confusion: a case that has formally been passed on yet belongs to nobody.

Boundaries of the pattern

Not every message is a case. Some correspondence on a shared address can be dealt with in a single reply and does not need either a working state or an owner. This pattern applies when a message starts living longer than one reply: it comes back for missing information, changes hands, or returns after a week with the question ‘what happened with this?’.

The second boundary: neither the inbox nor any tool makes substantive decisions that the business has not described. RFC 5322 describes the message format, and Google and Microsoft’s documentation describe the mechanics of their own tools. The handover pattern is a team decision: what we record, where, and who is allowed to change it. Our foundation post, “Business automation doesn’t start with AI. It starts with one process.”, sets out the wider method: first describe the process, its data and its rules, and only then choose tools. Email handling on a shared address is a good candidate for a first process, because it repeats every day and has few points of contact.

If emails in your business circulate between people and nobody can say who is responsible for the next step, we can talk it through without commitment: sitco.uk/contact.

Sources cited in the text: RFC 5322 (IETF), Google Workspace documentation and Microsoft 365 documentation are examples of workflow mechanics from official documentation. They are not a recommendation of any tool, nor a description of solutions used by sitco.