Dental Website Enquiry Journey Checklist

A fictional visitor wants to enquire about a dental check-up. From the service page they choose one of three alternative routes: phone, form or booking link. Each route has its own checkpoint: does the call connect, is the request delivered, or does the link reach the correct destination? The routes meet at reception review and follow-up. A confirmed appointment is a later state that exists only when explicitly agreed. A successful initial click alone verifies none of those handoffs.

The hypothetical website says Tuesday 9–5, phone 416-555-0100, address 10 Example Lane and dental check-ups. These invented values are paired respectively with the current practice schedule, reception line record, clinic address record and approved service list. Appointment availability is marked not confirmed and remains unpublished. The comparison teaches the team to use authoritative practice records rather than fill missing information with a plausible guess.

Two separate lanes ask different questions. General website content asks what a dental check-up is; the designated clinical reviewer checks it before publication review. An individual asks whether something is right for them; that question belongs with the clinician in a clinical consultation. A divider keeps these routes apart. No treatment advice is supplied, and approval of general content does not establish individual suitability.

A glass smartphone and magnifying lens represent tapping a phone link and checking the displayed number. The invented number is 416-555-0100. A red break before a separate telephone receiver marks the possibility that the call fails to connect. A later reception desk represents checking the actual team that answers. The three checkpoints are tap and number, connection, and correct reception. A recorded tap only verifies the first interaction.

The form is explicitly schematic and uses invented details. The required name is TEST Jamie. A required email field is empty and receives the specific error Enter an email address. The corrected value is test@example.com. Preferred callback time remains optional. No patient history is requested. The correction is understandable because the field and the needed action are both named.

A fictional TEST form submission splits into two independent checks. The visitor sees an acknowledgement that the request was received and reception will reply. The other branch is visibly broken before reception, and no TEST receipt reaches the intended team. The image therefore marks the test as failed. A successful visitor-facing message is not evidence that the team received the request; both sides must work.

The fictional visitor intends to request a dental check-up at Harbour clinic. A schematic booking link forks toward two buildings. The blue upper route is the intended Harbour clinic; the red lower route reaches Hilltop clinic and is blocked as a mismatch. The next step is also checked: request a time at the intended clinic. These labels describe the hypothetical example, not any specific booking software capability.

Two hypothetical messages represent distinct states. Request received says reception will contact the visitor and no time is reserved. Appointment confirmed states an agreed Tuesday 20 October at 10:30 at the fictional Harbour clinic. If reception still needs to choose a time, only the request acknowledgement with the actual next step fits. The example does not describe a real booking.

During opening hours, the fictional reception lead handles new enquiries. After hours, enquiries enter an explicitly configured queue that the next-open duty receptionist reviews. Both paths feed an unanswered-request review, and any published response time must be approved and achievable. The diagram explicitly qualifies direct booking: it requires the practice’s approved booking connection and scheduling rules. It makes no instant-booking or blanket availability promise.

A closed records box stays behind an exclusion boundary, separate from the feedback flow. Recurring questions are reduced to anonymous categories. A wrong-location category leads to clarifying the clinic name; an unclear-next-step category leads to explaining the reply process. Only necessary category totals belong in the brief. No counts, identifiable messages or treatment histories are shown, and the illustration makes no technical anonymization guarantee.

Five rungs define different measures: a website visit means a page was viewed; a phone-link click means a link was tapped; a submitted request means a request was sent; a confirmed appointment means an appointment was agreed; an attended visit means attendance was recorded. Dashed transitions explicitly do not prove the next stage. Not every route uses every stage. A submitted request may remain unconfirmed, duplicate another request, be cancelled or never lead to attendance.

The earlier-period and later-period worksheets deliberately leave dates and submitted-request totals blank. They require the same date-range length and the same event definition. Additional checks ask about repeated enquiries, changes to tracking capture and fewer available appointment times. These factors can alter the meaning of request counts. There is no invented patient count, trend or improvement claim.

A fictional issue concerns the Harbour clinic contact page: its phone link opens the wrong number. The web editor owns correcting the linked number. The evidence needed to close the issue is a repeated call reaching the intended reception team, not merely an edit log. Incorrect information and failed delivery take priority before wording and reporting improvements. A booking-software change triggers another journey test.