Shared Inboxes, Many Hands: Ownership Locks for Small-Team Email Automation

Disclosure: I co-founded NxFlowAI, an AI automation agency. Examples are generic.

Small UK firms often run one shared inbox: info@, hello@, enquiries@. Three people read it, and now an automation drafts replies too. The classic failure is the double reply: two staff answer the same customer with different prices, or a person answers while the bot's draft also goes out.

For AI automation agency builds for UK small-business inboxes, the pattern I recommend is an ownership lock. Here is the design.

The problem, stated precisely

A thread can be touched by several actors: humans in the mail client, an automation drafting replies, and sometimes a CRM sequence. None of them knows the others are working. You need a shared notion of "who owns this thread right now".

The lock

Store one record per thread:

thread_id | owner (person or "automation") | claimed_at | expires_at | state

Rules:

1. Claim before acting. Any actor must claim the thread before drafting or sending. Claims are atomic (a conditional update that only succeeds if the thread is unowned or the claim has expired).
2. Humans outrank automation. A person can always take a thread from the automation. The automation can never take a thread from a person.
3. Locks expire. If a person claims a thread and goes to lunch, the claim expires and the thread returns to the queue with a nudge.
4. Release on send. Sending a reply releases the lock and records who replied.

Surfacing the lock to people

The lock is useless if people cannot see it. Put the owner's name in a label or category inside the mail client, or a short note at the top of the thread. People will respect a lock they can see.

Drafts, not sends

For most small firms, the automation should draft and a person should send. That alone removes most double-reply risk. Where the automation does send (acknowledgements, confirmations), it must hold the lock first.

Test with chaos

Simulate two people and the automation working the same queue. If you never see a double reply in testing, the design is probably right.

For a broader view of mapping who touches what before building, see our notes on auditing a workflow before AI.

Disclosure, again: I co-founded NxFlowAI and have a commercial interest in this topic.