Run a mock customer project from first call to handover
Play the forward deployed engineer for a fictional clinic: discover, scope, prototype, test and hand over.
What you will have at the end
A discovery summary, a one-page spec, a prototype that reads messy letters, an acceptance test with results, a weekly update and a handover checklist. This is a full project you can walk through in an interview.
What you need
- Any chat AI tool
- A friend or a second chat window to play the customer
- A document or spreadsheet
All names, numbers and data in this lab are made up for practice. Never use real customer or personal data. Your ticks are saved in this browser.
The scenario
Maple Street Clinic is a small, fictional clinic. Staff spend hours each week reading referral letters from other doctors and typing the key details into a booking form.
You are the forward deployed engineer. The clinic manager, Ana, asked: can AI read these letters for us?
You will run the whole loop: find the real problem, agree what to build, prototype on real-looking letters, test, and hand over. A friend can play Ana, or you can ask a chat tool to play her using the persona below.
Starter material
Copy these into your own files or chat. Change anything you like.
Paste into a chat tool and say: play Ana. Answer only what I ask. Do not volunteer information.
You are Ana, the manager of Maple Street Clinic. You are busy, friendly and not technical. FACTS ABOUT YOUR WORK (reveal only when asked): - About 40 referral letters arrive each week, by email as pasted text or scanned PDF. - Two staff spend about 6 hours a week typing details into the booking form. - The form needs: patient name, date of birth, referring doctor, reason, urgency (routine/urgent), preferred days. - Mistakes happen when a letter is unclear. A wrong urgency can delay a patient. - You cannot share real patient data. You can share letters with names changed. - Your IT person, Dev, is cautious about data leaving the clinic. - You said "chatbot" at first, but what you really want is less typing and fewer mistakes. - Success to you: staff time on this task halved, and no missed urgent cases. - Must never happen: marking an urgent case as routine.
Eight fake letters. The names and details are invented.
1. Dear colleague, please see Mrs Rina Kapoor, DOB 12/03/1961, for knee pain, 3 months, getting worse. Routine is fine. She prefers Tues or Thurs. Dr. Shah 2. URGENT. Mr Omar Haddad (born 4 Sept 1975) has chest tightness on exertion since last week. Please see this week. Dr. L. Wei 3. Referral: Ben Ito, 09-09-2002. Ongoing headaches. Mornings are hard for him. Thanks, Dr. Mehta 4. Please see my patient, Priya N., about a skin rash that has not cleared with cream. No rush. Mondays suit her. Dr. Sol 5. Re: Mr Joseph Adebayo, DOB unknown, elderly, falls twice this month, daughter worried. Could be urgent? Dr. Park 6. Lena Fischer 21.01.1988 - follow-up on thyroid results, nothing new. Any weekday. Dr. Grant 7. Dear clinic, my patient (name on the attached scan) needs an opinion on back pain. Dr. Roy 8. Urgent?? Child, Aiden K., high fever 3 days, parents anxious. DOB 02/06/2019. Dr. Mehta
Fill in after discovery.
PROJECT: {{name}} SPONSOR: {{who}} USERS: {{who}}
PROBLEM (3 sentences): {{...}}
WHAT WE WILL BUILD: {{...}}
SUCCESS NUMBER: baseline {{...}} target {{...}} measured by {{...}}
IN SCOPE: {{...}} OUT OF SCOPE: {{...}}
DATA AND SYSTEMS: {{...}}
MUST NEVER HAPPEN: {{...}}
NEEDS A PERSON: {{...}}
TEST: {{set, who judges, pass mark}}
PILOT: {{who, how long, decision date}}A starting prompt for the prototype. You will improve it.
Read the referral letter below. Return JSON only with these fields:
patient_name, date_of_birth, referring_doctor, reason, urgency, preferred_days, needs_person.
Rules:
- urgency is "urgent" only if the letter says so or describes a danger sign. If unclear, use "unclear" and set needs_person to true.
- If a field is missing, use null. Never guess a date of birth.
- Do not add any text outside the JSON.
LETTER:
{{paste the letter}}The steps
Do them in order. Each step says how you know it is done.
- 1
Run discovery with Ana
- Interview Ana (a friend or the persona) for 20 minutes. Use the discovery questions from the course.
- Ask about the last time it happened, the costs, the data and the rules.
- Do not mention AI until you understand the work.
Done when: You have notes with at least five facts you did not know before the call.
- 2
Write the problem and the spec
- Write the problem in three sentences and read it back to Ana.
- Fill in the spec template, with a baseline and a target.
- List at least four out-of-scope items.
Done when: A one-page spec that names the must-never-happen rule: urgent marked as routine.
- 3
Build the prototype
- Use the extraction prompt on the eight letters, one at a time.
- Read every result. Fix the prompt where it guessed or missed.
- Add the unsure path: unclear urgency means a person decides.
Done when: The prototype handles all eight letters, and letters 5, 7 and 8 are sent to a person.
- 4
Agree the test with Ana
- Write the right answer for each letter.
- Write an acceptance agreement: pass mark, must-never-happen rule and who judges.
- Keep two letters hidden, to use only for the final check.
Done when: A signed-off acceptance page, even if only you and your friend signed it.
- 5
Test and study errors
- Run the six open letters, then the two hidden letters.
- Fill in an error review table: what happened, type, fix.
- Report the result to Ana in two plain sentences with real counts.
Done when: A results table and a two-sentence report that includes one failure.
- 6
Plan the integration and rollout
- List the systems: email, the booking form and where letters are stored. Give the least access each needs.
- Write how Dev's data concern is handled: masked samples, no real patient data in the prototype.
- Plan shadow mode, then assist mode, with a success number for each.
Done when: A systems map and a three-step rollout with numbers.
- 7
Write the weekly update and the handover
- Write the weekly update: done, next, results, risks, decisions needed.
- Write the handover checklist: how it works, how to fix common problems, who owns it.
- Write what you would tell your own team that you learned.
Done when: An update, a handover checklist and a three-line note for your team.
Success checklist
How to know the lab is really done
Show it in an interview
- Tell the story: what Ana first asked for, what she really needed and how you found out.
- Show the spec and the test table, and explain one failure honestly.
- Say how you handled the data concern and what you would do differently with real data.
Common mistakes
- Starting to build before you understand the work
- Promising perfect accuracy
- Testing only on the letters you used to improve the prompt
- Skipping the handover
Want a bigger challenge?
- Add more tricky letters and see which rules break.
- Record a five-minute demo for Ana in plain words.
- Write the security review answers Dev would ask for.
Next step: practice the interview questions for this role →
Other labs
A small agent that looks up orders and opens tickets, with checks, limits and a test set.
A researcher, a writer and a reviewer pass work to each other. You add limits and test the failures.
Score ideas, build a business case, list the risks and plan a pilot for Riverside Logistics.