The Hidden Cost of Gathering Context at Work

Before someone answers a customer, they often have to reconstruct the situation. They find the account, open an order, search old messages, and check which promise still applies. Measure that work separately from writing the answer. It can reveal a better first investment than an AI tool that only drafts the reply.

Define when the context is ready

Consider an illustrative delivery enquiry: a customer asks why an order hasn't arrived and whether they can cancel it. The service representative needs the correct customer and order, the latest delivery event, the promise the sales team made, and the cancellation rule that applies to that order. They may need several systems to establish those facts.

Call the context ready when the representative has enough verified information to decide the next step. Record which facts they need and where each fact comes from. Finding an order number alone doesn't meet that definition if the delivery event or agreed terms still need checking. Record a missing fact as a gap, rather than treating a plausible answer as a completed search.

This problem appears in current customer-service discussions. In a September 2026 discussion, a contributor describes staff piecing together support history, account records, and feedback while a customer waits. That is an example of the question people ask, not a measure of how common the problem is. Your own case records establish its scale.

Separate searching, checking, and waiting

Use a simple activity log for each observed case. Record the start and end of each active interval, the system or colleague involved, and the reason for that step. Label the work consistently so you can see which parts repeat.

1. Find and read: locate the account, retrieve a record, search a message thread, or read the material needed for the case.
2. Resolve conflicts: compare two delivery dates, determine which contract applies, or check whether an old promise still governs the order.
3. Ask a colleague: explain the question, request a missing fact, and read their response. Record the colleague's active time separately if you can observe it.
4. Decide, write, and check: choose the response, draft it, verify its claims, and complete the case. Keep this work separate from gathering context.

Track waiting on another clock. Six minutes waiting for a warehouse answer isn't six minutes of active work if the representative handles another case during that interval. It still delays the customer's answer. Report active labour, elapsed time, and any extra staff effort separately; overlapping intervals mustn't inflate the total.

Switching also has costs that a stopwatch may miss. In their 2008 laboratory study of interrupted work, Gloria Mark, Daniela Gudith, and Ulrich Klocke found that participants completed the simulated email work faster under interruption but reported more stress and effort. Most participants were university students, so this isn't a universal workplace estimate. It is a reason to ask staff about the effort behind a fast result, alongside measuring time and errors.

Observe a sample of normal work

Choose a manageable first sample, such as thirty delivery enquiries over a week. This is a starting point for finding patterns, not a statistical guarantee. Include routine cases, missing records, and disputed promises. Observe busy and quieter periods, and include staff with different levels of experience.

Tell staff that you're studying the process and the information it requires. Ask them to work normally and explain uncertain steps after the case, so your questions don't create interruptions that you then count as process overhead. Store case references and timings in the measurement record; keep customer details in the authorised source systems.

Compare the observation with the event history. A ticket open for forty minutes may contain five minutes of work and a long wait. A short ticket may hide a colleague's ten-minute search. Screen activity alone also won't tell you whether someone reads the right contract or repeats a failed search. Combine timings with a brief account of what they needed and whether they found it.

Review the log with an experienced representative and the process owner. Agree how you classify a step that combines reading and checking, and mark uncertain estimates. Report averages and longer cases, with their counts, by enquiry type. If you combine groups, weight their averages by volume; multiplying a median by total cases won't estimate total labour reliably.

Calculate the time the process consumes

The figures below are an illustrative calculation, not a client result. Assume a team handles 400 comparable delivery enquiries each week. In the example baseline, gathering context takes an average of 7.5 active minutes per enquiry, and deciding, writing, and checking takes another 2.5 minutes.

At that assumed volume, context gathering consumes 400 × 7.5 ÷ 60 = 50 representative-hours a week. After the example change, context gathering takes 3.5 minutes, but checking the reply takes an extra half-minute. The total falls by 3.5 minutes per enquiry, or 23 hours and 20 minutes a week. Claiming the full four-minute context reduction would ignore that extra review.

Add colleague time and any rework before treating this as the team's result. Check whether the same mix of cases achieves an acceptable answer in each period. To express the labour cost, multiply observed hours by the relevant loaded hourly rate. That values the effort the process consumes; a reduction in that value doesn't establish a reduction in payroll.

