The context

BeeHealthy is a white label health platform. Healthcare providers launch it as their own branded app on iOS and Android, and booking is one of the main reasons patients open it.

Every customer brings something different: their own brand, their own patient record system, their own booking rules. A private clinic chain, a public health centre and a physiotherapy practice all want the same thing from the patient’s side, a quick way to find a time and book it, but the way they get there is never the same.

My role

I design the patient-facing booking experience on iOS and Android. Most of the work isn’t one big project. It comes in as a steady stream of customer needs, support issues and new appointment types. My job is to fit each one into the product without breaking what already works.

One flow, configured, not forked

With many customers on one product, the easy answer to every request is a new screen. Do that often enough and you end up maintaining many apps instead of one. So I held every new need to the same question: can this be a configuration of the core flow instead of a new flow?

The core flow stays simple: search, see the soonest times, pick a date and time, confirm. Everything else on this page builds on it.

Search by professional or specialty, see who’s available soonest, then pick a date.

Pick a time, review the booking, confirm. The same steps every customer’s patients see.

Different customers, same search

Customers structure their services in different ways. Some describe care by specialty and professional, straight from their patient record system. Public sector customers group services into categories, like a child health clinic.

Instead of two search experiences, I designed one three-level search: who or what, then the service, then the place. The layout and behaviour stay the same, and each customer’s data fills the levels.

Two set-ups, one layout. Filling all three levels narrows results to the right service and place.

Booking tickets: guided booking

Some care has to be booked within limits: a follow-up within four weeks, with a specific professional, at a specific clinic. Clinics send patients a booking ticket that sets those limits.

The ticket reuses the normal booking flow. Fields the ticket sets are locked, and the app says why, so patients aren’t left wondering why they can’t change the search. Only times inside the booking window show up. Clinical back-end fields stay hidden.

From the ticket on Home to a time inside the booking window, through the same flow as any booking.

Booking for a guest

One of our key customers needed patients to book care for someone who isn’t in the app yet, like a relative or a child. The guest has no account, so the app has to identify them before anything can be booked.

The user starts with the guest’s ID number or passport and contact details. We verify them, look for a matching profile and add the guest to the user’s family profiles. From there, it’s the normal booking flow.

Enter the guest’s details, confirm the match, and the guest joins the family profiles.

The hard part was everything in between. The details might match an existing profile, match nothing, already be on the account, or fail validation. Each outcome got its own screen with one clear next step.

And when the profile can’t be created because of a technical problem, booking still works. The user continues in a guest booking flow, a banner on every step shows who the appointment is for, and the confirmation goes by email.

When things go wrong, booking still works, and every error has one clear next step.

Series and group sessions

New appointment types came in from customers: therapy that runs as a weekly series, and classes where several patients attend together. Both reuse the same select-time and confirm steps. What changes is what the patient needs to know first.

Series. The patient picks when the series starts, not every session. The booking keeps the first session in focus, with the rest one tap away.

A series is booked as one decision: choose the start date, confirm, see every session.

Group sessions. The first question is “will I be with others?”, so the group label and places left are on the result card and on every time.

Booking talks to each customer’s own patient record system, so things can go wrong in ways the app doesn’t control. Someone else takes the time while the patient is choosing, or the record system doesn’t answer.

Every error says what happened and gives one clear next step. A taken time sends the patient back to the times with a note explaining why. A failed booking says plainly that nothing was booked, with customer service as the fallback.

Confirming, time taken, back to times, booking failed.

Also in the flow

Smaller pieces built on the same patterns:

• Cancel and reschedule from the appointment details, with the old and new time side by side.

• Book again from an archived appointment, straight to times with the same professional.

• Browse as a guest and sign up only at the point of booking, with the chosen time kept.

Confirm cancel, confirm a new time, book again, book as a guest.

The outcome

This is the booking flow patients use every day, across every brand the platform runs under.

• Around 5,000 bookings a day go through it.

• It’s widely used for booking in Finnish public healthcare.

• It powers healthcare providers globally as part of BeeHealthy’s white label platform.

It scales because new customer needs are added as extensions of one flow, not as new screens. Each new provider gets the same booking experience, under its own brand.

What I learned

In a white label product, the best design work is often invisible. The question isn’t how a screen looks for one customer, but whether the pattern still holds when the next customer, brand or rule arrives.