AI email automation: the inbox, not the campaign

"Email automation" usually means sending — campaigns, sequences, newsletters. The larger and less examined problem is the other direction: the shared mailboxes where real work arrives, sits, gets handled twice or not at all, and where nothing is measured because a mailbox is not a system.

Most organisations have several of these. They are where customers, suppliers and colleagues actually reach the business, and they are managed with folders, colour labels and somebody's memory.

What we'll cover

• A shared mailbox is an unmanaged queue
• What goes wrong in one
• Triage, and what it should produce
• Building it with CodeWords
• Routing to a person
• Drafting replies rather than sending them
• Threads, forwards and the mess
• What should never be auto-sent
• Measuring a mailbox for the first time
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

A shared mailbox is an unmanaged queue

It has all the properties of a work queue and none of the tooling.

No ownership per item, so responsibility is ambiguous by default.

No state beyond read and unread, which is not a workflow.

No ageing visibility, so something four days old looks like something from this morning.

No measurement, so nobody knows the response time or the volume by type.

Folders are not a solution, they are a filing system, and they hide items rather than progressing them.

What goes wrong in one

Items handled twice, because two people opened the same message.

Items handled by nobody, because each assumed the other had.

Long-running threads lost among newer messages.

Anything requiring a wait — a reply from a supplier, an internal answer — disappears and resurfaces as a complaint.

Coverage gaps during leave, since knowledge of what is outstanding lives in individuals.

The escalation arrives from outside, which is how most of these problems are discovered.

Triage, and what it should produce

A category, which determines who handles it and how quickly.

An urgency, from the content rather than from the sender's assertion of it.

An owner, assigned rather than available.

The context attached: who this is, their history, any related open item.

A duplicate check, since the same request frequently arrives twice through different routes.

A visible state, which is the thing a mailbox fundamentally lacks and the reason work goes missing in one.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: how mail is categorised, who it goes to, what context is attached, and what is drafted.
3. Authorize the connections — the mailbox, the CRM or helpdesk, and your chat.
4. Describe the exceptions: an unclear message, an automated sender, a thread already assigned, anything urgent.
5. Run it over last month's mailbox and check the categorisation and routing against what actually happened.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Routing to a person

Assign an individual, not a team, since a team assignment reproduces the original problem.

Respect existing ownership. A reply on a thread somebody is handling goes to them, not through triage again.

Check availability, or items sit with somebody on leave.

Balance by open items, not by count assigned, since messages differ enormously in effort.

Escalate on age, automatically, which is the mechanism a mailbox has never had.

Make reassignment easy and logged, because the first routing will sometimes be wrong and the correction is useful data.

Drafting replies rather than sending them

A draft is the safe form of this, and it captures most of the time saving.

Use your own previous replies as the basis, since they encode your tone and your actual policies.

Cite the source, so the person sending can check the claim rather than trusting it.

Leave the gaps visible. A draft with a marked placeholder is more useful than one that invented a plausible detail.

Record the edits, which tell you where drafting is going wrong and is free feedback.

One click to send, because a draft requiring reformatting is slower than writing from scratch and will not be used.

Threads, forwards and the mess

A thread is one item, not several, and treating each message separately duplicates work.

Forwards break attribution, since the sender of the forward is not the person with the question.

Quoted history confuses categorisation, because the old content frequently outweighs the new.

Automated senders are a large share of any mailbox and should be filtered before triage rather than routed.

Out-of-office replies should close a loop rather than create a new item.

Somebody replying to an old thread for a new reason is common and is the case that naive threading gets wrong.

What should never be auto-sent

Anything with a commitment in it — a date, a price, a promise about what will happen.

Anything to an upset customer, where an automated reply reads as dismissal.

Anything legal, contractual or regulated, which needs a person regardless of confidence.

Anything to a complaint, which in some sectors has defined handling requirements.

A first reply to a new relationship, since the first impression is worth a person's minute.

Acknowledgements are the exception and are worth sending automatically, provided they are honest about what happens next.

Measuring a mailbox for the first time

The most useful output of automating a shared mailbox is that it becomes measurable, and most organisations have never seen these numbers for a channel that carries real work.

