Shared inbox migration checklist: move the workflow, not just the mail

The real migration is a change in responsibility

A shared mailbox and a shared inbox can both show the same customer email, but they do not represent work in the same way. In a mailbox, responsibility often lives in habits: a folder means someone took it, a flag means it is urgent, or a chat message says who will reply. A shared inbox makes those decisions explicit through an owner, a status and a visible next action.

That is why copying history or adding a forwarding rule is not enough. A technically successful switch can still leave two competing versions of the truth: one person watches the old mailbox, another works from the new inbox, and each assumes the other route is covered. Treat the cutover as an operating change with entry conditions, acceptance checks and a rollback path.

1. Map the intake before changing it

Start with a route map, not a tool configuration. List every public address and every system that can create customer email. Include website forms, aliases, forwarding rules and any personal address that is still used as an unofficial front door. For each route, name where the message arrives today and who notices when that route fails.

Then record the sender identity customers expect to see in a reply. Receiving mail and sending from the public address are separate checks; a message arriving in the new workspace does not prove that a reply will leave with the right identity.

• Public entry points

  Addresses and forms customers are currently told to use.

• Hidden routing

  Aliases, filters and forwarding rules that can silently divert a message.

• Expected reply identity

  The address that should appear in From when the team replies.

• Failure owner

  The person who checks a route when a test message does not arrive.

2. Take a snapshot of work already in flight

The risky messages are not always the unread ones. An open commitment may sit in a thread that looks answered: a quote promised for Tuesday, a question waiting on a colleague, or a follow-up due after the customer has had time to decide. Before cutover, list the conversations that still owe a next action, even if the last message was sent by your team.

Keep this snapshot bounded. Its job is to prove that every known commitment has an owner in the new workflow, not to recreate the whole mailbox by hand. Historical mail can be imported as reference; active work needs an explicit decision.

• Needs a reply

  The customer is waiting for the team.

• Waiting with a follow-up

  The customer or a third party is expected to act, but the team still owns the reminder.

• Drafted but unsent

  A reply exists, but no sent message proves that it left.

• Unclear

  The next action cannot be established without a person reviewing the thread.

3. Define the operating model before the canary

Write down what an owner means and what each status means before the first live message enters the new inbox. If those rules are invented while people are already replying, the same label will carry different meanings and the migration will preserve the ambiguity it was meant to remove.

A workable baseline is simple: one named owner is responsible for the next action; unassigned means nobody has accepted it yet; waiting means the team has replied but still owns a future check; complete means no next action is currently owed. Also decide how ownership moves during absence and where internal discussion belongs. The rules should answer common cases without requiring a separate chat thread to interpret them.

4. Run a canary on one real route

Choose one address or form route that is real enough to exercise the workflow but bounded enough to reverse. Send controlled test messages from outside the company, then let the team process them as normal work: take ownership, discuss internally, reply, wait and close. A configuration screen saying that forwarding is active is not an acceptance result; the message and reply are the evidence.

Include awkward cases. Send two messages with the same subject, reply while another person has the conversation open, and create a message that should remain unassigned until someone deliberately takes it. The canary should test the operating rules, not only delivery.

5. Cut over, then prove each obligation

Make the full routing change in a defined window and run the same acceptance checks immediately. Record the test message, the route it used, the expected result and the observed result. If a check is not run, mark it not run; do not let an untouched row look like a pass.

• Inbound delivery

  A new external message reaches the new inbox once, with its content and attachments intact.

• Outbound identity

  A reply reaches an external address and shows the intended public sender.

• Ownership and status

  The conversation can be taken, transferred and moved through the states the team defined.

• Unassigned visibility

  A message nobody has taken remains visible as unassigned instead of blending into handled work.

• Deadlines and follow-ups

  A due reply and a promised later action both appear where the team expects to work from them.

• History

  The people handling the message can reach the context needed to answer it accurately.

6. Keep rollback narrow and time-bound

Do not dismantle the old route before the acceptance checks pass. Keep a named rollback action: who can restore the previous routing, what change they will undo, and how the team will reconcile messages received during the test window. Rollback is not running both systems indefinitely; that creates two authorities. It is a short, explicit way back if the new route fails.

Once the new path has passed and the team has worked from it for the agreed observation window, retire the old operating habits as well as the old routing. Remove instructions that tell people to watch the former mailbox, and make the shared inbox the one place that answers who owns a message and what happens next.

How this cutover maps to Inbox Works

Inbox Works brings in an existing team address with one forwarding rule, so customers do not need a new address. Historical email can be imported from eml or mbox files; Inbox Works runs its detection across that history and produces a report of conversations that may have been missed. Treat that report as a review queue, not as proof that every detected item is an open obligation.

For live work, each conversation can have a named owner, and messages nobody has taken remain in an unassigned view. Status is set automatically with a stated reason and can be corrected in one step. Internal comments and @mentions stay beside the customer conversation without being sent to the customer, while reply deadlines are calculated from business hours and approaching or overdue work is surfaced. These controls support the operating model, but the canary and acceptance checks still need people to prove that the chosen routes and identities work in their environment.