Start with a service policy, not a screen
Before changing software, agree how your team handles booked visitors and walk-ins. Are appointments arrival windows or fixed service slots? When does a booked visitor join the live queue? Who can approve an exception? Put those answers in a short desk guide that every shift can use.
The policy depends on your setting. A service centre may separate collection from diagnosis; a clinic may need clinician-directed urgent exceptions. Software should make the decision visible, not invent a priority policy. Do not promise that registering online puts someone ahead of every person already waiting.
Keep the appointment separate from arrival
Record the planned visit when the appointment is made. When the person reaches reception, find that visit and confirm their arrival instead of creating a second visit. A walk-in starts with registration and arrival together. Both can then appear in the appropriate live queue.
With Ado Q appointments, staff can record the visit source and whether the person has arrived. Use the existing patient or client profile for returning visitors so their history stays connected. Check identifying details privately; avoid asking people to announce sensitive information across the waiting room.
Give each exception a clear owner
| Situation | Desk decision | What to tell the visitor |
|---|---|---|
| Early arrival | Confirm the visit and apply your arrival-window policy. | Whether service may start before the booked window. |
| Late arrival | Ask the responsible staff member whether to retain, reassign or rebook. | The agreed next step, without a guaranteed wait. |
| Missed call | Use the agreed recall or return-to-queue procedure. | Where to check in again. |
| Counter interruption | Pause or transfer the affected queue/visit with a handover. | Which desk is handling the visit next. |
These are planning prompts, not automatic rules that Ado Q applies to every account. Rehearse the actions with your own team and confirm the supported configuration during the demo.
Explain the queue without exposing the record
A personal visitor queue-status link gives someone a way to check their ticket, people ahead and estimated wait from a phone. Explain that estimates change as service proceeds. Keep a staff-assisted option for people without a suitable phone or who prefer to speak to reception.
Queue status and private records serve different purposes. A public display should not be treated as a patient portal. During evaluation, check exactly which information each link exposes, who receives it and what happens if it is forwarded. Never use a shared demonstration workspace for actual patient information.
Rehearse a mixed-arrival shift
- Create one scheduled visit and one walk-in using sample details.
- Mark the scheduled visitor as arrived and confirm that no duplicate visit appears.
- Call a visitor and inspect the corresponding phone status.
- Pause the counter, then practise a transfer and handover.
- Complete the visits and check their recorded history.
- Review the visit report with the same date range used for the rehearsal.
Ask the staff member who will run the desk to perform the actions, not just watch. Record where they hesitate, which labels need explanation and whether your exception policy is clear. This is more useful than testing only an ideal, uninterrupted queue.
Review the workflow after real adoption
Once production requirements and training are agreed, start with a defined workflow and a named owner. Review duplicate registrations, missed calls, confusing handovers and visitor questions. Use consistent waiting-time definitions before comparing reports.
Do not assume an improvement percentage in advance. Record the observation period, staffing and service mix so you can interpret changes fairly. For a product walkthrough, tell us about your reception process or book a demo and ask us to show the interruption that causes your team the most trouble.