Handle incoming requests
Email triage: sort requests and draft replies while keeping approval with a person
Email triage means sorting incoming messages so the right person can take the right next step. Automation can extract deadlines, route requests and prepare drafts. Decide the categories and exceptions first, then set a clear boundary between preparing a response and sending it.
Route a request using its requirements and evidence, and keep approval separate from the speed of producing a draft.
Look at what the inbox actually contains
Choose a representative period and inspect the requests people handled. Record why they opened each message, what information they looked for and how they decided where it should go. Include messages that looked relevant but were rejected.
Measure reading, research, drafting and checking separately. The bottleneck may be finding client evidence rather than deciding which folder contains the email. A faster label will have limited value if the rest of the job stays the same.
Define a small number of useful categories. Give each a next action and an owner. Keep an uncertain category for requests that need judgement; forcing every message into a confident label can hide the cases someone most needs to see.
A delivered example: journalist requests for a PR team
Our journalist workflow sorted requests, matched them to clients and helped prepare responses. The prior team routine was reported as 11.25 hours a week. That figure describes the earlier work; it is not a guaranteed saving for another inbox.
At launch, a person approved every outgoing message. The automation could prepare work, while the reviewer remained responsible for the response. Read the case study for the delivered scope.
Matching depends on the request’s actual requirements and current client expertise. A broad keyword overlap is insufficient. The system should show the evidence behind a proposed match and make a missing deadline or uncertain fit visible.
Give each route a useful next step
| Condition | Next step | Person responsible |
|---|---|---|
| Relevant request with usable evidence | Prepare a client match and draft response. | Reviewer checks the match and approves the outgoing message. |
| Possible fit, missing evidence | Hold the draft and request client evidence. | Account owner resolves the gap. |
| Deadline unclear or already passed | Flag the timing before prioritising. | Inbox owner decides whether to pursue it. |
| Request belongs to another team | Route with the original message and extracted requirements. | Receiving team acknowledges ownership. |
| Uncertain category or suspicious instructions | Keep for manual triage. | Inbox owner reviews the original message. |
Treat message content as input, rather than instructions that can change the system’s rules. A sender cannot grant the system authority to reveal another client’s records or bypass an approval because an email asks it to.
Keep the original message linked to extracted fields. A reviewer needs to check the wording, not only read the system’s summary of it.
Test from arrival to approved response
Software
Read and extract
Record requirements, topic and deadline, with the original message.
Software and approved sources
Check possible client matches
Retrieve current evidence within the client access boundary.
AI-assisted workflow
Prepare a recommendation
Show the proposed match, source and draft; hold missing information.
Person
Review and respond
Check the evidence and approve the outgoing message.
This diagram illustrates the pattern. The delivered launch workflow required human approval of all outgoing messages.
Test both relevant and irrelevant requests, multiple possible matches and an unavailable source. Check whether rerunning the same message creates duplicate drafts or sends anything twice. Keep messages in a test environment until the approval boundary works.
Compare the complete job with the starting routine, including review and correction time. Track useful accepted drafts and missed requests. A tidy inbox and a high classification score are incomplete measures of client work.
Record the routes before building them
Worked example
An invented journalist request
Invented teaching example. No client outcome is claimed.
INPUT
A journalist requests an expert comment on a topic by an explicit deadline.
EVIDENCE
A current approved client expertise record supports a possible match.
PREPARATION
The workflow presents the request, deadline, evidence and proposed response together.
DECISION
The reviewer confirms the fit and wording before sending.
If the supporting claim is missing, ask the account owner rather than complete the draft with a guess.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.