Keep the denominator visible. Fewer incoming enquiries, a changed case mix, or leaving hard cases unresolved can all improve the average without improving the process. For a fuller comparison, use the method in Build a Baseline Before Claiming AI Saved Money.

Match the fix to the cause

A log that says “opened five systems” describes the symptom. Ask what made each visit necessary. The repair depends on whether the information exists, whether staff can reach it, and whether the business agrees on what it means.

If staff repeatedly search by a customer's trading name because systems use different identifiers, fix the account mapping and provide a link to the right record. If delivery status exists but the service team can't see it, give the relevant role a supported, authorised view. A concise case screen with current records may remove more work than a generated summary.

If the sales team leaves special terms in individual inboxes, change where they record approved promises. If two systems give different delivery dates, name the source and owner that govern a customer commitment. Putting both dates into a longer AI prompt won't settle that business rule. Track the unresolved conflict and ask its owner to decide.

If staff already have the facts but need an approver, measure that handoff and clarify the decision authority. Faster search may leave the queue unchanged. Rank repairs by the repeated minutes and errors they address, their implementation cost, and the owner who will maintain them. The data-readiness guide covers missing records and conflicting definitions in more detail.

Give an AI context pack a narrow job

AI may help when staff need to find relevant passages in long messages or documents and assemble them for a specific enquiry. Start with a read-only context pack: customer and order identifiers, relevant source extracts, timestamps, links, and a clear list of missing or conflicting facts. Keep the final customer response with the representative during the trial.

Use direct system queries for structured facts such as the latest delivery event. Use document retrieval for agreed terms or earlier conversations. Attach the customer and order identifiers to both paths so a similar name or another customer's contract can't silently enter the pack. Carry the user's access rights into retrieval before information reaches the model.

A summary can sound convincing while omitting the fact that changes the answer. AWS's current RAG evaluation guidance separates context relevance and coverage from answer correctness, faithfulness, and citation measures. In practice, check whether the pack retrieves the required evidence, whether its statements agree with that evidence, and whether each cited passage supports the claim beside it.

Test changed delivery events, revoked access, an expired promise, and a missing record. The pack should show the gap or conflict and its source; it mustn't invent an approval or promise a refund. Record how long the representative spends verifying the pack. If they reopen every system to trust it, the trial hasn't yet removed the context-gathering work.

Check the whole case after the change

Use comparable enquiries and the same activity labels after a repair. Check completed answers against their source records, including the cases that need a colleague or a manual fallback. Count incorrect account matches, missing terms, and unsupported promises explicitly. Review reopened cases after a suitable interval rather than declaring success when the first reply goes out.

Compare experienced staff with newer staff separately. An experienced representative may already know where to look, while a newer colleague may need more time to interpret what they find. Erik Brynjolfsson, Danielle Li, and Lindsey Raymond's 2025 study of a customer-support AI assistant reports different productivity effects across worker experience and skill. That study evaluates a particular deployment, so it doesn't predict the effect of your context pack.

Watch for work moving elsewhere. A tidier screen may rely on an analyst manually preparing its data every morning. An AI pack may shorten the first search but increase correction time. Record those costs and support effort alongside the representative's time. Expand the change only when the evidence supports the whole workflow at acceptable quality.

Bring the evidence to management

Give management a short record of the enquiry types, observed case count, active context time, elapsed delays, and answer quality. Include examples of the longest searches and the fact staff struggled to establish. Recommend the first repair with a named business owner, a technical owner where needed, and a date for checking the result.

For a venture investor, ask whether a product reduces the customer's total investigation work or mainly produces a faster draft. Request a demonstration that includes retrieving the evidence and checking the answer. For a private equity team, compare this process within each portfolio company before multiplying a result across different systems and operating rules.

A small company can start with shared record links and clear ownership of promises. A larger organisation may need account mapping and access across several systems before a context pack can work. Choose the repair that addresses the observed obstacle, then rerun the cases. The next investment should follow the evidence about what still consumes time.