Protected case study

This case study is password protected

It covers confidential client work. Enter the password you received to view it.

← Back to all work

Discovery • Prototype • Product design • 2026

Standalone booking: from idea to decision

Role

Senior product designer, booking lead

Team

Booking PM, sales, product and market leads

Timeline

8 weeks, 2026

Status

Approved, on the 2027 roadmap

Turning a years-old idea into a clear build or no-build decision, with research across five European markets, an evidence-backed MVP and a working calendar prototype in 8 weeks. Now on the 2027 roadmap.

The problem

In many European markets, clinics still book appointments by phone. Patients call, wait on hold and sometimes need a callback. Front-desk staff spend hours on the phone, and cancelled appointments go unfilled.

BeeHealthy’s booking module works well, but it’s built to connect to the clinic’s EMR. In markets where EMRs are scattered, old or hard to connect to, that integration is the blocker. Standalone booking removes it: a live calendar, self-service booking and reminders that work on their own.

The idea had been talked about at BeeHealthy for years but never built. My job was to turn it into something concrete enough for leadership to say yes or no to.

Front-desk day view with every practitioner side by side

The front-desk calendar: every practitioner side by side, with open slots and reminders in view.

My role

I led the project as senior product designer for the booking module. I owned the research, the market matrix, the feature list and its rationale, the prototype and the final presentation. I worked with the booking PM and with sales, product and market leads across Germany, Italy and Sweden, plus field input from a colleague with experience at a major competitor.

The thesis

Standalone booking makes sense in markets where EMR systems are scattered or outdated, and where no competitor has already locked up booking for mid-to-large clinic groups.

Two framing choices shaped everything after. First, I built the case around a market condition rather than a country. Germany had the most evidence, so it became the reference market, but the matrix, rationale and prototype were all set up around EMR maturity so the case could scale. Second, I kept public and private care in view together. Building only for private clinics felt like a mistake, even where public care needs extra integration.

How I planned it

I was asked for four linked deliverables: a market matrix, a feature list with rationale, a prototype and a decision package. I planned them in that order on purpose, so the prototype would only show what the evidence backed.

A few rules held the work together. Every claim traced back to a source, and guesses were labelled as guesses. I tested each matrix row on one or two markets before rolling it out. And I named our known bias early: internal interviews only reflect deals we’d won or lost, so desk research on EMR maturity was the counterweight.

8-week project timeline

Eight weeks, four linked deliverables.

Picking markets that could prove me wrong

I chose comparison markets at different points on the EMR-maturity range: some to check that the pattern repeats, and some to check that the need drops off where EMRs are already joined up. Each market was scored on EMR maturity, competitors, who pays for care, how clinic groups buy, local booking rules and evidence confidence.

Germany and Italy came out convergent. Spain and Sweden came out divergent, and that was just as useful: it showed leadership where the product doesn’t fit, not only where it does.

Market matrix with verdicts per market

The market matrix, simplified: where the thesis holds and where it breaks.

What I learned from the matrix:

  • EMR fragmentation predicts fit better than overall digital maturity, as long as the target segment hasn’t already standardised on bundled platforms.

  • Where competitors choose to expand is a stronger signal than maturity indexes or academic scores.

  • High national digital maturity can hide fragmentation at the clinic level, as in Sweden.

  • A shortcut, booking into a competitor’s calendars through its partner API, came out weak: we’d give up the patient relationship for a per-booking fee.

From features to what clinics measure

The core problem was simple: replace phone and callback booking with a live self-service calendar and reliable reminders. Everything in the MVP exists to make that loop trustworthy for both staff and patients.

To make the feature list easier to judge, I mapped each feature to a result a clinic cares about. The first pass showed the MVP was strong on no-shows and slot use, and thin on bringing in new patients. I flagged those gaps instead of hiding them.

Features mapped to customer KPIs

Mapping features to the results clinics measure showed the MVP was thin on new patients.

Priorities tied to evidence

Every capability had to pass two checks: it helps clinics stop booking by phone, and it works without any EMR integration. Then it got a priority based on how strong the evidence was. Must haves had strong evidence or were basic calendar needs. Should haves had medium evidence, mostly from internal interviews. Could haves were bets, clearly marked as bets to check with clinics before they go in.

Each row also carried its evidence rating, the markets that back it and its key open question, so the team could see how sure we were about each item, not just what was on the list.

Priorities tied to evidence strength

Two gates, then a priority set by the strength of the evidence.

Reframing the competitive story

On the core booking loop, the MVP matched the two big European booking platforms. My first slide showed the feature gaps around it, which made us look weaker than we were.

I turned it around. The booking calendar is a must-have, but it won’t win deals alone. BeeHealthy’s edge is the platform around it: digital clinic, care plans, records, forms and payments, which clinics get alongside booking.

Competitor slide before and after the reframe

Before and after: from a feature gap to the breadth of the platform.

The prototype

In the last two weeks I built the core booking loop as a working calendar prototype for front-desk staff, plus an animated walkthrough. It shows the flows the research said matter most, end to end.

A live front-desk calendar. Every practitioner side by side, with open slots, no-shows and reminders in view, so staff can answer the phone and book in seconds.

Week view for one practitioner

Week view for a single practitioner.

Booking that finds the time for you. Staff search a patient by national ID or name, pick a patient type, and either choose a practitioner or let the calendar suggest the next open times. Online booking rules, like minimum notice, are shown right in the form.

New booking with suggested times

New booking: pick the patient, then let the calendar suggest open times.

Sick leave without the phone marathon. When a practitioner is out, staff block the time. Overlapping bookings are marked Rebook instead of disappearing, and one action texts every patient a link to choose a new time themselves.

Bookings marked Rebook with the rebooking list

Overlapping bookings stay in the calendar, marked Rebook.

Rebooking SMS sent to every patient

One action texts every patient a link to choose a new time.

Filling cancelled slots. When a slot opens, the calendar shows who asked for an earlier time. Staff can offer it by SMS or move a patient straight in after a phone call.

Offer an earlier time panel

Offer an earlier time to the patients who asked for one.

Rooms, equipment and reminders. Staff can block an X-ray room so only the affected appointment types are hit, and send all upcoming reminders in one go.

Blocking an X-ray room

Blocking a room or piece of equipment only affects the appointment types that need it.

The outcome

Leadership said yes. Standalone booking is now on the product roadmap for 2027.

The project ended with a full decision package presented to product and design leadership: the market matrix, the capability list and rationale, country research, the KPI mapping, the competitor comparison, the prototype and walkthrough video, and an 11-slide deck.

  • A years-old idea became a concrete, evidence-backed MVP scope the team could react to.

  • The matrix showed where standalone booking fits and where it doesn’t, so leadership could see the limits as well as the opportunity.

  • Stakeholder reviews surfaced scope questions early, such as whether public bookings in Italy need integration with regional booking systems.

What’s still open

I left the next phase with clear questions rather than false certainty: do clinics see the bets as needed, what’s behind EMR fragmentation in Germany, how smaller clinic groups buy in Italy, and how the largest private groups book in Sweden.

What I learned

The most useful thing I did was choose markets that could break the thesis. A case that only shows where an idea works is easy to argue with. Showing where it stops is what made the yes believable.