The Work Beneath the Request

At 8.15 on Monday 17 August, Leila Morgan moved the service queue to one side of her screen and opened twenty completed service-credit cases. Priya had forty minutes before she was due back on the phones. The board had allowed two weeks for the diagnosis. Leila could already see how the investigation might consume the people it was meant to help.

They had taken the last twenty cases completed in July from the case register, rather than choosing memorable complaints. Each had a full seven-day follow-up window. Beside the register sat the contact history, the credit ledger and both versions of the procedure. The old article was dated 11 June 2025. The approved replacement had arrived by email on 11 December. Neither told an adviser what to do with the other.

“Shall we time how long it takes to find the rule?” Leila asked.

“First tell me what we’re trying to find,” Priya said.

She opened a case in which a credit had eventually been paid. The first adviser had declined it. The second had approved it. The ledger showed the money. The contact history still showed the original refusal, followed by a note saying only that the customer had called again.

Leila recognised the pattern from the case they had discussed the previous week. She had thought it was an untidy exception. Now another record was on the screen.

Priya put a finger against the second contact. “If this comes back to me, which decision am I meant to believe?”

The answer was not in either procedure. They could search faster and still arrive at an incomplete account of what the company had already done.

Follow the work through one complete case

They stopped the search timer. On a blank page, Priya wrote what had actually happened: request received, rule found, eligibility judged, refusal recorded, customer called again, different rule used, credit paid. Underneath, she added the missing step: explain the changed decision in the record that the next adviser would read.

The written procedure ended at the credit transaction. The customer’s experience did not. A later adviser could repeat the old refusal because the first decision remained easier to see than its correction. The company had completed a payment without completing its memory of the decision.

Leila asked whether they should delete the refusal. Priya shook her head. Then they would lose the reason for the customer’s second call. They needed a visible correction linked to the original entry, with the person, time, reason and applicable rule. History should show what changed, rather than pretend the first decision never happened.

They followed the next case from start to finish. This time both advisers used the current rule. The first recorded “outside policy”. The second found an exception that a supervisor had approved. Nothing on the first screen revealed that approval. The customer had to supply the fact that the company itself had failed to carry forward.

By the sixth case, Leila had crossed out “advisers cannot find procedures” as the diagnosis. She left it on the page, legible, and wrote underneath: “Some advisers cannot establish which decision is current or why.” The earlier wording mattered. It explained why a search assistant had seemed like the obvious solution.

Mapping the work begins with an instance, not an ideal flow. Follow the request until the person affected can rely on the outcome. Include the return visit, the handover and the correction. Ask which screen the next person actually opens. A process that ends when one team completes its task may leave another team, or the customer, to repair the join.

For each step, record the input used, the judgement made and the record left behind. Notice where someone supplies knowledge from memory. Then ask what happens when that person is away. Do not turn every informal workaround into a defect. Some are sensible responses to an incomplete system. Find what the workaround protects before removing it.

Priya’s handwritten sequence was enough for this decision. There was no need to model the whole service department. The boundary was service-credit requests and the information required to resolve them. When a case raised another problem, Leila recorded it for its owner instead of expanding the diagnosis without limit.

FIG-2.1

Follow the failure beneath the request

1. Visible conflict
   Two procedures appear current. Add an explicit supersession relationship.
2. Missing reason
   The next adviser cannot explain the decision. Record the reason and rule used.
3. Uncorrected history
   A credit changes but the refusal remains prominent. Link the authorised correction to the original record.
4. Residual search problem
   Now compare ways to locate the applicable clause in the repaired library.

Count the failure without pretending to know its cause

By 11.30, they had reconciled the twenty cases. There had been forty-eight contacts in total. Thirteen cases involved more than one contact. In ten of those thirteen, the reviewers found a missing reason or an unresolved procedure version that plausibly explained an avoidable return. They assigned one principal explanation per case: six to missing decision reasons, four to unresolved versions. Other contributing problems stayed in the notes.

Two of the twenty cases contained a reversal of the initial eligibility decision. A second contact was not automatically a reversal. One customer had called to check when an already approved credit would appear. Another had supplied information that had not been available at the first call. Leila would not label either a failed first decision merely to make the proposed repair look useful.

These were fictional company records, not research findings. The counts described this review set. They did not establish that ten cases would certainly have avoided a return if a field had existed. Someone might have entered an empty explanation in a mandatory box. A customer might still have wanted to speak to a person.

