Rolling Out AI Email on a Shared Inbox Team

An AI email for a shared inbox team rollout fails for a different reason than a personal one does. On your own mailbox the worst case is a bad draft you delete. On support@ or billing@, where four people send from the same address, it is two teammates sending different answers to the same customer nine minutes apart — and neither knowing it happened.

Most rollout advice treats that as a notification problem. Mute this, filter that, add a rule. It isn't. Duplicate replies are an ownership problem, and an AI assistant either hardens the ownership model or quietly adds a fifth actor who ignores it. Sequence the rollout around that decision and the rest of the criteria fall out of it.

The short answer#

Introduce the assistant in five stages, and do not skip the boring first one. Each stage adds exactly one new capability, so when something goes wrong you know what caused it.

1. 1

   Decide the identity model before you connect anything

   Does each teammate authenticate as themselves against the shared address, or does the tool hold one credential for the mailbox? This determines attribution, offboarding and whether the audit trail can name a person. Everything else is downstream of it.

2. 2

   Run read-only for a week

   Let the assistant categorise, summarise and surface — no drafting, no sending. You are checking that its reading of your queue matches the team's, and that nothing in the connection breaks your existing filters or forwarding.

3. 3

   Turn on drafting for assigned threads only

   A draft should exist for one named person. If the assistant will draft on unassigned threads, two people can open the same thread and find a ready reply waiting. That is the duplicate you were trying to prevent, now pre-written.

4. 4

   Require approval on every send, from a named human

   Approval-before-send is not a training-wheels setting you graduate out of in week two. On a shared address it is the record of who took responsibility for a reply that went out under a name nobody personally owns.

5. 5

   Read the log for two weeks before widening anything

   Only then consider more autonomy, and only per queue — never across every shared address at once.

Why duplicate replies happen, and why rules don't fix them#

A shared address has no natural owner. Every message arrives for everyone, so "someone will get it" and "I thought you had it" alternate depending on how busy the week is.

Notification rules address the wrong half. They change who finds out about a message; they do not change who is responsible for it. The moment two people both find out, you are back where you started — and an assistant that drafts on arrival makes acting on it faster for both.

The criteria that actually decide the rollout#

Feature lists compare drafting quality. Drafting quality matters least here, because a human reads every draft in the first month anyway. These are the dimensions that decide whether the rollout survives contact with four people and a busy Tuesday.

• Identity model — does the tool act as each teammate, or as one credential for the mailbox?
• Collision control — what structurally stops two people replying: assignment state, a real-time presence indicator, or nothing?
• Assignment as an object — is an assignee a first-class field with a status, or a label you all agreed to use?
• Approval scope — can approval be required per mailbox and per person, rather than one global switch?
• Audit granularity — does the log name which human approved which AI draft, or only that a reply was sent?
• Reversal — is there a send-delay window you can cancel inside, and does cancelling get recorded?

Scoring the criteria#

How the AI connects decides what it can do#

"Shared inbox" means three different things technically, and the differences are not cosmetic — they change which capabilities are available to any tool you buy.

On Microsoft 365, Graph exposes shared and delegated folders through the delegated permissions Mail.Read.Shared and Mail.ReadWrite.Shared. Microsoft's own documentation adds a caveat worth knowing before a vendor demo: those two permissions do not support subscribing to change notifications on items in shared or delegated folders. A tool that wants push updates on a shared mailbox needs the application permission Mail.Read instead — a broader, tenant-level grant your admin has to approve.

On Google, the published Gmail scopes are scoped to the authenticated user's own mailbox. Google documents gmail.settings.sharing as restricted to administrative use, available only to Workspace customers using a service account with domain-wide delegation. Google does not publish a delegate-access path in that scopes reference, so treat any vendor claim about Gmail delegation as something to confirm with them directly rather than assume.

Who owns a reply once the AI has drafted on it#

The assistant should never be the owner. It is a drafter, not an accountable party, and any model where "the AI sent it" fully answers "who sent this?" will fail its first real dispute.

The workable rule: a draft inherits the thread's assignee. If nobody is assigned, the assistant may summarise and categorise but not compose — a composed reply on an unowned thread is an invitation for whoever opens it next.

• Assignment moves ownership; the draft follows it, along with any handoff note.
• The approver, not the assignee, is the person of record on a send — they are often the same person, and the log should say so either way.
• Reassigning mid-thread transfers the pending draft rather than duplicating it.
• Internal notes stay internal. Coordination that could be emailed to the customer by accident is a design flaw, not a training issue.

Worked example: support@ with four people, two weeks#

1. 1

   Days 1–2 — map the current reality

   Count last month's threads and how many got two replies. You need the baseline, because after the rollout everyone will remember the old process as tidier than it was.

2. 2

   Days 3–7 — connect read-only

   One mailbox, four members, no drafting. Check that categorisation matches how the team already thinks about the queue. Fix the categories now — it is much harder once drafts are in flight.

3. 3

   Days 8–10 — assignment first, AI second

   Get the team assigning threads with statuses, without the assistant drafting anything. If assignment discipline does not hold for three days with humans only, an assistant will not create it.

4. 4

   Days 11–12 — drafting on assigned threads

   Enable drafting, scoped to threads with an assignee. Every send is approved by that assignee. Nobody gets more autonomy yet, including the person who asked for it loudest.

5. 5

   Days 13–14 — read the log together

   Pull every AI-assisted send and read the reasoning next to the reply. The ones where the approver clearly clicked through tell you which queues are not ready for more autonomy.

Red flags#

• The tool cannot tell you which human approved a specific AI-assisted send. If the log stops at "reply sent", it is not an audit trail.
• Autonomy is one account-wide switch. You need it per mailbox and per role — billing@ and careers@ do not carry the same risk.
• Assignment is a label. Labels have no status, no single-owner guarantee, and no way to list what is waiting on review.
• The demo runs on a personal Gmail. Ask for it on the shape you actually run, because a personal mailbox cannot reproduce these failure modes.
• Undo is described but not demonstrated. Ask to see the cancellation appear in the log, not just the button.
• The vendor cannot name the permission scopes it requests. That question has an objectively correct answer, and it is a fair proxy for the rest.

What we'd pick, and who should buy something else#

Start with the honest split, because it decides more than any feature comparison. If your shared address is a support queue with obligations attached — response-time targets you report on, round-robin routing, satisfaction scoring, ticket-level analytics — buy a helpdesk. Front and Missive are both built around shared-inbox collaboration, and Front publishes real-time collision detection that shows when a teammate is already replying to a conversation. That is a stronger answer to the duplicate-reply problem than assignment state alone, and we do not publish an equivalent presence indicator. If watching a colleague type is what would make your team trust the rollout, go and buy that.

We build AI Emaily, and it is the right pick for the other shape: a small team of operators working a shared address inside their actual mail client, who want an ownership model rather than a ticket system. Sharing a mailbox grants members access to its threads while the owner's OAuth tokens and context stay owner-scoped. Assignment is a real object with an open, working, needs-review, done lifecycle, and the same menu that hands a thread to a teammate hands it to the agent with an explicit authority level. Under Copilot nothing sends until a person approves it. The agent drafts as the mailbox owner, using that owner's context brain and client profiles rather than anything inferred from the team's past mail, so the address keeps one voice whoever is at the keyboard.

Two limits worth knowing before you plan around us. The agent audit log records agent and rule actions — a reply a teammate types and sends by hand shows up in sent mail, not in that log, so it is not yet the single unified activity record some teams want. And shared inboxes sit on the Team plan with a three-seat minimum, which the seven-day trial on Pro and Autopilot does not cover; check the current terms on our pricing page before you budget.