The fix for both is the same: treat the rollout as a manufacturing process — one pilot, one hardened template, then waves with go-live gates. Here's the playbook, including the gotchas that only show up in production.

Why EHR-integrated, not standalone

A standalone scheduler creates a second calendar someone must reconcile forever. EHR/PMS-integrated booking (we maintain 30+ integrations, from cloud APIs to on-prem connectors) means:

• Slots come from the real schedule — providers, appointment types, durations, rooms — so the widget can never offer a time the practice can't honor.
• Bookings write back as real appointments (and new-patient charts where needed), so the front desk workflow doesn't change.
• The website never holds intake. The widget runs iframed off the site; patient data goes to the platform and the EHR, not the web database. Compliance case: HIPAA-Compliant Online Scheduling.
• Every step is measurable via widget micro-events — opened, location picked, slot picked, details entered, booked — which is how you'll debug funnels per location later.

Phase 1: Pilot one location like you mean it (Weeks 1–2)

Pick a pilot that's representative, not flattering: a location on the group's most common EHR, with typical staffing and call volume. At the pilot you'll discover the group's real configuration decisions:

• Which appointment types are bookable online. Not all of them. New-patient exams and consults, yes; complex procedures, usually no. Decide per type, with clinical leadership, once.
• Durations and buffers that match what the office actually books — the EHR's defaults often don't.
• Provider participation. Which providers accept online bookings, and whether patients pick a provider or take "soonest available."
• Required fields. Some EHRs require a real date of birth to create a patient chart; if yours does, the widget must collect DOB or bookings from new patients will silently fail to reach the EHR — the patient thinks they're scheduled, the practice never sees them. This is a per-integration rule, not a preference.
• Confirmation and reminder policy — what's automatic, what the front desk touches.

Run the pilot live for two weeks. Watch the micro-events, sit with the front desk, and log every "that's weird" — each one is a template fix that saves you N repetitions.

Phase 2: Harden the template (Week 3)

Convert the pilot into a written per-location configuration template. The non-obvious entries that belong in it, learned the hard way:

Timezone, at every layer. Timezone must be set correctly in the location record, the availability schedule, and any per-channel scheduling layer — because defaults disagree. The classic failure: an availability layer defaulting to UTC turns a Chicago office's 8-to-5 into slots rendered at 2–3 a.m. for visitors. Patients don't report it; they just don't book, and the dashboard reads "low conversion." The template therefore includes an automated slot QA gate: generate real slots and fail the go-live if any renders outside 6 a.m.–10 p.m. local time.

Notification silencing before first sync. Connecting an EHR usually triggers a historical appointment import. If patient-facing SMS/email notifications are live during that import, the system pages real patients about old appointments. Template rule: all patient notifications zeroed before the first inbound sync, re-enabled deliberately after the import settles.

Mapping tables per location: provider ↔ EHR provider ID, appointment type ↔ EHR type ID, location ↔ EHR facility, plus room/operatory mapping where the EHR schedules by chair. An unmapped appointment type shouldn't break the flow — but it should be a logged, reviewable event, not silence.

Auto-confirmation policy: whether an online booking lands as confirmed or as a request the front desk approves. Groups usually start with review-then-confirm at each new location and flip to auto-confirm after two clean weeks.

Phase 3: Waves (Weeks 4 onward)

Roll out in waves of 3–5 locations, grouped by EHR — same-system locations share 90% of their configuration and 100% of their failure modes. Per location, per wave, run the gates:

The per-location go-live gate checklist

Gate 9 earns its row: booking flows routinely pass desktop QA while being unusable under a thumb — verify both viewports as separate runs, every location, no inference. Gate 8 catches the subtler class of sync bugs (cancellations and reschedules echoing or vanishing) before patients do.

A location that fails any gate doesn't go live with a follow-up ticket. It goes live when it passes. The entire value of the wave model is that gate discipline costs a day and template drift costs a quarter.

Phase 4: Operate (ongoing)

• Watch micro-event funnels per location weekly. Divergence is diagnosis: a location leaking at slot selection has a supply problem (providers not releasing schedule, durations too long); one leaking at the details step has a form or trust problem.
• Re-run slot QA after any schedule or config change. Availability edits are the top post-launch breakage source.
• Feed "booked appointment" into attribution. The rollout's payoff isn't convenience — it's that marketing can now optimize to appointments in the EHR rather than form fills. That wiring is Cross-Location Attribution Under HIPAA.
• Onboard acquisitions with the same template. A new office joining the group is one more wave-of-one; the intake sequence around it is in DSO Marketing: The Operations Layer.

Rollout timeline at a glance

For a 20-location group on 2–3 EHRs: pilot (2 weeks) → template hardening (1 week) → five waves of ~4 locations (1–2 weeks each, overlapping) → fully live in roughly 10–12 weeks, with every location having passed the same ten gates. Faster is possible; faster without gates is how groups ship the 2 a.m.-slots bug at scale.

Actually doing the marketing

Once booking is live everywhere, point demand at it: booking CTAs on every location page and GBP listing, ad campaigns landing on pages where the widget is one tap away, and budget steered by per-location cost per booked appointment — the metric this rollout just made real. (Nowhere does this matter more than same-day demand — see urgent care marketing, where a booking flow that isn't one tap away simply loses the visit to whoever's is.) The full operating rhythm is in Multi-Location Practice Marketing and the enterprise pillar, all HIPAA-compliant by default per the compliance guide.

Or have us run the rollout: PilotPractice ships the widget, the 30+ EHR/PMS integrations, the slot QA tooling, and the team that has walked these gates at hundreds of practices — pilot to full fleet, with the marketing layered on top. Book a demo and bring your EHR list; we'll sketch your wave plan on the call.