Process · shared inbox
Everyone can see the email. Someone has to own it.
On a shared address, “someone will deal with it” usually means nobody. The system keeps the original separate from the working status, records the minimum context and assigns an owner for the next step. A handover records who, why and what to do — instead of “FW: can you sort this”.
FW: FW: Re: order 3110
“When is the delivery? The contract said 20 October and nobody has replied for a week.”
+ 6 earlier messages in the thread
- About
- Order 3110, Barton Builders
- Known
- contract date: 20 Oct
- Missing
- confirmation from the warehouse
- Owner
- Kate
- Action
- confirm the date to the customer
- Waiting for
- a reply from the warehouse
named wait not just “pending”
Fictional data. Fields and rules are agreed for your process.
What comes in. What goes out.
01 · Comes in
An email to a shared address.
The original stays untouched as the reference — no summaries along the lines of “customer asking about X, sort it”.
02 · The system sorts it
A working status and an owner.
The minimum context in one predictable place. One person is responsible for the next step.
03 · Goes out
A handover as an event.
Who it goes to, why, and one named action. The recipient doesn’t have to guess.
Minimum context: four questions instead of the whole history.
We record only what lets the next person start work without reconstructing the basics.
- 01
What is it about?
The customer, the subject and a reference number if there is one — specific enough to recognise the case without asking.
- 02
What do we already know and what has been done?
What the original says, plus anything done since it arrived.
- 03
What is missing?
The information, access or decision without which the next step can’t start.
- 04
Who takes the next step?
A person or role, and one named task.
An ordinary day in this process.
Every step stays in the log. Purple rows are where the system deliberately stopped and is waiting for a person.
- 08:20 office@: question about the date of order 3110working status created done
- 08:21 Owner: Kate · confirm the dateassigned done
- 08:21 Waiting for a reply from the warehousenamed wait paused
- 12:10 Customer asks to change the delivery addressadded to the case, not a new thread done
- 15:30 Handover to Tom: Kate on leavewho · why · action done
- 15:31 Complaint in the same threadneeds a decision waiting for you
Sample log, fictional data. Scope, rules and stopping points are agreed in the process map.
The limits are part of the system.
If the data is incomplete or contradictory, or the case doesn’t fit the rules, the system doesn’t guess. It flags an exception and passes it to a person. That isn’t a failure — it’s a checkpoint.
The system can
- keep the original separate from the working status
- record the minimum context of the case
- assign an owner and a named wait
- hand the case over with who, why and what to do
- chase a case that hasn’t moved
A person decides
- the substantive reply
- decisions the business hasn’t written down
- complaints and exceptions
- judging whether an email is a case at all
We cover this pattern in more depth on the blog
Shared inbox handover: pass emails on without losing contextOther processes we often start with
Enquiries and quote requests
An email describing a job → a brief with the gaps listed → a draft reply for approval.
See the processDocuments and invoices
A PDF or scan → a completeness check → a specific next step, or an exception with a reason.
See the processService requests
A form → missing details shown openly → a handover with a condition and one task.
See the processGot a process like this?
Describe it in a few lines. We’ll tell you whether it’s worth automating, where to start and what to leave alone.
Or call +44 7822 000220 · email info@sitco.uk