A patient calls the front desk to ask where their appointment went. They booked online and the screen confirmed the booking. Nobody can find it under their name.
Calls like that were usually how the staff learned a booking was lost. Other patients booked the same way and their bookings went through.
The setup. A New York City clinic group running Google Ads for calls and online bookings. This write-up is de-identified: no names, no patient data, no account IDs.
Why nothing looked broken
Because the screen told every patient "you're booked," nothing in the system told the clinic which bookings it had lost. There was no pattern to follow either: no error the staff could point to, and no reliable way to make it happen on demand.
It looked random because four separate failures overlapped, and one success screen covered all of them.
A test booking, followed all the way
Before reading any code, I made a booking myself and followed it step by step:
- The widget. That's the booking form patients use online. I kept the exact request it sent and the response that came back.
- The database. I looked up what the booking system's database had written for it.
- The scheduling system. Through its API, the connection other software uses to read and write appointments, I asked for the appointment the database said it had created.
- The screen. I put all three next to what the patient had seen.
The fourth step broke it open. The screen had shown a confirmation for bookings where the backend, the part the patient never sees, had returned an error. It had also confirmed appointments that were created under the wrong patient. The widget put up its confirmation whenever the request came back, whatever the response said.
Four failures, one screen
| What it looked like | What was actually happening |
|---|---|
| Bookings vanished at random | A customer record was linked to the wrong patient's chart, so that customer's new bookings were filed there |
| Some patients got no confirmation | Email came from a free mailbox with no SPF, DKIM or DMARC, so it went to spam |
| Text confirmations were "unreliable" | Sends were failing systemically at the provider, not now and then |
| The widget always said it worked | It showed success without reading the system's response |
Some of the vanished bookings had been misfiled, not lost. A customer record in the booking system had been linked to the wrong patient chart in the scheduling system. Every new booking for that customer went onto someone else's record. The front desk searched under the right name and found nothing.
The email and the text failed at the same time. The text was the fallback for the email, so patients who really had booked often heard nothing at all, and assumed the booking had failed.
The success screen hid failed bookings: on a backend error, the patient still saw "you're booked" and went home.
What I fixed, and what I handed over
Two fixes went into the system. Two went to the clinic as written instructions, so I never had to touch their mail or telecom credentials.
- Matching, fixed. I corrected the wrong link and changed the matching. An unclear match now goes to review, so it can't quietly tie a customer to the wrong chart.
- Success screen, fixed. The widget now checks the backend's real response and the ID of the created appointment before it shows a confirmation.
- Email, documented. The instructions describe moving confirmations to an authenticated sending domain with SPF, DKIM and DMARC in place, so they stop landing in spam. Those three are settings on your domain that let mailbox providers check the mail really comes from you.
- Texts, documented. A configuration fix on the provider's side, so the texts actually send and the second confirmation channel comes back.
Throughout, the work stayed HIPAA-conscious. Patient data was never written into logs or exports. Phone numbers used in matching were hashed, turned into a code that can be compared without showing the number. Ad reporting gets a timestamp, a value and the anonymous id Google attaches to an ad click, and nothing else.
Once booking records are right, they can feed offline conversion tracking. It tells the ad account which clicks became real appointments, so a practice can see which ad spend produced an appointment. With the privacy rules above, none of this has to move patient data.
I didn't measure booking volume before and after, so there is no number for it here. The engagement was delivered and rated 5.0.
Run a similar test on your booking page
Start on your phone.
- Book like a new patient. Use your own name and number, pick a real slot, and finish the booking.
- Wait for both confirmations. Look for the email, spam folder included, and for the text. If the email comes from a free mailbox address, ask whoever set it up about moving it to your own domain with SPF, DKIM and DMARC.
- Find it in the schedule. Ask the front desk to look it up under the name you used, then cancel it. If it's missing, or filed under someone else, you have the symptom this clinic had.
- Ask whoever built your booking page what the confirmation screen waits for. It should appear only after the system sends back the ID of a created appointment.
- Ask the front desk to tell you about every "where's my appointment" call. In this case, that is how the staff usually found out.
Tags
Frequently asked questions
Why do some online bookings never show up in my schedule?
In this case there were two reasons. A matching bug filed appointments onto the wrong patient's record, so they existed but staff could not find them. And the widget reported success even when the backend returned an error, so sometimes nothing was created at all. Both looked random from the front desk.
Why do my appointment confirmation emails go to spam?
Mailbox providers treat unauthenticated mail as suspicious and filter it. Here the confirmations came from a free mailbox with no SPF, DKIM or DMARC records, so patients who really had booked often got nothing in their inbox. The fix I documented moves them to an authenticated sending domain.
How do I know if my online booking is failing silently?
Book a test appointment and look for it in the schedule under the right name. Then ask whether the confirmation screen reads the backend's response and the created appointment ID, or only waits for the request to finish. A screen that never reads the response will show success on an error.
Can a booking system be fixed without exposing patient data?
Yes. The work here was HIPAA-conscious: patient records were never written into logs or exports, phone numbers used for matching were hashed, and ad reporting received a timestamp, a value and an anonymous click id, nothing more.
Not sure every booking actually lands?
I check that what the booking flow confirms really exists in the schedule, then tie those bookings back to Google Ads so the account counts patients who showed up. HIPAA-conscious, fixed price, verified in the account.
Prefer writing? (I reply within 24 hours)Prefer escrow? Hire me on Upwork (escrow)