Online Booking With SimplePractice Across Multiple Offices: The Provider-to-Office Problem

If your therapy or psychiatry group runs SimplePractice across more than one office, online booking has a problem that is not obvious until you set it up: SimplePractice has no setting that says which office a clinician works in. Not on the team-member record, not on availability, not under any role, admin included. The office exists only on individual appointments. So any booking page that lets a client choose an office and then a clinician has to work out the clinician-to-office relationship from booking history, and someone in your practice has to confirm it before it goes live.

This is not a niche edge case. SimplePractice was the largest single source of synced appointments across several hundred practices in the last twelve months (KloudMD platform data, Sep 2025 to Sep 2026), and therapy groups are among the most likely practices to have clinicians who float between offices or see clients only by telehealth. Get the mapping wrong and a client books an in-person session at the office a clinician is not in that day.

What SimplePractice does and does not store

Verified against the SimplePractice interface under every role, including account owner:

Data	Where it lives in SimplePractice	Usable for multi-office booking?
Clinician record	Name, email, roles, NPI, taxonomy, photo, permissions	No office field
Clinician availability	Tied to the practice and the clinician	Hours per clinician, not per office
Office	Only on each appointment (office id and name)	Yes, but only as history
Telehealth / virtual	An office type on the appointment	Yes, but it carries no state

Two things follow. First, the only signal for “where does this clinician work” is where they have been booked. Second, availability sync gives you hours per clinician, not hours per clinician per office. If a clinician does Mondays in one office and Thursdays in another, SimplePractice knows their hours but not the split.

A common misunderstanding worth heading off: upgrading the integration’s role to admin does not expose offices. There is nothing to expose.

How the mapping gets inferred

The workable approach is to derive the clinician-to-office mapping from synced appointment history: a clinician is considered to work at an office when they have at least one non-cancelled synced appointment there. Run nightly, this keeps up with a clinician who starts taking sessions at a second office. Telehealth appointments come back as a virtual office with no state attached.

Inferred history is right most of the time and wrong in exactly the cases that matter for a growing group:

• New hires have no appointments yet, so they have no inferable office.
• Clinicians who recently changed offices still show the old office in history.
• Floaters show up in every office they have ever covered, including one-off fill-ins.
• Telehealth-only clinicians should never appear under a physical office, but may if they did one in-person intake a year ago.

The confirmation step you should insist on

Because history is only a guess, the mapping must be confirmed by someone at the practice before booking goes live, and again whenever a clinician or office is added. The format that works is a simple table you review in a few minutes:

Clinician	Offices inferred	Booking history the inference rests on	Practice confirms
Clinician A	Downtown	Consistent, every week	Correct
Clinician B	Downtown, Northside	Consistent at Downtown / a handful at Northside	Downtown only; the Northside sessions were fill-ins
Clinician C	Telehealth	Consistent, every week	Correct, virtual only
Clinician D (new)	Unmapped, needs your answer	None yet	Northside, Tue and Thu

Three rules for reading it. A clinician with no booking history is listed as unmapped and is not guessed at, and is never attached to every office “to be safe.” A handful of appointments in a second office is a flag, not a mapping. And the confirmation is recorded (who, when), so when the booking page shows a clinician somewhere unexpected six months later, you can see whether the mapping or the practice changed.

What the booking page should do with the mapping

Once the mapping is confirmed, the online booking flow for a multi-office SimplePractice group looks like this:

1. Client chooses a service (for example, an initial intake versus an ongoing session), which sets the duration and the SimplePractice service code.
2. Client chooses in-person at a specific office, or telehealth.
3. The page shows only the clinicians mapped to that office (or to telehealth) who offer that service.
4. Availability is the clinician’s SimplePractice hours minus their existing appointments, across all offices, because SimplePractice only knows their hours as a whole. A clinician cannot be in two offices at once, so blocking on their full calendar is correct.
5. The booking is created in SimplePractice with the correct clinician, service, true visit duration, and the chosen office on the appointment, which in turn feeds tomorrow’s mapping derivation.

Step 4 has a subtlety. Because SimplePractice hours are not split by office, the page cannot stop a client from booking Clinician B at Downtown on the one day B is physically at Northside, unless you add that rule yourself. For clinicians with a fixed day-per-office pattern, configure per-office days in the booking tool so the page only offers Downtown slots on Downtown days.

Reschedule, cancel, and the office

When a client reschedules, the same appointment in SimplePractice must be moved, not cancelled and recreated, and it must keep its office. A proper integration proves this before go-live by creating a test appointment in a specific office, moving it to a new time on the same appointment id, and then cancelling it, watching SimplePractice the whole way. If your vendor cannot show that, expect clients to reschedule online while SimplePractice keeps the old time. More on why that step is hard: why reschedule and cancel are the hard part.

Intake and matching across offices

A multi-office group also has multi-person households. A parent may book a teenager’s session from the parent’s phone and email. SimplePractice client matching should use the client’s name and date of birth together with the contact, never the phone or email alone, or the appointment lands on the parent’s record. The booking form should therefore collect the client’s name and date of birth even when the contact details belong to someone else, and record the relationship. See why matching patients by phone alone fails for the general rule.

Why this is worth doing anyway

The alternative to solving the mapping problem is a request form and a callback, and the platform data on demand timing argues against that: 44% of web new-patient requests arrive outside 8am to 5:59pm, 28% in the evening and 16% overnight, and volume is nearly flat from 8am through 9pm, with the 9pm hour still within about 15% of the daytime peak (KloudMD platform data, Jun to Sep 2026). For a therapy practice, the evening inquiry is the norm, not the exception, and the person sending it is comparing several practices. A real time, held in the calendar, is what stops the comparison.

There is also a scheduling reason to prefer booked time over requested time. Across about 160,000 appointments booked through the platform over twelve months, no-show rates with reminders on were 2.1% to 2.9% regardless of how far ahead the booking was made. Cancellations, by contrast, rose from 3.9% for same-day bookings to 12.9% for bookings two or more weeks out. For therapy groups with long intake lead times, that means the cancel path, and the freed slot reappearing on the booking page quickly, matters as much as the booking path.

Checklist before you turn on multi-office booking

• Every bookable clinician appears in a clinician-to-office table with the appointment count behind each mapping.
• Someone at the practice has confirmed or corrected every row, and unmapped clinicians have an answer.
• Telehealth-only clinicians are mapped to virtual only.
• Fixed day-per-office patterns are configured for floaters.
• The booking form collects the client’s name and date of birth, plus relationship when someone else is booking.
• A create, reschedule, and cancel have been proven on a test client in SimplePractice, in a specific office.
• You know how mapping changes are handled when you hire or open an office (same table, same confirmation).

How KloudMD handles this

KloudMD’s SimplePractice integration syncs appointments and cancellations in both directions, keeps the service menu, clinician schedules, and client records mirrored, and writes bookings into SimplePractice with the correct clinician, service, true visit duration, and office. Because SimplePractice has no clinician-to-office setting, KloudMD derives clinician-to-office mappings nightly from non-cancelled synced appointments, presents them as a table with the appointment count behind each mapping, and treats them as unconfirmed until the practice confirms or corrects them, before go-live and whenever a clinician or office is added. Clinicians with no history are flagged for an answer rather than guessed. Client matching uses name and date of birth with the contact, and every integration is proven with a create, reschedule on the same appointment, and cancel before it is live. See the SimplePractice integration page and online scheduling, and for phone bookings the same channel powers Voice AI.

Get started with KloudMD and we will build your clinician-to-office table from your SimplePractice history for you to confirm.