Priya kept a column for disagreement. Where the two reviewers could not reconstruct why the customer returned, they wrote “reason unclear”. They did not ask a language model to infer the missing reason and then treat the inference as history. A plausible reconstruction would have made the sheet tidier while making the evidence weaker.

At 2.20 that afternoon, Nadia read Leila’s proposed conclusion: “Most repeat contacts are caused by missing reasons and conflicting procedures.”

“You’ve found a likely mechanism,” she said. “You haven’t established the cause of most contacts.”

Leila pointed to the ten cases.

“Ten of thirteen in this set,” Nadia said. “And we should still test whether the repair changes what happens.”

The claim did not survive unchanged. Leila narrowed it to what the records supported and proposed a short observation of the repaired process. She had enough evidence to correct an obvious record defect under her existing authority. She did not yet have enough to promise the resulting saving.

A useful diagnosis separates three questions: what happened, what might explain it, and what changes when the suspected condition is repaired. Record-based observation can answer the first. It can suggest the second. The third needs further observation, and sometimes a comparison designed to distinguish competing explanations. The degree of investigation should match the decision being made.

For this repair, the team did not need to prove that every repeat contact had the same cause. They needed to establish that the procedure conflict was real, that the correction record was incomplete, and that the proposed fix would not erase legitimate exceptions. The saving would be measured rather than used as permission to fix a known defect.

Make the baseline answer the question

The twenty cases gave the team a mechanism to examine. They needed a wider record for the financial and service baseline. On Tuesday 18 August at 9.10, finance brought the July extract. It contained 1,200 service-credit requests and 2,880 linked contacts within the agreed observation window. The average was 2.4 contacts per request. There were 132 recorded reversals of the initial eligibility decision, or 11 per cent.

The observation window was seven days after the initial recorded resolution. A request was counted once, even if it had several contacts. A reversal meant an eligibility decision changed after that initial decision; it did not include a customer supplying a genuinely new request. The extract was a reconstruction of the July cohort with follow-up complete, not a simple count of everything that entered the contact centre during July.

Finance had previously used a different number. It divided all service contacts by tickets closed in the same month. That mixed requests that started earlier with requests still open at month end. The old measure remained useful for workload planning, but it could not tell them how often one request returned. They kept it, renamed it, and stopped comparing the two ratios as if they were the same.

Leila sampled the links between request IDs, contact records and credit entries. Priya checked cases where an adviser had opened a new ticket for the same problem. Finance retained the reconciliation and the exclusions. They could now reproduce the denominator instead of relying on a dashboard label.

The time estimate was less firm. The available activity records suggested around twelve minutes of adviser handling per contact, including the recorded after-call work. A practical planning range was eleven to thirteen minutes. The team had not measured every interruption or every supervisor consultation. They recorded those limits beside the estimate.

At the central estimate, 2,880 contacts multiplied by twelve minutes gave 34,560 minutes, or 576 adviser hours for the monthly cohort. The lower and upper time assumptions gave 528 to 624 hours. Those were handling estimates, not a claim that the company could remove that many paid hours from its roster.

The CFO asked which figure would appear in the board paper.

“All three,” Leila said. “The middle one explains the calculation. The range tells you how much we know.”

He agreed, then asked for the source and the repeat-contact definition to remain attached. He did not want the apparent precision of 576 to travel into next year’s budget without its assumptions.

Choose a baseline that could change the decision. Contacts per request helped this team see whether work returned. Reversal rate showed one kind of correction. Handling time helped estimate capacity. None of them alone measured whether customers understood the outcome, whether an initially wrong decision went unchallenged, or whether advisers could maintain the process under pressure.

Keep those gaps visible. A low reversal rate can mean better first decisions, but a case review is still needed to understand what the number represents here. If customers stop challenging an outcome, the recorded reversal rate could fall without service improving. The team therefore kept a small review of completed cases and invited customer evidence instead of declaring the metric self-explanatory.

Avoid making the baseline larger than the decision. Leila did not commission a company-wide time study. She asked finance to preserve the extract, define the measures and follow the repaired workflow. The unanswered questions had owners. The diagnosis still had an end date.

Preserve the cases that do not fit

Finance found requests that could not be reconciled cleanly because two tickets appeared to concern the same event. Those records were investigated before the July cohort was finalised. The reconciliation file retained the link decisions and their reasons, so a later analyst could challenge them without rebuilding the whole extract.

