At a glance
A booking button is the start of a path. Check where it leads, record what a patient sees, and distinguish a problem from a step you could not inspect.
1. Decide exactly what you are checking
Start with a roster of locations and their public website addresses. Give each booking entry point its own row: a main appointment button, a new-patient link, a consultation button, or a link from a public listing. Several buttons on the same website can lead to different systems. A working homepage button does not establish that the location-page button works.
Agree on the devices, appointment types, calendar dates, and inspection boundary before beginning. For a first pass, choose a manageable set of paths and record the coverage you actually complete. Keep locations that were not inspected visible in the roster so they cannot be mistaken for successful checks.
Use public pages and stop before sending a request, reserving a slot, creating an account, or submitting patient information. If the next step requires information or authorization you do not have, record that stopping point. Testing delivery or appointment creation is a separate, explicitly authorized exercise with the responsible team.
- Location name, address, and starting URL
- Entry point and intended appointment type
- Device and browser used for the check
- Date, time, and time zone of the observation
- Calendar date range, if a calendar is inspected
- Agreed stopping point and the person responsible for the check
2. Follow the path a patient actually sees
Start at the public office page. Record the appointment action you choose.
Follow the link. Check the office name, address, and appointment channel.
Record the destination, selection, and last step you could inspect.
Stop before sending a request, entering patient information, or reserving a slot.
Open the location page, rather than starting at a scheduler URL you already know. Find the appointment action in the page layout and follow it. On mobile, check the menu and any fixed appointment button as well. Record which action you used so another person can reproduce the route.
At each handoff, check the office name and address. A scheduler can load correctly while pointing to the wrong location. If the destination offers several offices, inspect the selected office instead of assuming the original page carried the selection through. If you cannot establish which office receives the request, leave the routing unverified.
Identify the channel you reached. A phone number, a request form, and an appointment calendar are different outcomes. Describe the experience the page provides. Do not describe a request form as a confirmed appointment or treat a clearly labelled telephone route as a broken calendar.
If a calendar is visible without taking a slot, record the appointment type and dates you inspected. No times for that selection is a bounded observation. It does not mean the office has no availability for other services, other patients, or dates you did not inspect.
| Channel reached | Useful observation | Still unverified |
|---|---|---|
| Telephone | A visible number and clear call instructions | Whether the call is answered or results in an appointment |
| Request form | The correct office and a reachable form | Request delivery, office response, and appointment confirmation |
| Calendar | Displayed times for the inspected selection | The complete schedule and whether a booking would finish |
3. Separate a booking issue from an incomplete check
Use labels that describe the evidence. “Broken booking” is too broad if all you know is that an automated browser could not inspect a page. Equally, a page returning a successful HTTP response says little about whether a person can find the right office or continue through the form.
Keep observed problems, details that need confirmation, and checks you could not complete in separate groups. A blocked or interrupted inspection should remain visible until someone can resolve the uncertainty. Do not count it as either a successful path or a confirmed patient-facing failure.
| What you observed | How to record it |
|---|---|
| The booking button opens an error page | Observed issue: record the entry point, error, and reproduction steps |
| The destination displays a different office | Routing detail to confirm with the location or scheduler owner |
| A challenge or login prevents further inspection | Incomplete check: record the last visible step and the restriction |
| No times appear for the selected type and dates | Scoped availability observation: preserve the exact selection |
| A request form is reachable at the correct office | Observed channel: submission and delivery were not tested |
4. Turn an observation into an actionable finding
The location page identifies North Office.
The checker follows the public link on mobile.
The next page shows a different office name and address.
Fictional example. Stop before data entry. Confirm the intended office, correct the link or label, then repeat the same path.
In this example, the office identity changes at the handoff. Ask the owner whether the cause is a shared intake process, an incorrect label, or the wrong link. No request was sent, so delivery remains unverified.
A good handoff includes enough detail to repeat the observation, the person who should investigate it, and the evidence needed to close it. Avoid copying patient details, session tokens, or private URLs into the finding. Use screenshots of the public path with sensitive fields absent or masked.
- Starting page and the exact button used
- The destination and visible office identity
- Expected behavior versus observed behavior
- A dated screenshot or short reproduction record
- The inspection boundary and remaining uncertainty
- An owner, agreed next action, and recheck date
5. Route the fix to someone who can make it
Attach the starting page, observed behavior, and reproduction steps.
The website, form, or scheduler owner checks the finding and makes the agreed change.
Use the original entry point and device type. Save a dated result alongside the finding.
If the issue remains or the check is blocked, return it to the owner with the new evidence.
The team that owns the website may not control the scheduler. A link change, an embedded form configuration, office details, and displayed appointment times can have different owners. Assign the finding according to the affected step and include the location team when the intended experience needs confirmation.
Prioritize using what is known: the obstacle observed, the entry points affected, and any verified traffic information your team already has. Without that information, do not turn a count of broken links into an estimate of lost patients or revenue. A small number of well-documented findings is more actionable than a large, unexplained failure percentage.
After a change, repeat the same entry point on the same device type and inspect the same appointment selection where applicable. Save the new date, destination, result, and stopping point alongside the original finding. An edited link is not closed until its public path has been checked again.
| Affected step | Likely first owner to confirm |
|---|---|
| Website button or destination link | Website team or agency |
| Embedded form or office routing | Form administrator and location team |
| Scheduler selection or displayed times | Scheduling administrator and office operations |
| Public listing appointment link | The team managing that listing |
6. Keep one record per inspected path
Use the downloadable worksheet as a starting point. It contains a blank row and fields for the location, entry point, device, appointment selection, observation, classification, stopping point, owner, and recheck. Duplicate a row when a location has more than one booking path. Keep the worksheet in your team’s approved workspace.
The record should make coverage visible. Keep “not checked” separate from “checked with no issue observed,” and preserve the original result when you add a recheck. Group-level reporting should state how many locations and paths were inspected, over which dates, and which checks remained incomplete.
Choose a repeat cadence with the people maintaining the sites and schedulers. Recheck affected paths after releases, scheduler changes, or office-detail changes as well. A periodic check is a dated observation; it cannot establish that every path worked between inspections.
Download the audit worksheet (CSV)Questions to settle before you start
Should we send a test request? This guide stops before submission. Any delivery test needs a separate agreed procedure, authorized test information, and an owner who can identify and clean up the test. Do not send an unsolicited request to prove the form works.
Does a successful check mean patients can book? It means the documented steps were observed at that time. If the inspection stopped before submission, request delivery and completion remain unverified. State that limit next to the result.
Can we combine website and Google listing checks? You can include both as distinct entry points when they are in scope. Keep a separate row for each. They may lead to different destinations, and success through one route does not establish success through another.
What would Spawn Partners do? We agree on the locations, entry points, and inspection scope, then document the patient-facing behavior and the next steps suggested by the findings. Coverage, reporting, and repeat checks are agreed for your group. Bring a few representative location URLs to a walkthrough so we can discuss the paths that matter to your team.