The Cost of Running Routine Requests Through Email Chains

Many workplaces treat email as the universal meeting point for routine requests. In practice, this creates a recurring pattern of friction: conversations drift across inboxes, handoffs become ambiguous, and important requests disappear into threads where context is buried under replies, forwards and changing subject lines. This is not merely an annoyance. It is a reproducible drain on throughput, a source of mistaken assumptions and a predictable driver of delays that ripple through teams, customers and suppliers.

Routine requests are the ones that should be easiest to handle: a new user account, a quote revision, a leave approval, a supplier detail change, a stock transfer, a refund. Because they are routine, nobody designs a process for them. They default to email, and email was built for correspondence, not for tracking work to completion.

Opening the operational pain

When requests begin in email, the person asking must repeatedly restate context, confirm ownership and chase confirmation. The operational symptoms are tangible: duplicated follow-ups, fragmented decision records and escalations that arrive late, just when a customer enquiry needs resolution. The cost of misalignment compounds as teams switch between apps, copy in more people and recreate the same information across several threads. The result is a work pattern in which time goes into documenting and re-documenting rather than moving work forward.

Microsoft's 2023 Work Trend Index gives a sense of the scale of communication overhead. Across Microsoft 365 usage it found people spending 57% of their time communicating, in meetings, email and chat, and 43% creating. The heaviest email users, the top quarter, spent 8.8 hours a week on email. In the same research, 62% of survey respondents said they struggle with too much time spent searching for information. Not all of that is routine-request handling, but routine requests carried by email add directly to it.

A worked example

Take a 35-person engineering services firm in Cape Town. Site managers request purchase orders by emailing the office administrator, copying the operations manager "for visibility". The administrator raises the order in the accounting system, emails the supplier and replies to the thread. When a supplier queries a price, that conversation starts a new thread that the site manager never sees.

A week later the site manager asks whether the material has been ordered. The administrator searches three threads, finds the supplier's query unanswered and discovers the operations manager had assumed someone else was dealing with it. Nobody did anything wrong. The request simply had no single place where its status lived. The same failure shows up in procurement requests that disappear into email.

Operational symptoms and evidence of cost

Delays in acknowledgement and task assignment as messages queue in inboxes rather than in a single, trackable workflow.
Missed or duplicated requests when ownership is unclear across email threads and chat channels alike.
Manual follow-up fatigue that reduces mental bandwidth for higher-value work.
Fragmented audit trails that hinder reporting, accountability and customer experience tracking.

Shared mailboxes do not solve the problem on their own. They make requests visible to more people but rarely make ownership clearer, a pattern explored in why shared inboxes become operational bottlenecks.

How to diagnose it

Pick one common request type and sample twenty recent examples. For each, note when the request was sent, when someone acknowledged it, when an owner was clear, when it was completed and how many emails were involved. Then ask:

How many requests needed a follow-up from the requester before anything happened?
How many involved more than one thread?
Could anyone other than the original handler have said what state the request was in?
How often did the request have to be re-explained because information was missing at the start?

If the answers point to chasing, re-explaining and invisible status, the cost is real even if it has never been measured. Chasing is a symptom in its own right, as described in why chasing people for updates is a systems failure.

Economic mechanisms and remediation

The financial consequence of email-chain processing appears in labour costs, rework and slower decisions. Each hour spent finding the right thread, re-reading an earlier message or restating requirements adds to personnel costs and reduces capacity for valuable work. Google's site reliability engineering book describes this kind of effort as toil: work that is manual, repetitive, automatable, reactive, without lasting value, and that grows in step with volume. Email-based request handling fits that description closely. Double the requests and you roughly double the chasing.

A practical remediation path combines structured intake, central task management and automation where appropriate:

a single point of assignment for requests;
a ticketing or work-management layer that preserves context;
explicit ownership with escalation rules.

These shifts reduce handoffs, stabilise throughput and create audit trails that support performance measurement.

Trade-offs

Moving requests out of email has a cost. People must learn a new habit, and a badly designed form can feel more bureaucratic than a quick email. External parties, such as customers and suppliers, will keep emailing regardless. The answer is usually not to ban email but to make it an entry point: an inbound message becomes a tracked item, and the conversation continues against that item. Start with the request types that are frequent, repetitive and frustrating, not with everything at once. Leave genuinely one-off or sensitive conversations in email, where a personal reply is the right tool.

What better looks like

Adopt a central intake channel for routine requests with clear service levels and owners.
Implement light automation to acknowledge receipt and route to the correct owner without recreating context.
Maintain a shared, searchable log of requests and decisions to reduce rework and improve reporting.
Train teams to convert inbound messages into actionable work items, using standard templates and checklists.
Track time to acknowledge, time to assign and time to resolve as leading indicators of process health.

Approval requests are a particularly costly variant, because the work cannot move until someone replies. The finance version of this is covered in the pain of invoice approvals in inboxes.

What to do first

List the five routine request types that generate the most email.
For the worst one, define the minimum information needed at the start, and turn it into a short form or template.
Name a single owner for that request type and a back-up.
Route submissions into one tracked list, whether a ticketing tool, a work-management board or a simple shared tracker, with a status column.
Send an automatic acknowledgement that includes a reference number.
After a month, compare acknowledgement and resolution times with your sample, then move to the next request type.

Bottom line

Replacing scattered email chains with a disciplined intake-and-workflow approach improves speed, accuracy and customer satisfaction. The economic meaning is straightforward: less labour leakage, fewer errors and faster throughput mean real savings and more capacity for growth. The path is practical and low-disruption if it is implemented as an incremental improvement to existing processes, not a wholesale rewrite of daily routines.

Sources and further reading

https://www.microsoft.com/en-us/worklab/work-trend-index/will-ai-fix-work (last verified 10 October 2026)
Google SRE - What is Toil in SRE: Understanding Its Impact (last verified 10 October 2026)