Leila also kept a separate list of unresolved requests outside the completed-case review. A measure built only from finished work could otherwise make a growing unresolved queue disappear. That list was not added to the denominator of a completed-case ratio. It was shown beside the ratio, with the oldest unresolved request and its owner available for follow-up.

The board did not need every line of this working file. It did need to know that the twenty reviewed cases were not the entire service, that requests could be mislinked, and that unfinished work was still being watched. These qualifications could change the interpretation of the result. They were therefore part of the decision, rather than detail removed to make the paper shorter.

For another organisation, the appropriate observation window might be longer than seven days. The team chose it here to make the initial comparison feasible and consistent. It left later returns as an explicit blind spot. Leila assigned continued review of those returns to her service reporting routine. If later contacts changed the picture, the baseline and the claimed improvement would both be revised.

Repair what already has an owner

At 10.40 on Tuesday, Leila approved three changes within her existing service authority. The old procedure acquired a prominent supersession notice linking to the approved version. The current procedure acquired an effective date, an owner and a record of what it replaced. Changing a service-credit decision now required a reason and a link to the earlier decision in the contact record.

These changes were made in the existing knowledge base and case system. There was no new model and no new external data transfer. Daniel checked the configuration with Priya before it was enabled. A corrected decision remained visible at the top of the case, while the original entry stayed available in its history.

The reason field accepted a short explanation. It also allowed “awaiting supervisor decision” with a named owner, so an adviser would not invent a reason merely to get past the screen. An unresolved item could not be displayed as a final approval. Leila remained accountable for the procedure library, and assigned a service supervisor time to maintain this portion of it.

Priya tried the repaired screen with the case they had opened on Monday. She could see the refusal, the correction, the current rule and the reason for the change without opening the credit ledger separately. She asked Daniel to move the correction above the free-text contact history. The first configuration had put it below several old notes, where an adviser in a hurry might still miss it.

“Now I can tell the next person what happened,” she said.

That was the immediate test. They were not asking whether the screen looked modern or whether the company had adopted AI. They were asking whether the next adviser could reconstruct the decision without requiring the customer to do it again.

The old cases were not silently rewritten. Leila set a queue for reviewing incomplete records when they resurfaced, and for identifying records that needed proactive correction. Priya flagged possible customer consequences separately. The small repair did not provide authority to change an earlier credit outcome without checking the case.

Process repair should not wait for the technology proposal when the repair is already justified and authorised. Equally, “ordinary process work” is not permission to make any change casually. Keep the owner, the reason and the effect visible. Here, recording a corrected decision was within Leila’s remit. Changing the eligibility rule itself would have required the rule owner’s decision.

The board would hear about the repair on 28 August. It did not have to approve a supersession notice before the service team could stop presenting two contradictory procedures as current. The distinction preserved both speed and accountability.

Leila explained the reason field to the advisers before the change reached their queue. It was there so the next person could reconstruct the decision, not so a supervisor could count words. Priya suggested reviewing a few explanations together rather than setting a minimum length. A short reference to an applicable exception could be more useful than a long account that never said why the decision changed.

They kept a way for advisers to report an unsuitable field or missing option. If the new screen forced people to misdescribe the work, that would be evidence against the configuration. The form was part of the repair and could itself need repair.

Hear what the measures leave out

On Wednesday 19 August at 12.15, Leila joined a short call with three customers who had agreed to discuss service-credit experiences. The invitation made clear that this was optional and would not affect an individual decision. The team offered a written response and a separate call for anyone who did not want to speak in a group.

They did not begin with a demonstration. Leila showed a plain explanation of a corrected decision, with names and account details replaced by fictional information. One participant read it twice. She could see that the refusal had changed, but not whether she had to call again to obtain the credit.

Priya added a sentence saying what would happen next and when the customer should contact the company if it did not. Another participant wanted a way to challenge the explanation without retelling the whole story. The existing reference number was not visible on the example. It was added beside the contact route.

The woman who had questioned the next step agreed to return for future discussions. Leila proposed a standing customer panel, with other participants rotating as different services were examined. It would meet again before wider service changes. Its membership and limits would be recorded. One cooperative customer, or three, could not speak for everyone who found the process difficult.

The panel’s early contribution concerned the human correction process. It said nothing about accepting an automated refusal, or about a system deciding eligibility without a person. Leila wrote that boundary in the meeting note. Much later, someone would be tempted to use “customers consulted” as a broader claim than this conversation supported.

Customer evidence was also gathered outside the panel. Complaints, corrected records and people who had abandoned a request might reveal different experiences. Leila asked the service team to note where the invitation method excluded people, including anyone unable to use the offered channels. They did not treat silence as agreement.

