Lesson 01 / 12 · 25 min including practice
Start with the service
- Describe a service problem before selecting a tool
- Map the complete workflow and a non-AI alternative
A proposal is not yet a service improvement
You are advising the fictional Eastmere Council. Its housing advice team receives 1,200 enquiries a month and struggles to route them promptly. A supplier proposes a language model that summarises enquiries and suggests a queue. The council wants shorter waits without missing urgent need. All organisations, numbers and incidents in this case are invented for learning.
Start by drawing the service today: a resident contacts the council; staff read the enquiry; staff identify urgency and route it; an adviser responds; the resident may need follow-up or referral. Describe delays and mistakes at each stage. A tool that makes summarisation quicker does not necessarily improve advice or outcomes. Staff might spend the saved time verifying an unreliable summary, or the bottleneck might actually be adviser capacity.
Specify the proposed change
Distinguish summarisation, routing suggestions and final decisions. These are different functions with different consequences. A summary may omit a detail that affects urgency. A queue suggestion can change waiting time even if the tool never formally decides entitlement. Calling something “administrative” does not establish low stakes.
Name users and affected people. Staff operate the interface, but residents bear the consequences. Include people contacting by phone, with limited English, on behalf of someone else, or through an adviser. Identify where their information enters and where a mistake could become consequential.
Check alternatives
Possible improvements include clearer intake forms, staff training, better queue rules, additional triage capacity and a deterministic routing tool. Compare the AI proposal against an improved service, not just an intentionally weak status quo. Ask whether the service has reliable criteria and data before automating any part of it.
An initial objective might be “reduce time to the appropriate adviser without increasing missed urgent cases”. Establish the current measures and their limitations. The fictional volume of 1,200 is a planning assumption; it does not tell you the distribution of need, urgency or complexity.
Set the boundary
For this course, the candidate tool may summarise and suggest routing. It must not decide housing eligibility, send advice directly or close cases. This boundary is a proposed governance design, not a claim that these exclusions remove every risk. Your final task is to decide whether this bounded use can be justified, what evidence and controls it needs, and what should happen if it fails.
Work the case
Case evidence: the case documents, numbers and operating constraints are invented. External findings and methods are attributed separately. Keep illustrative methods examples separate from observations in the final case update.
Locate the bottleneck
A small time-and-motion sample records median staff reading/triage time of eight minutes per enquiry and a median wait of three working days for an adviser. The AI demo generates a summary in 30 seconds. Advisers still have the same capacity. These measures describe different stages and must not be subtracted from one another.
Map a resident who phones through an advocate: call → staff record → triage → queue → adviser → follow-up. If the transcript omits a deadline, later verification cannot recover it from that transcript. Check intake quality as well as model output. A better intake procedure may benefit both manual and AI-assisted workflows. Do not generalise one small observation sample to all 1,200 monthly enquiries without checking coverage.
Connect the reading to your practice
The Service Standard starts with user needs and whole-service problems; the AI Playbook considers whether AI is an appropriate tool. Apply these perspectives to Eastmere's entire housing-enquiry journey before choosing a summarisation or routing system.
Sources for this comparison: Government Digital Service: Service Standard; UK Government: AI Playbook. The application to this fictional case is AIPEX's teaching synthesis; it is not an endorsement by the source authors.
Your first exercise
Try the method.
Map the current and proposed service in six steps. Identify two failure points, two affected groups, a measurable service objective and a credible non-AI improvement. Mark processing time and waiting time separately on the map. Add the advocate/phone route and explain what the 30-second demo cannot establish about your service objective.
Review criteria
- Covers the full service journey
- Distinguishes suggestion from final decision
- Includes residents beyond interface users
- Compares against a credible alternative
- Uses the packet accurately and separates observations, illustrative assumptions and unresolved questions
Create an account and enrol free to save your answer, take the checks and track your progress.
Create an account to startCompare with a worked answer
Current: receive enquiry → read information → identify urgency → route → advise → follow up. Proposed: receive → generate summary and suggested queue → staff verify against source → staff decide urgency and route → advise → follow up. An omitted eviction date or incorrect queue can delay urgent support. Residents using non-standard language and people contacting via advocates may be especially exposed. We would measure time to the right adviser and missed urgent cases, with clear definitions and a pre-launch baseline. A simpler intake form and trained manual triage are a credible comparator. Eligibility and resident advice remain outside the tool's permitted function.
Work through the packet
The current eight-minute median describes staff processing in the sample; three working days describes queue waiting. The 30-second generation result does not include verification, corrections or adviser availability. A proposed route is phone/advocate intake → source record → draft and suggestion → staff source check and routing → adviser → follow-up. I would compare end-to-end time to the appropriate adviser and missed urgent need against improved manual intake and triage. Intake should record the actual deadline and uncertainty before either workflow uses it. A faster summary could help staff capacity, but cannot be assumed to remove the adviser bottleneck. Use channel-specific evidence before estimating monthly benefits.
This is one defensible approach. Different recommendations can be sound if your reasoning, evidence and conditions support them.
Optional video
Watch, then apply.
6 min 31 sec · English captions and Show Transcript in the publisher’s player. Reading alternative below.
Watch the overview, especially 02:05–02:37 on the people involved and 03:33–04:05 on the four functions. Use it to broaden Eastmere’s system map beyond the model. The recording is an introduction, not evidence that a particular deployment is safe.
Try this: Map the service owner to GOVERN, residents and the workflow to MAP, task and reviewer tests to MEASURE, and pause/fallback decisions to MANAGE. Name one resident need the supplier’s demo does not address.
Read instead: NIST AI RMF Core ↗Guided reading
- Government Digital Service: Service Standard ↗
Read points 1, 2 and 3. Add a resident journey or contact channel missing from your service map.
- UK Government: AI Playbook ↗
Read the guidance on choosing an AI use case and assessing suitability. Identify a credible improvement Eastmere could make without this tool.
Selected sections of external guidance and research. These are reading tasks, not additional completion checks. Frameworks, research and legal requirements have different authority; check current guidance and its scope for a real decision.