Chapter 1
The Demand Arrives
At 8.31 on Tuesday morning, Maya's phone lit up.
The board will expect a sense of direction. Questions are fine, but we need to show we are not standing still.
Tom wanted options.
By then, Maya had received suggestions from almost every member of the executive team. Finance proposed invoice matching. Sales wanted the tender tool restored. Marketing wanted access to a paid writing assistant. Daniel had booked two vendor demonstrations for Thursday afternoon.
Leila sent no new use cases. She sent the two service-credit procedures.
One was dated 11 June 2025, fourteen months earlier, and stored in the customer-service knowledge base. The other had been approved six months later, on 11 December 2025, and attached to an email. Both looked current. Neither contained a clear supersession notice.
Maya understood the concern. The company could not spend months studying every possibility while employees found their own tools and providers introduced features by default. Delay was not neutral.
But the long list of ideas concealed a more immediate fact: people were already using AI under different assumptions, and nobody had agreed what counted as authorised use.
She called Daniel.
“Can you cancel the demonstrations?”
“I can,” he said. “I don’t think we should.”
“Why?”
“Because the board wants movement, and we need to learn what the products can do. A demonstration doesn’t commit us to anything.”
“What will we ask them to demonstrate?”
There was a pause.
“Service support. Tender review. Internal knowledge.”
“Those are three different problems.”
“They are also three common products. We don’t need a finished business case before we look.”
Daniel was right about one thing. Seeing a product could help the team understand what was possible. The risk was allowing the product to define the problem. A polished demonstration could turn an undefined demand into a preferred solution before anyone had agreed what success meant.
“Keep one session,” Maya said. “Ask them to use a fictional scenario. No company or customer data. Tell them we are examining the service-credit problem, not shopping for an enterprise platform.”
“That will make the meeting very narrow. The provider has one opening this month, and procurement needs a price range before the budget meeting. If we cancel the wider session, we may lose both.”
Maya considered that. “Keep the opening. Ask for a price range separately, but make the demonstration about the service-credit problem. We will learn less about their platform and more about whether they can work with our evidence.”
“Tom may still call that slow.”
“Then the paper needs to explain the trade.”
Record why the request arrived now
An AI request is rarely only a request for technology. It carries a history.
The chair may fear that competitors are moving faster. A manager may need to reduce a queue. Employees may already be using tools because the approved process is slow. A vendor may be encouraging adoption before a renewal. A customer may be asking for assurance. An executive may have publicly promised savings.
These pressures explain why the demand has arrived now and what may distort the decision. They belong in the record.
If a sponsor has already promised a result, evidence that challenges the proposal may be unwelcome. If a team is exhausted, it may accept risks it would otherwise question. If a customer has asked for assurance, the organisation may feel tempted to describe intentions as existing controls.
The first task is to preserve the request before organisational language tidies it up.
Write down what was said as closely as you can. “We need an AI strategy” is different from “customers wait four days for a response” and different again from “reduce service cost by fifteen per cent”. Each statement carries an assumption that should remain visible.
Do not convert the request into a solution brief yet.
One request can carry five different pressures
FIG-1.1
Separate the pressures
Board pressure
Defensible investment or direction
Existing use
Immediate boundaries
Customer assurance
Evidence the organisation can support
Service failure
An outcome to diagnose
Vendor pressure
A problem defined before product selection
Write the first useful note
At 4.10 on Monday 10 August, before sending the note described in the Prologue, Maya drew five headings on a blank page. She gave herself twenty minutes. Several answers were still missing. She recorded who would find them rather than filling the space with a confident guess.
What is being requested in the original words
Tom’s words: “We need to get ahead of this. What’s our AI strategy?”
What should improve and who owns it
Direction and assurance for the board. Maya owns this first record. Service and tender baselines: unknown. Leila and the sales director to clarify their intended outcomes by Friday 14 August.
What is already happening
Sales reports a tender trial and a caught error. Other use: unknown. Daniel to bring an initial list and supporting records by Friday 14 August.
What needs an immediate boundary
No new customer tender uploads while handling is checked; Daniel applies the pause. No live data in demonstrations. No customer-facing service pilot yet. Maya reviews the first restrictions on Friday.
What is the next decision by whom and when
Tom and the board on Friday 14 August: decide what to contain and whether to authorise diagnosis. Implementation spending is not requested.
At 4.30 she stopped editing. At 4.36 she sent the page to Tom. The unknowns had owners and dates. They were work to do, not defects to hide.
TOOL-1
Write the first useful note
Five questions first. Add supporting detail only where it is needed. Unknown is a valid answer: name who will resolve it and by when.
Layer 1 stays short. Layer 2 holds the records and questions that a particular demand needs. By Friday, Maya could update the first page and attach the supporting detail below. She had not known all of it on Monday.
Read the Friday first pass
What is being requested in the original words
“We need to get ahead of this. What’s our AI strategy?” Tom Avery, chair. First recorded Monday 10 August 2026; updated Friday 14 August.
What should improve and who owns it
Tom needs an investment direction and a truthful assurance response. Maya owns the record. Leila owns the service outcome; the sales director owns tender work. Baselines remain unknown: each owner reports by Friday 28 August.
What is already happening
Tender use and a caught contract-reference error are evidenced in the saved trial history and review copy. Leila holds two conflicting procedures. Four of seven reported tools have evidence-backed entries; three reports and AI features in two existing systems remain unchecked.
What needs an immediate boundary
No new tender uploads to the trial; Daniel enforces the restriction. Demonstrations use fictional data. No customer-facing service pilot or experimental record changes. Maya decides exceptions after the required checks; reviews are dated in Layer 2.
What is the next decision by whom and when
Friday 14 August: Tom and the board decide on bounded diagnosis and interim controls. Requested end date: Friday 28 August. Combined ceiling: twelve staff-days and AUD 5,000 external advice. No implementation approval is requested.
Keep the supporting detail behind it
Layer 2 for this demand follows. These are fictional case records, included to demonstrate the method. A real note would link to the organisation’s access-controlled originals.
Record pressures and measures
Tom needs capital-allocation options and an honest customer response. Sales needs a route for next week’s tender. Leila needs fewer repeat contacts and reversals. No measured productivity or cash saving is yet established. The opportunity remains open while the exposure is contained.
Identify people and correction
Priya and other service advisers who would use, review and correct output under existing workload targets.
The customer who spent forty minutes obtaining correction of a service-credit decision, and customers in comparable cases.
Customers whose tenders, service records or communications may be processed.
Managers accountable for service quality, cost and correction.
Voice, correction and escalation during diagnosis:
Priya will represent frontline evidence in the service workflow session.
Existing complaints, reversals and repeat-contact records will be reviewed as provisional customer evidence.
Leila owns correction of live service records during diagnosis and escalation of any material customer impact to Maya.
Direct customer participation will be considered after the first case review; if it is not used, the reason will be recorded.
Name challenge and specialist input
Nadia Bell, head of internal assurance, will test whether evidence supports the proposed next step before either diagnosis closes.
Nadia does not own the expected service benefit, sales target or technical delivery. She will record any conflict that emerges.
The initial screen has identified customer confidentiality, provider handling, uncertain information content and contractual obligations in the tender trial. Daniel will obtain security and privacy review, and the commercial counsel will review the relevant customer and provider terms, before Maya decides whether any tender use may resume.
Record each boundary
Tender trial pause. No new customer tenders may be uploaded. Daniel owns enforcement; Maya may vary or lift the pause after provider terms, settings, retention, deletion and customer confidentiality obligations are checked. The sales director may request an exception in writing, but cannot approve it. Review: Friday, 14 August 2026.
Demonstration data. No live company or customer information may be used. Daniel owns enforcement and may stop the session. Any exception requires Maya’s prior approval after information classification and provider handling are checked. Review: after the Thursday demonstration.
Customer-service pilot hold. No customer-facing pilot may begin until the service-credit workflow, current sources, correction route and outcome owner are confirmed. Leila owns the hold; Maya approves any move to experiment after independent challenge. Review: Friday, 28 August 2026.
The board retains authority to approve the experiment budget and scope. Maya may implement that approval within its conditions; she cannot authorise an additional experiment or spending overrun herself. This distinction also applies when she varies a temporary boundary.
Attach sources to known facts
Board paper and assurance response due Friday. Source: Monday executive meeting record and the customer’s dated questionnaire, held by Maya. Checked against the originals on Friday 14 August.
Tender tool used and an incorrect reference caught. Source: saved trial history, uploaded tender and marked review copy, compared by Daniel on Thursday 13 August. Establishes this recorded incident, not the overall error rate.
Two service-credit procedures conflict. Source: knowledge-base article dated 11 June 2025 and approved email attachment dated 11 December 2025, held and compared by Leila on Tuesday 11 August.
A reversal is not explained in the live contact history. Source: the service-credit record inspected by Leila with Priya on Wednesday 12 August. The credit entry exists; the reason for reversal is absent.
Keep reports assumptions and unknowns distinct
Reported saving: sales says the trial saved hours; source is the sales director’s account. Baseline not measured. Working assumption: faster replies reduce total service cost; finance must test review and repeat-contact work. Permission and handling for resumed tender use remain unresolved despite the check of the retained document set.
By Friday, the original “no personal information” report has become a checked statement about the retained trial set only. Other tools remain outside that check. Daniel owns the remaining tool and feature checks for Friday 21 August. Leila and the sales director own their baselines and alternatives for Friday 28 August. Maya records which matters remain open at each decision.
The proposal asks for diagnoses within twelve staff-days and AUD 5,000 for external advice. Their conclusions must distinguish closing the request, repairing prerequisites and proposing a bounded comparison. This note is not an approved AI strategy or a complete inventory.
In a small organisation, one person may hold several of these responsibilities. Keep the responsibilities separate on the page even when the names repeat. Where the decision could materially affect a person, a contract, safety or confidential information, find a challenger outside the proposed benefit and obtain specialist advice where needed.
Keep evidence in its proper place
FIG-1.2
Keep evidence in its proper place
| Evidence class | Example and source |
|---|---|
| Verified fact | Conflicting procedures | Source: Leila’s knowledge-base copy dated 11 June 2025 and approved email attachment dated 11 December 2025. |
| Reported information | Hours saved | Source: sales director’s account; no measured baseline yet. |
| Assumption | Faster replies reduce total cost | Source: finance’s working proposition; test checking and repeat-contact work. |
| Unanswered question | Other enabled AI features | Source: Daniel’s discovery list; checks in two systems still outstanding. |
One request, several demands
On Tuesday afternoon, Maya met with Tom.
He read the first-pass Demand Note in silence. Maya kept the supporting records beside it.
“This is useful,” he said, “but it still doesn’t tell the board where we should invest.”
“We don’t have enough evidence to recommend an investment.”
“Then what do we have?”
“A customer assurance problem, an existing-use problem and at least one operational problem. They need different responses.”
Tom turned back to the first page.
“The board asked for a strategy.”
“The words were ‘What’s our AI strategy?’ I recorded them exactly.”
“You know what I meant.”
“I may have misunderstood part of it,” Maya said. “I heard a request for an investment direction. The notes suggest a customer-assurance issue, uncontrolled adoption and a service problem as well. Which of those does the board need resolved first?”
“Capital allocation,” Tom said. “And confidence that unmanaged use is not growing while we deliberate. I need to explain why we are reserving money or why we are not.”
“Then I can give you a bounded discovery request and the controls we need now. The investment options will follow the evidence.”
Tom tapped the table with his pen.
“What can the board approve?”
“A short diagnosis. Immediate boundaries. Named owners. We can return with options supported by evidence.”
“How long?”
“Two weeks for the first two demands.”
“Why two?”
“Because that is enough time to map one service problem and verify the tender trial without pretending we have completed an enterprise review.”
“And the budget?”
“Reserve a small discovery amount. Do not approve implementation money yet.”
“Give me a page I can defend,” he said eventually. “No governance essay.”
Name the owner of the outcome
A sponsor can create urgency and provide authority. That does not make the sponsor the owner of every outcome.
If the proposed use concerns customer service, the owner should understand the service process and be accountable for what improves or worsens. Technology can operate the system and own its technical components. Leila remains accountable for service quality and customer consequences. Risk, privacy and security specialists challenge the proposed approach within their expertise.
Benefits also need owners.
“Save time” is not an owned outcome. Whose time? How much? What will happen with it? Will customers receive faster service, will the team handle more work, or will the organisation reduce cost? Each answer changes the baseline and the people who should participate.
Maya asked Leila to own the diagnosis of the service-credit problem.
Leila hesitated.
“If I own it, finance will expect a saving.”
“Finance can test the economics. You own whether the service outcome improves.”
“What outcome?”
They agreed on two initial measures: the number of contacts required to resolve a service-credit request and the rate at which employees reversed an earlier answer because they found a different procedure.
Neither measure mentioned AI.
That mattered. If cleaning the procedures solved most of the problem, the diagnosis needed to make that visible.
See who lives with the result
The people affected by a consequential AI use extend beyond its sponsor and users. In this case, customers could receive the wrong answer while advisers inherited the work of checking and correcting it.
The first-pass note need not contain a complete impact assessment. Where the request raises consequences for people, use Layer 2 to identify who may experience them and how they can raise a problem during diagnosis.
Leila asked Priya, one of the senior service advisers, to join the first workflow session. Priya had handled the customer whose service credit was initially declined.
“The old procedure wasn’t the only problem,” Priya said. “The account screen shows the date but not the reason for the last decision. I thought another adviser had already checked eligibility.”
“Would an assistant have helped?” Maya asked.
“If it showed me the current rule and the earlier adviser’s reasoning, yes. If it wrote a confident reply without either, no.”
The distinction changed the proposed work. The team had begun with “an assistant for repetitive enquiries”. It now had a narrower question about current rules and decision memory.
Priya also asked who would correct the customer record if an AI-assisted answer was wrong. Leila checked the earlier case. The credit had been applied, but the original refusal remained in the contact history without a note explaining the reversal. A future adviser could still interpret it as a valid decision.
Leila assigned herself responsibility for correcting live service records during the diagnosis. Maya added the voice, correction and escalation details to Layer 2 of the Demand Note.
Establish provisional boundaries
Diagnosis can take time. Existing exposure may require action before the diagnosis is complete.
Provisional boundaries are temporary rules that prevent a demand or experiment from expanding while the organisation establishes what is happening. They should be narrow enough to enforce and short enough to review.
For this case, three boundaries mattered most: keep customer documents out of the unapproved tender tool; use fictional data in the demonstration; and prevent experimental systems from contacting customers or changing records. The supporting prompts are in Appendix A.
A boundary is not an enduring policy merely because it is sensible. Record its owner, reason and review date. Explain how employees can ask for an exception or report an existing use without being punished for surfacing it.
FIG-1.4
Make a boundary usable
Boundary and reason
No new customer tenders in the unapproved trial; provider handling and obligations remain unresolved.
Owner and enforcer
Daniel applies and checks the restriction.
Request and approval
Sales director may request an exception; Maya decides after the relevant checks.
Review and lifting
Review on Friday 14 August 2026. Record evidence, decision and any continuing restriction.
Maya wanted employees to tell Daniel what they were already using. She made clear that reporting an existing use would not itself attract a penalty. Deliberate misuse would still be handled through the company’s ordinary processes.
In this invented case, Daniel checked the saved trial history against the uploaded documents. He and the commercial counsel found no personal information in that retained set, but the documents contained customer commercial information subject to confidentiality terms. The provider’s written reply showed different deletion schedules for the account and service logs. Daniel recorded the scope of the check; it did not establish what employees might have entered into other tools.
The company had not approved this use or confirmed that the provider terms and customer confidentiality obligations permitted it.
Daniel disabled the trial account after preserving the available history and obtaining confirmation of the provider’s deletion process. The sales director objected.
“You’re shutting down the only real example we have,” he said. “We have another tender next week. The team will lose the time saving, and the board will see a closed account instead of progress.”
“I’ll put that cost in the paper,” Maya said. “I’ll also put in the customer obligation we had not checked. Bring me the baseline and we can test another route.”
Decide whether diagnosis is deserved
Routine use within an existing approval does not need a new project. This triage is for proposed consequential uses outside that approval, or uncertain current use that needs clarification.
First check current or uncertain exposure on every route, even if you intend to decline the proposal. Containment can remain necessary after the proposal ends. Then ask:
1. Is there a real outcome, failure or opportunity to examine?
2. Is someone accountable for that outcome?
3. Is there a credible initial map of affected people and a plan to find indirect or missing groups, including people who may struggle to raise concerns?
4. Does the underlying problem deserve examination independently of AI?
5. Is it worth comparing process repair, existing software, deterministic automation and AI?
6. Can the organisation establish safe boundaries, time limits and meaningful independent challenge for diagnosis?
Run an initial specialist screen before authorising diagnosis where the proposed use may affect rights, employment, safety, essential services, vulnerable people, personal information, security, contractual obligations or regulated decisions. Seek advice proportionate to the context; do not wait for a polished evidence pack if an immediate restriction may be needed.
For demands entering this gate, the result should be one of three first decisions. Necessary containment remains active whichever decision is made.
Decline
The request has no clear outcome, owner or strategic reason to continue. Record why it was declined and what would need to change before it could return.
Contain and clarify
Existing use or provider functionality creates exposure, but the underlying demand is not ready for diagnosis. Establish boundaries, identify ownership and collect the missing facts.
Diagnose
A real problem or opportunity exists, an owner is named and a short examination can produce a useful decision. Approve the scope, time limit and evidence required.
At this stage, “diagnose” is not approval to buy, build or pilot.
The first decision gate
FIG-1.3
Check exposure on every route
1. Check existing or uncertain exposure
Always do this. If present, contain and assign an owner. Carry this action forward even if the request is declined.
2. Check the proposed outcome
No worthwhile outcome: decline the proposal, retaining any containment. Otherwise continue.
3. Check ownership and boundaries
Missing owner, affected-person map or usable boundary: contain and clarify.
4. Check whether diagnosis can help
Compare simpler options within an effort ceiling. Narrow, clarify or decline a scope that cannot produce a useful decision.
5. Check proportionate challenge
Obtain independent and specialist input where required. If conditions are met, authorise bounded diagnosis only.
What the board received
On Friday morning, Maya replaced the requested AI strategy with a paper titled:
AI Demand: First Decisions
The paper contained three recommendations.
First, the board would approve provisional boundaries for unapproved or uncertain AI use. Approved routine use could continue within its existing information and audience limits. A new purpose or data category required review of the relevant provider terms, settings and obligations. Customer communications or record changes required an approved workflow with verification, correction and monitoring. A named person had to be able to pause it.
Second, the company would run two diagnoses ending Friday, 28 August. Leila would own the service-credit problem and return with a current-work baseline, source conflicts, customer consequences and process-repair options. The sales director would own a review of tender-analysis work, including baseline time, types of error, document obligations and non-AI alternatives. The two-week limit belonged to this case; future work would be sized by scope, consequence, evidence access and participation needs.
Third, Daniel would maintain a provisional register. He had checked four of seven reported tools against account or configuration records and recorded each approved purpose or unresolved permission. Three tool reports and AI features in two existing systems remained unchecked. Those two counts were separate: reports of tools and checks inside established systems. Each outstanding check had Daniel as owner and Friday 21 August as its next review date.
The paper included no enterprise platform purchase and no headcount-saving target. The two diagnoses shared a ceiling of twelve staff-days and AUD 5,000 for external specialist advice. Maya could move effort between the two diagnoses but could not approve an overrun. Any additional discovery spending, experiment or implementation required a separate board decision.
Tom presented it to the board.
The first question came from a non-executive director.
“Are we being too cautious?”
Tom looked towards Maya.
“A customer document went into a trial before we reviewed the provider terms,” she said. “The service assistant would also draw from two procedures that give different answers. I cannot recommend expanding either use until we resolve those facts.”
The chief financial officer asked when the board would receive numbers.
“After we establish a baseline and identify where the work goes,” Maya said. “If time moves from advisers to reviewers, we will show that. If a process repair creates most of the benefit, we will show that too.”
The board approved the boundaries and the service-credit diagnosis. It authorised the tender review only far enough to establish the document obligations, baseline and alternatives; any new trial would return for approval. One director dissented, arguing that the company should run a low-cost productivity pilot immediately. The request for an enterprise AI investment returned to the agenda without a decision.
Nadia read the assurance response before it left. “Four entries supported by records is not a verified inventory,” she said. The response stated exactly what Daniel had checked, listed the three unverified reports and the two systems awaiting feature checks, and described the interim restrictions actually applied. It made no claim to a complete AI management system.
The tender trial remained closed.
Leila left the meeting with responsibility for a problem she genuinely owned and no promise that AI would solve it. Priya had a place in the diagnosis. Finance had to wait for a number it could defend.
After the meeting, Leila opened the two service-credit procedures beside the earlier customer record. The later procedure looked clearer, but it still did not explain who could approve an exception or what an adviser should record after reversing a decision. Her two-week clock had begun.
Create your AI Demand Note
Use the five-question first pass in Appendix A for a consequential demand needing a new decision. Preserve the original words. Allow unknowns, but assign each an owner and a date.
Add Layer 2 only for the questions the first pass exposes. Keep the decision page short and the supporting evidence accessible. Do not finish with “explore AI opportunities”. Name the next decision and who can make it.
Chapter 2 follows Leila’s diagnosis. It asks whether the conflicting procedures explain the customer’s experience or hide a deeper failure in recording and correcting decisions.