On this page 12 sections
In most shared inboxes the better return is drafting and triage with a person sending, not an agent answering. It removes the lookup and the blank page while keeping the judgement, and it needs no confidence gate because nothing reaches a customer unread. The trap is the draft that is nearly right, which costs more to correct than an empty box costs to fill.
The question in a shared inbox is not whether AI can write the reply. It is whether the reply it writes is faster to fix than to write.
Key takeaways
- Automate triage before drafting. Routing and context retrieval pay back sooner and fail more safely.
- A draft that is 80 percent right is the expensive kind, because the errors are subtle enough to send.
- Facts in a draft must come from your systems, and anything unknown must be marked rather than filled in.
- Measure time to send and how often the draft was deleted, not how many drafts were generated.
- Assistive drafting suits high-value, low-volume inboxes where an autonomous agent does not.
Who this applies to
You have a shared mailbox handled by people - sales, operations, accounts, a service desk - and the volume is high enough to be a job but the messages matter enough that nobody wants a bot replying.
Two adjacent questions live elsewhere. Whether an autonomous customer-facing assistant makes sense is build or buy AI customer support. Getting outbound email delivered at all is cold email deliverability. This is the middle case: a machine drafts, a person sends.
Four jobs, and only one is writing
An inbox contains four separable jobs, and teams usually try to automate the third one first.
Triage. Category, priority, which queue, whether it is a duplicate of an open thread, whether an agreed response time is at risk. Cheap, safe, and it improves the day even when no draft is ever generated.
Retrieval. Pulling the order, the account, the contract clause, the previous thread. Most of the time a person spends on a reply is finding things, not typing.
Drafting. Producing the text.
Sending. The part to leave alone in almost every inbox of this kind.
Automating triage and retrieval first is a smaller project with a faster payback and a much smaller failure surface. Do that, measure, and then decide whether drafting is worth adding.
The 80 percent draft problem
Draft quality does not pay off linearly, and it is worth being explicit about why.
An obviously wrong draft is cheap. The person reads a line, deletes it, writes the reply themselves. Time lost: a few seconds.
A clearly right draft is cheap. Read, adjust a word, send.
A nearly right draft is expensive. It is well written, the tone is correct, and one figure is wrong or one commitment was invented. Checking it properly takes longer than writing the reply would have, and if the reader is busy, the error goes out over their name.
This is why “the drafts are pretty good” is not a success criterion. The interesting question is what happens on the messages where the system is confidently wrong about a detail, and the answer has to come from the system’s design rather than the reader’s diligence.
Two design rules follow. Every fact in a draft comes from a system read, never from the model’s memory of similar messages. And anything the system does not know is marked in the draft as a gap for the person to fill, not smoothed over with plausible wording.
What makes a draft usable
The facts are pulled, not recalled. Order numbers, dates, balances and entitlements come from a lookup. If the lookup fails, the draft says so.
No new commitments. A draft may state a policy that exists. It may not invent a delivery date, a discount, a deadline or an exception. This is a hard rule in code rather than an instruction in the prompt, for the reasons in guardrails: what to check going in and coming out.
Right length for the channel. A three-paragraph reply to a one-line question reads as automated and takes longer to trim than to write.
House voice, and consistently. This is the one thing in the whole list where fine-tuning on real past replies genuinely earns its place, and the reasoning for when it does is in fine-tuning, retrieval or a better prompt.
Visible provenance. The person should be able to see which sources the draft used, so checking it takes seconds rather than a search.
Triage is the underrated half
The measurable wins in these projects are usually here rather than in the writing.
Routing to the right person the first time removes a whole handling step. Thread and duplicate detection stops two people answering the same customer. Priority and response-time risk turns an undifferentiated queue into an ordered one. Detecting that a message is a reply to something already resolved prevents a reopened conversation being treated as new.
None of these produce anything a customer sees, which is why they get skipped in favour of drafting, and why they are the safer place to start. Validate them against what people actually did with the last three months of mail rather than against how the categories were supposed to work.
What to measure
Draft acceptance rate is the metric vendors report and it is close to meaningless, because a person under time pressure accepts things.
Three that mean something:
Time to send, per message. The whole point. Measure it before you start, or you will not be able to claim anything afterwards.
Deleted-draft rate. How often the person cleared the draft and wrote their own. This is the honest quality signal and it is uncomfortable, which is why it needs to be in the report by default.
Corrections that changed a fact. Distinguish edits that changed the wording from edits that changed a number or a commitment. The second kind is a near miss and each one should be a case in the evaluation set, built the way an eval set from real tickets describes.
Where it must not send by itself
Anything that commits money, sets an expectation you cannot control, or goes to a person already unhappy. Complaints, cancellations, legal or regulatory correspondence, and anything about an incident. A reply to a formal complaint has to be written by somebody willing to own it, and the automation’s job there is assembling the history.
What we build, and what we advise against
Triage and retrieval first, then drafting for the categories where the answer is a lookup. Sending stays with people in this shape of inbox, and we say that even when the brief asks for autonomy, because the two things a shared inbox usually protects are a relationship and a commitment, and both are exactly what an autonomous system is worst at.
The recommendation that costs us the larger engagement: if the inbox is low volume and high value - twenty enquiries a day, each worth thousands - the honest answer is retrieval and templates, not a project. The gain from drafting is a few minutes per message, and the risk of a confidently wrong figure in front of a client of that size is not proportionate. We would rather scope the small version.
Where we have been wrong: we have measured these systems on drafts produced rather than on time to send, which flattered them. The first client who tracked the deleted-draft rate found it far higher than the acceptance rate implied, and the difference was one category the system should never have been drafting for. Now the deleted-draft rate is in the report from week one.
When this is not worth it
Very low volume. Under a few dozen messages a day, saved replies and a good template library get most of the benefit for none of the cost.
When every reply is genuinely bespoke. If two replies in a hundred resemble each other, there is nothing to learn from and the draft will always be a starting point nobody wants.
When the content is not written down. If the answers live in people’s heads, drafting will invent them. That is a documentation project first, and no amount of model quality substitutes.
Frequently asked questions
Should the draft be visible to the customer as machine-written?
If a person reads, edits and sends it, it is their reply and it is theirs to own. Disclosure matters when the system is the one replying, not when it is the one typing.
Where should the draft appear?
Inside the tool people already use. A separate interface adds a context switch that consumes most of the time saved, and it is the most common reason these systems go unused.
Will it make replies sound the same?
Yes, if trained on the team’s best replies, which is often an improvement. Keep an easy way to discard and write freely, because uniformity is a benefit in operations and a liability in a relationship.
Can it learn from the edits people make?
It can, and it should be a deliberate periodic step rather than a live loop. Uncontrolled learning from edits is how a system drifts with nobody able to say when it changed.
Does this work for an inbox in several languages?
Drafting, yes. The constraint is the same one as everywhere else: only offer what your team can support when it goes wrong, because an escalation nobody can read is worse than no draft at all.
Next step
If your team spends more time finding things than writing them, triage and retrieval are a shorter project than a drafting assistant and usually the larger saving. Email automation starts by measuring where the time in the inbox actually goes.
Related: Build or buy AI customer support · Cold email deliverability · Guardrails: what to check going in and coming out · Building an eval set from real tickets · Email automation