Use participation to improve a decision, not to decorate it. State which question people were asked and what changed because of their answer. If the same meeting is cited later, check whether the later decision is actually the one they discussed. The existence of a panel is not evidence that every proposed use has been understood or accepted.

Let the simpler change earn its result

At 3.30 on Thursday 27 August, Priya brought the follow-up sheet. The team had tracked the first 100 eligible service-credit requests initially resolved in the repaired workflow between 18 and 20 August. Each now had the same seven-day window used for the baseline. The set involved ordinary requests handled by the participating service group; unusual cases and other teams were listed as limits, not quietly counted as successes.

Those requests had generated 180 contacts, or 1.8 per request. Four initial eligibility decisions had been reversed. The source was the linked case and contact extract, reconciled to the correction record. Priya and finance had checked the classification of each reversal. None of the cases had used an AI retrieval feature.

The shift was large enough to matter and too early to call permanent. They had changed several things together: the procedure notices, the reason field and where corrections appeared. Staff also knew the workflow was being watched. The result supported continuing the repair. It did not isolate the contribution of each change or prove that the same rates would hold across the full service group.

Leila’s first draft said “AI readiness work reduces repeat contacts”. She deleted the first two words. The improvement belonged to the process repair. A later tool should have to improve on this new starting point, rather than inherit credit for a change completed before it was used.

At unchanged volume and twelve minutes per contact, 1.8 contacts across 1,200 requests implied 432 handling hours. That was 144 fewer than the old central estimate of 576. Using the eleven-to-thirteen-minute range gave 396 to 468 hours. These were volume-normalised projections from the early cohort, not hours already removed from payroll.

The reversal change from 11 per cent to 4 per cent was also provisional. The team would continue the same definition and review the cases behind the rate. If the mix changed, the comparison would be revisited. The CFO accepted the potential capacity gain but crossed out “saving” until the use of the released time was known.

The repair had removed the dominant failure mechanism found in the initial review and delivered a substantial early improvement without AI. The remaining technology question was correspondingly smaller. Nobody could now justify the original service-assistant proposal by pointing to all the old repeat work.

Keep the residual problem in view

The repaired process still had a slow part. During the observation period, Priya and another adviser logged clause searches across the much larger procedure library. The version conflict for service credits had been resolved, but customers described the same condition in different words. An adviser who knew the library could find the clause. Someone covering another product often needed help.

Priya showed Leila a case where the decision history was complete and the current rule was unambiguous. Finding the relevant exception had still taken several searches. A supervisor then located it using the library’s internal product term, a phrase the customer had never used.

This was a different problem from the one that had produced the repeat contacts. It was about locating applicable text, not deciding eligibility or repairing a record. The team did not claim a new baseline for search time from a few observed instances. They kept the examples and proposed to measure the residual task directly.

The demonstration Daniel had arranged on 13 August had shown a way to display a source clause beside an answer. Its limitations were now more useful than its sales promise. Leila wanted to compare a source-finding feature with the existing search, using the repaired library. A fluent customer reply was no longer part of the immediate question.

Write the residual problem after the repair, not before. Otherwise the proposed technology can continue solving the original presentation long after the organisation has discovered a different cause. A smaller problem may need a smaller product, or no new product at all.

Give each alternative the same problem

Leila wrote four routes against the remaining work. Process repair would continue: ownership, supersession and correction were necessary whichever technology they chose. Better use of the existing software might improve navigation and search. Deterministic automation could reject publication without required fields and direct known product codes to known clauses. AI retrieval might help when ordinary language and library terminology differed.

They did not score “AI” against “do nothing”. They compared each route against a defined task: help an adviser locate the applicable clause and its effective date, without changing the customer record or deciding eligibility. The routes could be combined. A required effective-date field was useful even if the retrieval feature never proceeded.

FIG-2.2

Compare routes against the diagnosed work

Route	Work it addresses	Limit to preserve
Process repair	Current procedures, decision reasons, visible corrections.	Does not remove every clause search.
Existing software	Navigation, saved searches and available features.	Existing ownership does not establish permission for a new use.
Deterministic automation	Require metadata; route known codes to known clauses.	Someone must maintain rules and exceptions.
AI retrieval	Find candidate clauses from varied wording.	Applicability and source checking remain necessary.

