Healing Waves Wellness is a chiropractic and therapeutic massage practice in Santa Cruz. Its entire book of future appointments, some of it scheduled more than two years ahead, had to move to a new scheduling and payment system while the practice kept seeing patients four days a week.
“Amazing work, very detailed and thorough, with immediate responsiveness, especially after go live to work out the kinks.”
Dr. Melanie Hernand Shine · Healing Waves Wellness
A working practice cannot be switched off while its systems are replaced. That single constraint shaped every decision here.
The practice was running on an older scheduling platform and moving to a new one, with card payments alongside it. This was not a fresh installation. Thousands of appointments were already booked, roughly eighty patients were on standing weekly or twice monthly care plans, and some of those bookings ran into 2028. Four treatment tables run at the same time in half hour blocks. A massage therapist works her own separate hours. And the practice website still sent every visitor to the old booking system.
Nothing was configured until we had sat with the practitioner and both front desk staff and recorded a full working session. The centrepiece is one question, and the answer is written down word for word: if you had a wand, what would you change?
Her answer was about the confirmation email. It had to say what the patient actually booked, in the words the patient uses, at the price the patient expects. That sounds like a small thing. It turned out to drive the single largest technical decision in the project, and we would have got that decision wrong if we had started with the software instead of the conversation.
Patient records came across and were reconciled line by line against the old system's own export. Twenty eight genuine exceptions were written to a file rather than quietly absorbed: names broken by nicknames in quotation marks, and patients with no email address who would otherwise silently receive nothing forever. Those went to the practice as a list to fix, not as a footnote.
Every migrated appointment carries its old system patient ID inside its notes. That became the only reliable way to match a record in one system to a record in the other. Matching on names had already failed once during the original import, and a migration that matches on names is a migration that quietly corrupts a handful of records nobody finds for months.
The practice adjusts up to four patients at once, on four tables, in the same half hour slot. The import had put every appointment on one calendar, stacked two and three deep. It looked plausible on screen. It was calculating availability as though the practice had one table, which would have started turning patients away.
The deeper cause took longer to find and matters more. In this platform, availability does not belong to a calendar, it belongs to a service group sitting on that calendar. The practitioner's calendar carried four different groups with four different sets of weekly hours, including a separate after hours window used only for first visits. Because that window is one visit long, it enforces the practice's rule of one new patient per working day through the structure itself rather than through anyone remembering.
Redistribution ran as a script, not by hand: a dry run first, an explicit list of which service types are allowed to move so that one to one services never land on a shared table, and a rollback file written as it went. Across two and a half years of bookings the schedule reaches four patients in a single slot just once. The safeguard that caught that one slot also caught three other appointments a simpler script would have skipped without saying so.
Nearly every future appointment, 5,590 of them, had been imported onto one service type carrying the wrong name and the wrong price. The platform's interface offers no way to change an appointment's type once it is booked, and neither does its API. Correcting them individually would have meant cancelling and recreating every one: roughly ten thousand write operations, every appointment identifier destroyed, and the old system IDs in the notes put at risk. Four days before go live, that is not a trade worth making.
We tested a hunch instead and found that appointment names and prices are read live from the service record rather than copied onto each booking. So we renamed one record. All 5,590 appointments corrected in a single edit, then verified by re-running an independent audit against the account rather than trusting the screen.
Before anything was touched, every outbound message the system could send was switched off: booking, cancellation and reschedule confirmations, the reminder, patient text messages and internal alerts. This was urgent rather than tidy. Around eighty standing patients held appointments running to 2028 and were already receiving reminders from a system they had never heard of.
Every operation after that also carried its own suppression flag, as a second layer underneath the account wide switch. Thousands of records were rebalanced, renamed, cancelled and created across two weeks. Nothing reached a patient.
The old platform kept taking bookings during the parallel run, so a second export was taken and compared against the original. That produced two lists: appointments made since the first export, and appointments cancelled in the old system that were still sitting in the new one. Left alone, the practice would have opened on Monday looking at a schedule of people who were not coming.
Rather than act on the difference, we ran a read only diagnostic first. It separated four causes that look identical in a plain comparison and call for opposite responses: already cancelled, moved to a different time, matched to the wrong identifier, or never migrated at all. That check cut the removals by more than a third, because most had already been handled by the front desk. A small remainder that could not be matched with confidence went to the desk on paper to enter by hand, rather than being guessed at.
A new site was built and put live on the practice's real domain. The work that mattered most is the work that is invisible when it is done correctly.
The previous site had published dozens of addresses over the years. Fifteen permanent redirects were written so that every one of them lands on the right page of the new site. This is the step most businesses skip, and it cannot be recovered afterwards.
Here is why it matters. Every link a patient ever shared, every page saved as a bookmark, every listing already indexed by a search engine, and every citation on a directory or a social profile points at the old addresses. Without redirects, all of them become dead ends on the day the site changes. The practice loses the search authority it accumulated over years of being online, and the patient who bookmarked the booking page gets an error rather than a booking. A permanent redirect passes both the visitor and the accumulated search ranking to the correct new page. It takes an hour at build time.
The practice's email runs through the same domain settings as the website. Moving the domain wholesale to the new host, which is the default advice, would have put mail delivery at risk to gain the site nothing. The domain stayed where it was and only the two records that point at the website were changed.
Changing the first of those records silently detached the domain from the old hosting service, which removed several unrelated records at the same time, including those that route visitors arriving over newer internet addressing. Left undetected, a slice of visitors would have kept landing on the dead old site while it looked perfect to everyone else. We checked afterwards rather than assuming, and restored what needed restoring.
The domain had no sender authentication record at all, while two separate services were sending email as the practice. That is a quiet and growing cause of mail going to junk folders. It was added, along with reporting so that delivery problems become visible rather than invisible.
The advertising domain verification from the old website was carried forward into the new build so that the practice's ability to advertise survived the change of site. That verification lives in a single line of markup on the old homepage, and vanishes with it.
The old site and its hosting were deliberately left running and paid for after go live. It is the rollback path, and for a period it was also the only complete copy of the old content.
Card processing was connected to the practice's existing business account, with rules set per service: some paid at the time of booking, the introductory first visit taking no payment up front, and one service made impossible to book online at all so the practice never pays a therapist for a patient who does not arrive.
Card details never migrate between systems, by design and by regulation. So the first month was built around a habit rather than a feature: the front desk stores each patient's card at their next visit using a zero value charge, which saves the card securely without taking any money. Every card stored that way becomes a payment the practice can take later without the patient present.
Patients were being declined when paying with health savings and flexible spending cards, and nothing appeared to be wrong. The payment account was classified under a business category describing a massage business rather than a chiropractic practice. Health savings cards are only permitted at merchants in recognised health categories, so the patient's own bank was refusing the transaction before it ever reached the practice. Neither the card nor the card reader was at fault, which is why it had gone unexplained. We identified it and routed the correction through the payment processor.
The front desk needs one thing at the end of a day: who was seen, what was collected, and who was missed. The platform cannot answer that question. Both of its reporting screens group by service rather than by person, and neither displays a patient's name anywhere. The information exists only in a spreadsheet export.
So we built it. An automated summary now arrives in the practice inbox at closing time on each of the four clinic days, listing every visit of that day in order with what was collected and a total, alongside a tool the practice can run for any day it needs.
The design detail that makes it usable is what it does not flag. Standing patients drawing down a pre-paid pack are shown as normal rather than raised as problems, because a report that produces twelve alarms a day is ignored inside a week. Only genuine exceptions surface, including any payment that does not match the price of the service it was booked under.
It found one on its first run: a first visit booked under one service name with a different service's fee collected against it. That is a discrepancy that would otherwise have been found at the end of a quarter, or never.
Two printed single page guides, written from the questions the staff actually asked on the recorded session rather than from the software's own documentation. One covers closing out the day. The other covers booking across four tables, written after the desk reported that everything was landing on the first table.
That turned out not to be a bug. The system never assigns a table on its own, and the first option in the list carries the practitioner's own name, so it does not read as a table at all. Naming the cause in one sentence solved a problem that a week of retraining would not have.
Three things were deliberately not automated, and the reasoning is the practitioner's own. She declined automated pack renewal emails because a patient deciding in the room after care is in a different frame of mind from one deciding at home surrounded by their objections. So we left alone: counting visits against a pack, which stays on the physical card the patient carries in; the daily cross check against that card; and asking a patient about their next pack, which happens in person. A patient deciding in the room is in a different frame of mind from one deciding at home. Knowing what to leave alone is part of the work.
For a local practice, the business listing that appears beside a map is more often the first thing a prospective patient sees than the website is. It was reviewed as part of the move. The opening hours shown there did not match the hours the practice actually keeps, which sends patients to a locked door and counts against the listing's ranking.
The review count was also well behind comparable practices nearby. Review volume and recency feed directly into which practice appears first when somebody searches for care in the area, which is why a review request sits in the first phase of the roadmap rather than a later one.
Every item below was found or prevented by us, not requested. None of it appears on a scheduling platform's setup checklist.
The practice is live on the new scheduling and payment system. The website is live on its real domain with a security certificate, email untouched throughout, and every legacy address redirected. The forward book has been corrected, rebalanced across four tables and reconciled against the old system. The front desk closes each day against an automated summary that arrives at closing time.
The old system has been retired and the old website remains available as a rollback path. No patient received an unintended message at any point in the migration.
Automation follows scheduling, never the other way around, because everything downstream depends on clean scheduling data. The sequence is built on the practice's own appointment history rather than a generic template, and it puts retaining existing patients ahead of finding new ones.
First, proving the approach with appointment confirmations and a review request timed to a patient's fifth visit, when they have felt enough benefit to mean it. Then, closing the two gaps that quietly cost a practice the most: slow response to a new enquiry, and patients who drift away without anyone noticing. Then, a patient education sequence that answers, in the practitioner's own voice, the questions asked in the treatment room every week.
New patient scheduling stays manual and under the practitioner's control. That is a deliberate exclusion and it is not on the roadmap to change.
Discovery before build, every time. Systems that fail loudly rather than quietly. Nothing automated that a practice has decided should stay human. And a written record of every decision, so the practice owns what was built rather than depending on whoever built it.
Practice and patient details in this study are described with the practice's permission. No patient information appears in this document.