Volume by category, which is nearly always distributed differently from how people describe it.

Time to first response, as a distribution, since the tail is where the complaints originate rather than the median.

Time to resolution, separately, because a fast acknowledgement followed by a week of silence is a worse experience than an honest delay.

Items received outside working hours, which determines whether a coverage gap is theoretical or real.

Repeat contacts on one issue, which is the clearest signal of something unresolved.

Where it waits. Nearly always on somebody else — an internal answer, a supplier, an approval — which is a different problem from being understaffed.

Making it survive

Never lose a message. Persist and assign before any processing, so a failure delays rather than discards.

Make it idempotent on the message id, since mailbox APIs deliver duplicates.

Handle the mailbox being unavailable by retrying rather than skipping.

Keep mail in the mailbox as well as in whatever system you route into, since people will look there.

Report the outcome: messages received, categorised, routed, drafted, and anything unassigned or ageing.

Limits worth knowing about

Mailbox access is sensitive, and the scope of what an automation reads should be an explicit decision people know about.

Threading is unreliable across clients, which all handle it slightly differently.

Categorisation on short messages is weak, and much of a mailbox is short messages.

Attachments are their own problem, frequently carrying the actual content.

Automation cannot fix an under-resourced queue, it makes the shortfall visible and better ordered.

What to build first

Assignment with visible state and ageing: every message owned by a named person, with a state beyond read and unread, and anything old surfaced. It sends nothing and drafts nothing, and it addresses the failure that actually costs — an item nobody owned, which is how things go missing in a shared mailbox.

Two habits make the difference. Assign to an individual rather than a team, since a team assignment reproduces exactly the ambiguity that makes shared mailboxes fail. And draft rather than send, because a draft captures most of the time saving with none of the risk of a commitment nobody intended to make.

Frequently asked questions

Why treat a shared mailbox as a queue?

Because it is one, without the tooling — no ownership per item, no state beyond read and unread, no ageing visibility and no measurement. Folders are a filing system rather than a workflow.

What actually goes wrong in a shared mailbox?

Items handled twice, items handled by nobody, long threads lost among newer messages, anything awaiting a reply disappearing, and coverage gaps during leave. Most of these are discovered when somebody escalates from outside.

What should triage produce?

A category, an urgency derived from content rather than the sender's assertion, a named owner, attached context, a duplicate check, and a visible state — which is the thing a mailbox fundamentally lacks.

Should replies be sent automatically?

Draft rather than send. A draft captures most of the time saving with none of the risk, particularly around commitments — a date or a price in an auto-sent reply is a promise somebody may hold you to.

What makes a draft actually useful?

Basing it on your own previous replies so it carries your tone and real policies, citing the source so the sender can check, leaving gaps visibly marked rather than inventing details, and making it one click to send.

What should never be auto-sent?

Anything containing a commitment, anything to an upset customer, anything legal or regulated, anything responding to a complaint, and a first reply to a new relationship. Honest acknowledgements are the exception.

Why is threading difficult?

Clients handle it inconsistently, forwards break attribution since the forwarder is not the person with the question, quoted history skews categorisation, and somebody replying to an old thread for a new reason is common and commonly mishandled.

Can this fix a backlog?

No. It makes the shortfall visible and better ordered, which is valuable and is not the same as capacity. An under-resourced queue stays under-resourced.

What should I measure once a mailbox is instrumented?

Volume by category, time to first response as a distribution rather than a median, time to resolution separately, out-of-hours volume, repeat contacts on one issue, and where items wait — which is usually on somebody else rather than on capacity.

Why measure first response and resolution separately?

Because a fast acknowledgement followed by a week of silence is a worse experience than an honest delay, and a single response-time figure reports the first as a success.

Should automated senders go through triage?

No — filter them before it. Notifications, delivery receipts and system mail are a large share of any shared mailbox, and routing them wastes both triage capacity and somebody's attention.

What happens to out-of-office replies?

They should close a loop rather than create a new item. Treated as incoming mail they generate an item per recipient per absence, which is a meaningful share of the noise in a busy mailbox.

Related reading

• Automating form data routing
• Automating follow-up emails
• Connecting SendGrid to HubSpot