What actually happens after a booking is confirmed
The booking is the easy part. Everything that has to happen because of it is where spaces actually lose money and break the law — and the failures that hurt most are the ones nothing reports.
A booking is a promise to do eleven other things
When a reservation is confirmed, the record in the bookings table is the least interesting thing that happens. Depending on the space, confirming a booking should also open a door, issue WiFi credentials, allocate a printing quota, schedule the cleaning, raise an invoice, take a payment, calculate tourist tax, file the guest with the authorities, run whatever automation rules match, send the guest a message, and push the dates back to the channel it came from.
Every one of those is a separate system that can fail on its own. And they fail in a specific, nasty way: quietly.
The failure a status page cannot show you
There are two kinds of failure here, and only one of them is easy.
The easy kind is a step that ran and returned an error. The door provider rejected the credential, the payment was declined. Something happened, so something can be logged, retried and alerted on.
The dangerous kind is a step that was never attempted. Nobody enabled the integration. A condition silently excluded the booking. A queue job never ran because its cron was never installed. There is no error, because there was no attempt. In a system that logs what it did, this failure is invisible — the log simply has nothing in it, and nothing in it looks exactly like nothing went wrong.
This is why Boris does not just log actions. It reconstructs what should have happened for each booking and compares that against what did, so a step that was never attempted is shown as missing rather than being absent from the list.
Expectations come from configuration, not from a checklist
The set of steps a booking owes is derived per booking. If the space has an active door linked to that resource or to a common area, door access is expected. If a guest WiFi network is active, WiFi is expected. If a legal registration provider is enabled, filing is expected. If the booking carries a tourist tax amount above zero, the tax step is expected.
That matters because it makes the check honest for spaces that do not do all of it. A coworking with no doors under software control is not nagged about door access forever. Turn the integration on, and every booking from that point owes the step.
Four steps are not optional
Boris marks four areas as required, because when they fail silently the consequence is legal or financial rather than cosmetic: legal registration, tourist tax, invoicing and payment.
The asymmetry is deliberate. A guest not receiving their WiFi password is an annoyance they will tell you about within the hour. A guest never being filed with the authority is something nobody will tell you about, and in Spain and Italy alike the deadline is 24 hours from arrival. By the time anyone notices, it is a fine, not a task.
Done, versus provably done
"We called the API and it returned 200" is a weaker claim than it looks. The request can succeed and the effect can still not exist.
Where a provider publishes evidence of its own — a door-open event, an authority reference number — Boris records the step as additionally verified. The distinction shows up in the health overview as two separate numbers: how many steps succeeded, and what share of those succeeded and can be proven. A high success rate with a low verification rate is worth investigating; it usually means an integration is accepting requests and doing nothing with them.
Per booking, and across the space
The same records feed two views that answer different questions. Per booking, the dossier is what you open when a member says the door did not work at 8am: every step, its status, its provider reference, and a retry that re-runs it through the service that owns it rather than faking the effect.
Across the space, the overview scores each area over a window and lists the bookings currently at risk. This is the report that catches an integration that broke on Tuesday and has been failing ever since, which no per-booking view will ever surface because nobody re-opens old bookings.
Why this is worth building before you need it
Most spaces add this after an incident: a guest who never got access, an inspection that found unfiled stays. The reason to do it earlier is that the ledger is the only thing that makes the other integrations trustworthy enough to rely on. Automation you cannot audit is not automation — it is hope with a cron job.