A simple route should not win merely because it is familiar. If deterministic rules required a growing list of exceptions that nobody could maintain, that burden belonged in the comparison. Equally, a new product should not win because its demonstration included more functions than the team needed. Compare the work required to maintain each answer, including what happens when the procedure changes.

The short comparison would use the same repaired source set, the same questions and the same definition of a useful result. Advisers would need to find and inspect the source, not simply obtain an answer. Cases where no applicable rule existed would remain in the set. A tool that always produced something should not receive credit for inventing certainty in those cases.

Take the tender owner seriously

At 11.00 on Thursday 27 August, the sales director put a separate sheet in front of Maya. It covered six completed tenders from before the trial. He had reconstructed requirement-mapping and checking time from work records and saved revisions. The six totals were eight, nine, ten, eleven, eleven and eleven hours: sixty hours altogether, an average of ten.

He excluded waiting for customer clarification and commercial negotiation, because the proposed assistance would not remove those activities. Three mapping defects appeared in the saved drafts: two omitted requirements and one incorrect clause link. Review had caught them before submission. They were defects per six reviewed tenders, not a claim that half of all future tenders would fail.

Nadia asked whether the time included checking. He showed the reconciliation. It did. That claim held. The earlier claim that the trial “saved hours” remained reported information: no comparable timed run existed for the trial, and the paused account was not reopened to manufacture one.

“I still think we should have another route,” he said. “But I can’t give you the saving yet.”

Maya had expected an argument about lost momentum. He had brought a better account of the work than the one in her first paper. He also wanted a clause check because he did not want a plausible summary to conceal an omitted obligation.

The tender diagnosis would proceed towards reviewed terms and an approved tool. It would not establish that the disabled original account could resume. Daniel and commercial counsel still had to determine which documents could be processed, where, for what purpose and under which retention conditions. The sales director accepted that boundary and asked for a decision date. Maya put 4 September against it.

Close the diagnosis with a decision

At 9.20 on Friday 28 August, Tom asked which of the two diagnoses should receive money. Maya began with what had already improved. The service repair was operating under Leila’s authority. Its early result justified continuing it and measuring it across the wider workflow. No AI purchase was required to keep that benefit.

She asked the board to authorise a bounded comparison of source retrieval against existing search. It would use the repaired procedure set and fictional questions, with no live customer contact or record changes. The board also allowed a focused demonstration of the configured option within that comparison. The vendor session of 13 August had already occurred; this permission did not retrospectively authorise it or create a second version of the same event.

The board allowed four staff-days and AUD 1,500 of external assistance for this comparison, ending Friday 11 September. These were new limits after diagnosis. They were not an extension silently absorbed into the original ceiling. The completed diagnoses had used ten and a half of the twelve authorised staff-days and AUD 3,800 of the AUD 5,000 advice allowance, according to the work log and invoices.

The dissenting director wanted an immediate service rollout. He was right that customers should not wait for a technology experiment to receive the record repair. Leila confirmed that they were not waiting. The retrieval question remained open because it would introduce a different dependency and had not yet shown a benefit over the repaired process.

Tender assistance received a route to a decision, not permission to restart. Reviewed customer and provider terms, a usable citation check and an accountable reviewer were the remaining conditions. Maya would decide within the board’s stated delegation once Daniel and counsel had supplied the evidence.

Tom asked what would happen if ordinary search won. “We use it,” Leila said. The answer finally sounded like a service decision.

Complete the Diagnosis Record

The worked record at the end of the paper fitted on a page. Its question was whether service-credit repeat work required an AI assistant. Its evidence was the twenty-case review, the reconciled July cohort and the hundred-request observation of the repaired workflow. Its conclusion separated the proven record defects from the provisional estimate of improvement.

The chosen route was to keep the repair and compare source retrieval only. Leila owned the service outcome; Daniel owned the technical comparison; Nadia would challenge the interpretation. The baseline remained 2.4 contacts and 11 per cent reversals in the July cohort. The early repaired-workflow observation was 1.8 contacts and 4 per cent reversals, with scope and follow-up limits attached.

The record named what remained unknown: search benefit over the repaired process, performance on less common products, and whether the early service improvement would persist. It named what could proceed now: current procedures, visible correction and the bounded comparison. Tender resumption remained conditional on the separate route decision.

Use Appendix B to make the same distinction in your own work. Record the original question, the observed failure, the sources and limits, the simpler change tried, what happened afterwards and the residual question. End with close, repair prerequisites or proceed to a bounded comparison. If the answer is to repair, name who can act now. A diagnosis has earned its time when it changes the work that follows.