Experience + handoffs
Make the next step easier to take
A patient-journey workshop your team can actually finish
A 45-minute team audit with an observation sheet and a practical repair brief.
Get the free workshop kitFree with your email · Guide, worksheets + editable text
For you + your team



+ working tools
- Watch one journey
Give a newcomer a neutral task.
- Record the evidence
Separate meaning, function and ownership.
- Finish one repair
Agree who will fix it and how to verify the change.
A PowerSURGE working kit for practice owners, front-desk leads and marketing teams
Help more interested visitors understand your practice and reach the right next step. This workshop follows one journey from a public invitation to the receiving team, then turns the first supported problem into a repair someone can finish. Use it when your team has plenty of opinions about the website but needs a clear decision.
A common example: the first-visit page explains the practice well, but “Book my visit” opens a callback form. The visitor wonders which time they selected, while the front desk thinks it received a request. You can fix the words and the handoff without rebuilding the website. The completed example below shows how.
It extends Run a practical marketing audit with your team. The Booking & Follow-Up Check is a useful starting check. This workshop goes further by separating what a visitor understands, what the technology does and what the receiving team can carry forward.
Set up a contained workshop
Plan a focused 45-minute working session. Bring a practice decision-maker, someone who receives enquiries and whoever owns the website or campaign. Invite a colleague unfamiliar with the specific page to attempt the task.
Choose one entrance: a real public post, search listing, ad or shared link. Choose one task: understand the first-visit process, find the correct office or request a time. “Audit our marketing” is too broad to observe.
Start with public pages and the team's response templates. For any live test, agree who will receive it and where to stop. Record the receiving side separately from the success screen: they answer different questions.
The agenda
| Minutes | Activity | Output |
|---|---|---|
| 0–5 | Agree the task and what can be tested | One task statement and test boundary |
| 5–15 | Observe the newcomer without coaching | Exact words, actions and hesitations |
| 15–25 | Compare public promise with actual process | Confirmed facts and unanswered questions |
| 25–35 | Inspect the receiving handoff or its current template | Separate front-end and receiving-side evidence |
| 35–45 | Choose one repair and assign verification | Named owner, reviewer and recheck |
If the problem needs longer investigation, leave with an investigation owner and the missing evidence. Do not manufacture a repair just to finish the agenda.
Give the newcomer a neutral task
Read this aloud:
“Imagine you are considering a first visit to this practice. Starting from this link, find what happens at the first visit and how you would arrange a time. Please describe what you are looking for and what you think each step means. You can stop whenever you would normally stop. Stop before submitting the form so we can review what you expect next.”
Do not say “Click the green booking button.” That tests obedience to instructions rather than whether the page explains itself. If the person asks for help, record the question before answering. A useful observation might be “They asked whether sending the form reserves a time,” rather than “They didn't like the design.”
Observe successful moments too. An accurate location card or clear practitioner introduction should survive the repair.
Record evidence before explanations
Use one row per observed event. Keep hypotheses in their own column.
| Step / public URL | Task or question | Exact observation | Possible explanation | Evidence still needed | Status |
|---|---|---|---|---|---|
Status choices: Clear / Needs work / Not checked. “Needs work” means you observed a specific problem. “Not checked” means you do not yet know. Neither is a diagnosis of the whole practice.
Examples of useful evidence:
- The exact button says “Confirm booking,” but the practice describes it as a callback request.
- The map opens the other office's address.
- On the tested phone, the keyboard covers the next control and the tester cannot reach it.
- The first-visit explanation is found and accurately understood without assistance.
- The form displays success; the receiving record has not been inspected.
Use exact public wording and team roles in the observation sheet. That gives the repair owner enough detail to reproduce the issue.
Inspect three different kinds of continuity
Meaning: does the person understand the next step?
Ask the newcomer to explain the practice, location, first-visit process and action in their own words. Compare with the real operating facts. A page can be attractive and technically functional while communicating the wrong expectation.
Function: does the action work in the observed conditions?
Record device, browser and date. Follow the exact link. Check the chosen task with touch and, where practical, keyboard navigation. Look for legible labels, clear focus, recoverable errors and a truthful success message. These are useful checks, not a claim of complete accessibility testing. W3C guidance explains form labels and clear submission feedback for your implementer.
Ownership: can the team continue the conversation?
Check whether the intended queue receives the request, whether someone owns it and whether a backup exists. Preserve the campaign topic so the next person can continue the conversation. A technically delivered enquiry can still wait without an owner.
Choose the right kind of repair
| Observation | First investigation | Avoid jumping straight to |
|---|---|---|
| Visitor does not understand the first appointment | Missing or conflicting practice facts | A discount |
| Button does not work on the tested device | Reproduce the technical failure | A headline rewrite |
| Correct request reaches an unattended inbox | Routing, ownership and coverage | More advertising |
| Person expects an immediate confirmed time | Button, form and success wording | Blaming lead quality |
| Person cannot find suitable availability | Actual capacity and arrangement process | A stronger urgency message |
Prioritise a misleading fact or a blocked action. Next address an unowned handoff. Then remove unnecessary effort. Aesthetic improvements can follow when the decision and action are intact.
The front desk should verify operational statements. The practitioner or appropriate reviewer should approve clinical explanations. The website owner should verify the change behaves as intended. Together, those checks connect the page to the real visit.
Completed illustrative example
Fictional teaching example. This is not a real practice audit or a claim of campaign results.
Meadow Practice invites visitors to “See your first visit, step by step.” The fictional observer finds a clear introduction and accurate office directions. The action says “Book my visit.” After opening the form, the observer asks, “Which time have I chosen?” No appointment selection exists. The approved operating description says the front desk receives a request and contacts the person to arrange a time.
Observation: The action label creates an expectation the process does not fulfil.
Hypothesis: Clear request wording could reduce this specific uncertainty.
Evidence: Exact button text, observer question and verified administrative process.
Next question: Do fewer people ask whether a time is already reserved after the change?
The team chooses a bounded repair: change the action to “Request an appointment”; add “Our team will contact you to arrange a time”; align the success message. Keep the clear introduction, directions and approved clinical copy intact.
Completed ownership map
| Work | Responsible role | Evidence needed |
|---|---|---|
| Confirm actual process | Front-desk lead | Written agreement that this is a request |
| Edit three affected messages | Website editor | Changed button, form introduction and success template |
| Recheck understanding | Workshop facilitator | New uncoached reading correctly distinguishes request from confirmed appointment |
| Check receiving side | Front-desk lead | Labelled fictional request visible in correct queue with owner |
| Remove test artefacts | System owner | Test record and queued messages handled under agreed plan |
The repair is complete when those checks pass. The team can then review whether the same practical question continues to recur.
Reusable repair contract
Journey: __________
Visitor's task: __________
Observed problem, quoted precisely: __________
Evidence location and date: __________
Confirmed operating facts: __________
Unresolved questions: __________
Smallest proposed change: __________
What must remain intact: __________
Owner / reviewer / backup: __________
Test / stop point: __________
Pass condition: __________
Recheck date: __________
Result: Passed / Failed / Not checked
Next investigation, if any: __________
Verification script
“Starting at [exact entrance] on [device/browser], attempt [original task]. Read [changed wording]. Explain what happens next without coaching. For the agreed submission test, use [fictional test reference] and stop before [boundary]. Confirm [expected receiving evidence]. Check that [preserved behaviour] still works. Record actual result and cleanup.”
Team handoff note template
“We observed [specific issue] while attempting [task]. The agreed correction is [bounded change]. [Owner] will complete it; [reviewer] will verify the operating facts. We will repeat [exact test] on [date]. Preserve [working elements]. Until the receiving-side check is complete, its status remains Not checked.”
Keep the workshop grounded
- Use public copy, team roles and fictional test details. Keep patient information in the practice's appropriate systems.
- Confirm prices, appointment status and operating promises with the team; have clinical explanations reviewed by the appropriate practitioner.
- Before a live submission, agree the receiving owner, stopping point and cleanup so the test does not create an unintended appointment or send messages to someone else.
Leave with a decision, not a score
At the next team meeting, ask: Did we make the repair? Did the same task work? Did it cause a new problem nearby? What evidence remains missing? Review recurring questions or aggregate journey progression separately when there is enough relevant activity to learn from. Record the period, any changes to traffic or staffing and unknown outcomes.
If implementation needs a connected marketing starting point, bring the repair contract to The Defibrillator. You will arrive with something more useful than “we need a better website”: a real task, a supported observation and a clear next move.
Practice-owner education from PowerSURGE. Use the working tools with the people responsible for your practice’s message and response.
Explore the complimentary Defibrillator Starter KitMAKE IT YOUR TEAM’S NEXT WORKING SESSION
Keep the guide.
Put the tools to work.
A 45-minute team audit with an observation sheet and a practical repair brief.
Enter your email to access all three files.
- 01Complete workshop PDFPDF
7 pages of steps, examples and working guidance.
- 02Working worksheet PDFPDF
4 pages to use in your team’s working session.
- 03Editable MarkdownTEXT
Copy, adapt and keep your own working version.