By the end of this lesson
- Write a problem brief that does not assume AI, then revise its scope using new information.
- Compare process, conventional software and AI options, including the problem each addresses and the work each adds.
- Define checkable success and stop criteria, leaving clear tasks and limits for the next lesson.
Before you begin
- Bring the workflow, facts, assumptions and missing-information list from Lesson 3.
- Read the twenty introductory Beichen records and, separately, the new summary in the Lesson 4 progressive scenario. Keep the material sets distinct.
- Write what 'better efficiency' might mean: faster response, less waiting or less rework?
Read the Beichen case and introductory data
Move from a feature request to the work that needs improvement
'Build an AI knowledge assistant to improve efficiency' names a solution and a broad goal without locating the difficulty. Use the previous lesson's workflow to choose a delay supported by the material. Identify the user, trigger, task, current difficulty and consequence, then state which possible causes remain unconfirmed.
A drafting prompt is: 'When this group encounters this task, they need to do this step. The material shows this difficulty, but these causes remain possible. This round will test this question and exclude these actions.' Use the prompt to clarify your meaning, not as a rigid formula. GOV.UK's discovery guidance also reframes proposed solutions as problems; its government phases and schedules are not enterprise requirements.
Problem definitions remain revisable. This lesson establishes a starting point for design, not an irreversible commitment. New evidence about permissions, risk or value can justify narrower scope, a non-AI approach or stopping in any later lesson.
Use new information to change the judgment, not just the wording
The Lesson 4 progressive Beichen scenario supplies a new summary: among incidents with waits longer than 30 minutes in a three-month ticket analysis, most waiting occurs in specialist confirmation and parts approval. This is separately supplied scenario information, not a conclusion calculated from the twenty introductory JSON records. It gives no complete underlying records, exact share or statistical method, so do not invent percentages.
Attach the summary to the previous assumptions. It weakens 'document lookup is the main problem' and increases the need to inspect confirmation and approval. A parts draft might help prepare information, but that does not establish faster approval. Distinguish preparation before submission, waiting after submission and handling after approval. If authority or resources are the constraint, improving answers alone may have limited effect.
Compare genuinely different approaches
Connect each option to a possible cause. A full version, a simplified version and a delayed version differ mainly in scope or timing; they do not offer fundamentally different approaches. Consider the status quo, changes to work arrangements, conventional software or rules, and model assistance. Do not assume AI is best or that a non-AI approach needs no maintenance or validation. Ask which approach acts most directly on the established difficulty.
The comparison below is a teaching analysis, not a validated investment recommendation for Beichen. A real project must check authority, implementation cost, reversibility and workload. A combination may be appropriate, but separate the purpose and checks for each change so that doing many things at once does not obscure which helped.
| Approach | May directly address | Costs and limits to check |
|---|---|---|
| Keep the current workflow and investigate | Avoiding premature change when causes are unclear | Consequences of continued waiting and research deadline |
| Change schedules, escalation or authority | Waiting for specialists or finding a decision-maker | Authority to change the process and support capacity |
| Search, forms or rules-based software | Locating records or missing request fields | Version maintenance, permissions and exceptions |
| AI recommendations and drafts | Understanding unstructured material or preparing drafts | Applicable evidence, review and maintenance effort |
| A staged combination | Several distinct, established difficulties | Separate checks, dependencies and benefit estimates |
Define the baseline before comparing numbers
A baseline is the situation before a change, recorded using an agreed method. Define task eligibility, timestamp boundaries, sources, missing-value treatment and calculations before computing means or rates. Fast first response does not mean fast resolution. First response, specialist waiting and total resolution are different fields. A before-and-after pilot comparison also needs comparable task conditions.
For an introductory JSON calculation, the twenty resolution_min values total 1,753 minutes, giving a mean of 87.65 minutes. Twelve records have expert_wait_min greater than zero: 12/20, or 60%. Six have rework set to true: 6/20, or 30%. These describe only the synthetic practice records. They are not real Beichen business results and establish neither AI savings nor annual benefits.
The 60% does not mean that 60% of time is spent waiting for specialists: its denominator is events, not minutes. The records also contain no post-assistant comparison. If an exercise proposes a 30% reduction, that is an unconfirmed target. Multiplying 87.65 by 0.7 yields an illustrative 61.355 minutes, not an achieved result or a sufficient criterion for production use.
Explain how the system might affect work and outcomes
Observe success as several distinct steps: the system supplies applicable guidance, engineers consult it on eligible tasks, it helps complete an action, waiting or rework improves, and business outcomes change. Each connection is an assumption. Evidence for the first does not establish the last. Faster drafting may leave total resolution unchanged if approval is still the constraint.
Pair each main success criterion with a check for side effects. Alongside waiting, inspect review time, rework and correct escalation. Alongside adoption, inspect uncritical acceptance and later corrections. Compare tasks, equipment, shifts or experience groups so an average does not hide rare serious problems. GOV.UK's benefits guidance helps distinguish a baseline, predicted benefits and observed outcomes; it does not supply thresholds for your project.
Write stop conditions as actions that can be carried out
Success criteria explain when continuing is worthwhile; stop conditions explain when to pause, narrow scope or use the existing human process. State the trigger, affected scope, immediate action, owner and evidence required to resume. 'Review if accuracy is low' is too vague. Nor does every problem require stopping everything: the response must fit the consequence, authority and established operating procedure.
A teaching example is: if a recommendation contains an automatic equipment action prohibited by the initial scope, stop the affected recommendation path and notify the operations owner; inspect its reach and the correction, then require authorized confirmation before resuming. This is not equipment-operation guidance. Site safety remains governed by the customer's existing procedures. Out-of-scope data access or unavailable review also needs an explicit response.
An unknown state means that an action or outcome cannot currently be confirmed. Do not count it as success or failure merely to complete a metric. Define its measurement and decision treatment now; the next lesson designs its display, verification and human takeover. Human takeover requires someone with the information, authority and time to continue the task, not just a label in a diagram.
Build a one-page problem and decision brief
Continue the Beichen thread to see how evidence becomes a recommendation. 'Build a knowledge assistant for efficiency' does not locate waiting. Combining the previous alternatives with the new summary gives a draft: first establish where delays occur during specialist confirmation and parts approval for East China day-shift tasks; compare process changes with recommendation and drafting assistance; exclude automatic shutdown, request submission and customer incident conclusions. This is an exercise proposal, not an approved decision.
Add what the material suggests, what remains to check and what to do first. You might propose examining preparation, confirmation and approval periods in an authorized set of events, then comparing options with business and operations owners. If causes remain indistinguishable, do not claim that an AI pilot already has sufficient value. Paper-based validation or a process change can remain reasonable options.
Put criteria on the same page: eligible tasks, measurement, errors and added work, stop conditions and who confirms the next action. If the customer wants to retain 'AI assistant' as the project name, discuss the name separately; it must not substitute for actual scope. Ask relevant people to explain this round's tasks and exclusions. That reveals disagreement more effectively than an agreement in principle.
Check whether the problem is really defined
Replacing 'efficiency' with 'AI-enabled efficiency' does not make the problem specific. Removing adjectives while assuming universal use does not change scope either. Check whether evidence has changed the target task, preserved alternatives or removed an unsupported requirement. More changes are not automatically better: retaining the original scope is reasonable when supported and explained.
Another mistake is choosing a threshold and then selecting easy tasks to pass it. Agree scope and measurement first, then set criteria with owners using consequences, the baseline and available resources. A sample percentage is not an industry-wide rule. Preserve unfavorable results and earlier records when revising. This gives design a usable starting point: whom the solution serves and which conditions it must meet.
Practice the method
Use the introductory records for calculations and the progressive scenario for revising the problem. Do not combine them into supposed real pilot results.
- 01
Draft a problem brief without assuming AI. Cite two items from Lesson 3 and at least one unconfirmed cause.
- 02
Check the mean resolution time of 87.65 minutes, 12/20 events with specialist waits and 6/20 with rework. State each denominator and scope.
- 03
Add the three-month summary from the Lesson 4 scenario and revise scope. Identify it as separate material and note the exact figures it does not supply.
- 04
Compare a process change, conventional software and AI assistance. State the step affected, people needed and work added by each.
- 05
Write two success criteria, two side-effect checks and three stop conditions. Mark unsupported thresholds for agreement rather than declaring them approved.
- 06
Produce a one-page recommendation. Keep the first version and reason for revision, then state Lesson 5's task, data, permission and excluded actions.
Locate the waits in a workflow
Compare lookup, specialist and approval waits across 20 records, then define the problem and identify what still needs checking.
Specialist waits and resolution times match the introductory JSON. The added segments are constructed extensions, not recovered business observations.
Read the field guide, work through the calculation or walkthrough, then check the guide's review notes. Open the downloaded files in a spreadsheet or text editor; no code is required.
Check your understanding
Write your answer before opening the explanation, then check what you might have missed.
Do 12/20 events with specialist waits mean 60% of resolution time is waiting?
No. The denominator is event count. It describes how many synthetic records contain specialist waiting, not the share of time spent waiting.
Does faster parts-request drafting establish faster approval?
No. Preparation, waiting after submission and approval are different steps to examine separately. Improving one may leave total resolution unchanged.
Can you still recommend a non-AI approach after entering Lesson 5?
Yes. New information at any stage can change the problem, scope or reason to continue. Preserve the evidence and seek renewed authorization rather than keeping a plan simply because design has begun.
Your record and next step
A problem brief, a non-AI alternative, and success and stop criteria.
Define each metric and name who checks it. Even if average speed improves, inspect errors, rework and added burden on particular groups. A small practice sample cannot establish real-world benefits.
Lesson 5 turns the problem brief into a human–AI workflow. Bring eligible tasks, success and stop criteria, permissions and support requirements. Keep unconfirmed thresholds and causes explicitly pending.