Doctoralia Pro: unblocking a stalled B2B SaaS expansion
Diagnostic facilities were a new segment Doctoralia Pro wanted, but the product was built around doctors. The project to bring them in had been stuck for over a year with nothing shipped. I joined the team hands-on, fixed how we worked, and redesigned service management and visibility in both products. We shipped in four months: CSAT rose from 3.9 to 4.3, unblocking hundreds of facilities to move to the new solution.
Type
B2B SaaS
, 13 markets
Overview
Doctoralia Pro was built for doctors and clinics. Diagnostic facilities work differently: their business is built around exams, not specialists, so describing each service precisely is crucial. The existing configuration did not fit them.
Target group: Diagnostic facilities
Role: Product Design Manager, working hands-on
Team: 15 people: PMs, developers, designers, stakeholders, operations
Timeline: 2024, shipped in 4 months
Company: Docplanner (Doctoralia Pro)
One company, two products
Docplanner Group runs two products in 13 markets. Doctoralia Pro is the SaaS where doctors and clinics manage calendars, services and visits. Doctoralia is the marketplace where patients find them and book.
Clinics run everything in the SaaS. The marketplace is one of the channels patients come through, a very effective one, next to the clinic’s own website, phone and walk-ins.
My case sits in both products
New service management and visibility touch two jobs on each side. For clinics: better visibility and easy booking – what they offer, at what price, with which doctors. For patients: finding the right care, deciding whom to trust, and booking a visit.
I redesigned both sides: how facilities set up their services, and how patients search for them, see them on profiles and book them.
Jobs of clinics and patients. Stars mark the features this case changed.
Why: a new segment that didn’t fit
Diagnostic facilities were a new customer segment. We wanted them, but they didn’t want us – not unless we redesigned service management and visibility.
The clinic profile was built around doctors: patients book a consultation with one of them. Diagnostic facilities often have no doctors to show. Services were a simplified price list, just extra information. For diagnostics, exams are the whole offer: many variants, referrals, prices by scope and time. And they must be bookable.
The clinic profile on the marketplace: (1) built around specialists, (2) service just as a price list.
How: fixing the workflow first
After more than a year, nothing had shipped. So I joined the team and fixed the workflow before designing anything.
I started by understanding the team: 1:1s with everyone, asking how goals and vision were understood, and observing how collaboration and communication worked. Three problems stood out:
Communication silos and proxy decision-making.
Lack of context for developers and operational teams.
Short-term fixes instead of a sustainable, long-term approach.
Then I introduced a product trio, a shared product vision, workshops and deciding together, and direct contact with stakeholders – no proxies, no silos. And continuous discovery: weekly interviews with facility managers, experiments and iterative work.
The problem: first too much freedom, then none at all
At first, facilities could add any service under any name, and it showed up in patient search. Patients got near-duplicates, weren’t sure which one to pick, and often landed on results with a single clinic.
So custom names were blocked. Facilities had to decide on visibility before adding a service: a strict name from the dictionary, locked forever, or any name that patients would never see. Both ended the same way: a call to customer support.
The old setup
In the product, each doctor had their own copy of the same service, one under another (1). On each copy, the name was locked and visibility was a switch (2).
Before: the facility manager's view in the SaaS.
Mapping before deciding
I facilitated a series of workshops with the merged team. We mapped both systems and how they connect. I also initiated weekly interviews with facility managers, gathered requirements, collected feedback and looked at the data.
Workshop boards: system maps, requirements, feedback and data.
The key decision: two jobs, two flows
I separated what a facility offers from where patients find it.
In the SaaS – the job of easy booking, in the facility’s own words. Any name, changeable any time. One service with many doctors’ agendas. No visibility decision; a service can stay internal.
On the marketplace – the job of visibility, in the patient’s words. To show a service, the facility links it to a category from our dictionary, like head MRI. Linking is optional and reversible, and search stays clean.
What I decided against
I chose not to make a facility’s own service name the one patients search for. On listings, patients pick from a short dictionary of basic names that match how they think about exams. On a facility’s profile, they see that facility’s own names and descriptions.
The new setup
One service, many doctors’ agendas, and visibility at a glance (1). In the service details, the two jobs are two sections: the service itself, under any name (2), and showing it to patients under a service category (3).
After: the facility manager's view in the SaaS – list of services.
After: the facility manager's view in the SaaS – service details.
For patients: the category first, then the clinic’s offer
In search, patients pick the basic name they have in mind, like head MRI, and see every clinic that offers it. On the profile, they read the clinic’s own options – head MRI with and without contrast – each with its own price, description and calendar.
Behind it, we initiated cleaning up the marketplace dictionary and merging search results under categories, with help from another dev team.
The clinic profile, before and after
Before, services were a price list with no booking form (1). After, services are grouped, with a Book button (2), and under one category patients see the clinic’s own options, each with its own price, description and specialists (3).
Before and after: the clinic profile on the marketplace.
Results
Shipped in 4 months, after more than 12 months without a release.
CSAT rose from 3.9 to 4.3.
Hundreds of facilities unblocked to migrate to the new solution.
Diagnostics became a new sales segment for Doctoralia Pro.
The team kept an ongoing feedback loop with facilities.
Beyond the screens
A backend logic refactor for how services display on the marketplace, removing internal complexity.
A long-term design direction that supports scalable, iterative updates.
Background: why I knew where it would break
In 2021, in Docplanner’s New Ventures unit, I built the first version of this business from scratch: a separate marketplace for diagnostic exams in Poland, Mexico and Brazil. I talked to facility managers myself and led all patient research, and several hundred facilities joined. So when the move into the core product stalled, I knew the facilities, the patients, and where the configuration would break.