Visibility
What a booking widget cannot tell you
Why does your booking tool's dashboard look healthy while the diary feels thin?
Visibility3 min readPublished August 24, 2026
Every reporting tool has a horizon, and its horizon is whatever it was present for. A booking widget was present for bookings. It can therefore tell you a great deal about the bookings it took, and nothing at all about the three most expensive things that happened around them.
The three absences
The person who arrived at 9pm and left
They found you, considered you, and encountered a phone number during hours they were asleep or working. They did not fill anything in, so no record exists. Your conversion rate is calculated on the people who got as far as starting a booking, which means the visitors who bounced at the front door improve your reported numbers by leaving.
The client who stopped coming back eighteen months ago
There is no event for lapsing. A booking tool holds the appointments that were made; it has no concept of the appointment that should have been made and was not. Retention loss is therefore invisible to it by construction, no matter how good its reporting screens are.
The slot that emptied at 8am and was never offered to anyone
A cancellation is recorded. What is usually not recorded is what happened to the hole it left. If nothing offers that slot to a waiting client, the practice loses the revenue twice: once from the cancellation, and once from the capacity that sat idle while somebody else waited a fortnight for an appointment.
The pattern
The three largest gaps in most practices share one property: they are all absences. Dashboards are built to count events. An absence is not an event, so it does not appear — which is why a healthy-looking dashboard and a thin-feeling diary are perfectly compatible.
Why adding reports does not fix it
The instinct is to ask the vendor for better analytics. But the missing information was never captured, and no report can aggregate data that does not exist. Surfacing absences requires a different starting point: not what happened, but what was expected and did not happen.
Event-based reporting
Starts from rows that exist. Answers: how many bookings, which channel, what revenue. Cannot answer anything about people who left no row.
Expectation-based reporting
Starts from what should exist: expected returns, held slots that emptied, sessions that reached the booking page and stopped. Answers are gaps.
Four questions worth being able to answer
- How many people opened the booking page last month and did not complete a booking — and at which step did they stop?
- How many clients passed their expected return date without rebooking?
- Of the appointments that emptied inside 48 hours, how many were refilled?
- What proportion of last month's booked appointments did not happen, stated as a number rather than an impression?
None of these needs a data team. All of them need the booking, reminder, payment and client records to live somewhere they can be queried together — which is the actual argument for connecting a booking flow rather than assembling it from four products with four logins and no shared memory.
The modest version
If you take nothing else from this, pick the fourth question and answer it monthly. A no-show rate you can state out loud is the smallest possible step from impression to measurement, and it makes every subsequent decision about tools cheaper — because you will be able to tell whether anything you bought actually moved it.
The first three questions are worth more, and they are harder, because they all require someone to have decided in advance that absences are worth recording. Almost nothing does this by default. That is precisely why the gaps stay open for years in practices that are, by every visible measure, doing well.