This June article described a product direction: reducing unnecessary account and app steps for guests. That remains a useful design goal, but a proposed journey must not be read as a promise that every step is enabled in every school.
Practice: walk through the booking path yourself
This check needs no new feature. Open your school’s existing offer on a phone and work through to the final order summary. Stop before a binding purchase or a real payment. If an earlier step already creates a booking, reservation or message, use a suitable test environment or review that step with the responsible person.
- Access: Is a login required before the guest understands the offer and price? Is it needed for your process, and is the next action clear?
- Details: Are required fields clear? Does the person booking understand whether you need their own details or each participant’s?
- Readability: Can guests read dates, options, total price and the amount due now on a phone? Do error messages explain the problem?
- Going back: Can the guest correct a choice without unexpectedly losing previous entries or creating a second booking?
Record one obstacle with the page, device, expected behaviour and what you observed. Use a test screen without personal guest data for any screenshot, and do not share booking links containing access tokens. Assign a specific repair, such as “Explain participant details before the group form”, then repeat that step.
Your result: one reproducible problem or open question with an owner. This test does not confirm QR check-in or account-free access. It shows how your current booking path works. If the offer itself is unclear, start with the course-page check.
Start with the information guests need
A confirmation should make the activity, time, meeting point and preparation easy to find on a phone. If payment or participant information remains open, the next action should be clear. Test the message with the actual school configuration and a guest's device.
A useful test is a group booking: can the person who paid distinguish their own details from those of the participants? Who receives changes, and how does another participant find the meeting instructions?
Check access before promising it
For secure links, confirm which information the recipient can open, how access is protected and what happens when a link no longer works. For QR check-in, confirm that the actual school setup supports ticket generation and scanning. Prepare a staff-assisted lookup as a fallback and train the team to verify the correct participant.
A QR code is a way to retrieve or act on a record. It is not proof that payment, documents or safety checks are complete unless those states are actually checked.
Keep identity and consent separate
A booking record can identify a customer without identifying every anonymous visitor to the school website. Do not infer a durable customer identity from unrelated browsing. Optional website attribution has its own identity, source and consent requirements.
Test arrival as a complete workflow
Try a returning guest, a family, an unpaid balance and a participant with missing information. Confirm who can change attendance and which information the instructor sees. Only then write the guest instructions for that specific setup.
The customer journey overview describes the connected records currently used around a booking.
How does this work at your school?
Bring an everyday task from your school. We’ll show you how it could work in TIDEFORCE.
Request a demo →