Cases / Dental practices · Treatment plan platform
Client under NDA Planning and integrations

Three practices, twelve chairs: 75% of patients now finish their treatment plan, up from 50%.

50% → 75%
finish the treatment plan
+15–20%
chair utilisation
~2 mo
to the full loop

Client under NDA: industry and size are given as a range. The figures are the client’s own, comparing the periods before and after launch; comparable projects landed on both sides of these numbers. Run the numbers on your own volumes →

Context

The treatment plan lived in the front desk’s head, and the chair stood idle.

Three practices, twelve chairs, 30–40 staff. The dentist drew up a treatment plan at the appointment and from then on it survived on memory: the front desk kept a log and called patients whenever there was time. Around half of patients never reached the end of a plan — not because they changed their minds, but because nobody reminded them of the next stage in time. Weeks passed between stages where a few days would have done clinically. Chairs were allocated by dentist rather than by procedure, so a long piece of work could not find a window while short visits chopped up the day. Lab work was ordered by phone and tracked in a spreadsheet: whoever placed the order knew when the crown would arrive, and appointments were booked with a safety margin. The price of a plan, the split of payments across stages and any instalment arrangement were all worked out by hand.

Solution

Planning from the chair, not from the logbook.

Same stack as our other projects: Python and Django at the core, PostgreSQL as the source of truth for the patient, the stage and the chair. The platform knows how long each procedure takes, what equipment it needs and how long the external dental lab takes, and builds the schedule from that rather than from one dentist’s free time. The lab is connected by an order and status exchange, so turnaround time is an input to planning exactly like procedure length.

Architecture
Treatment planstages and timingChairs and dentistsavailabilityDental laborders and statusPaymentsstages and instalmentsPlatform corepatient · stage · chairSchedule3 practices · 12 chairsRemindersSMS · messengersPatient portalplan and paymentsAccountingpayments and write-offsStockconsumables
What we built

Six loops in two months.

The order was chosen by money: first what brings a patient back and fills a chair, then everything else.

01
The treatment plan as a route
The dentist writes the plan; the platform breaks it into stages — what the procedure is, how long it takes, what it needs, and how soon it can follow the previous one.
02
A schedule built from chairs and equipment
Visits are laid out by chair rather than by a dentist’s logbook: long work gets a window, short visits stop chopping up the day, and a free slot is filled by the next stage that fits it.
03
Coming back for the next stage
The system reminds the patient, not the front desk working through a log. The gap between stages fell from weeks to days, and around 75% now reach the end of a plan instead of roughly half.
04
The external lab
Orders for crowns, inlays and splints leave for the lab from inside the system, status and due date sit on the patient’s card, and the appointment is booked against the real date rather than a padded one.
05
Money by stage
The price of a plan is calculated automatically, payments are allocated to stages, and instalment arrangements run alongside the treatment plan and reach accounting without re-keying.
06
Hygiene visits and consumables
The six-monthly hygiene reminder goes out on its own, and consumables are written off against the procedure that used them rather than at a quarterly stocktake.
Before and after

Before and after.

Before
Finish the plan~50%
Chair utilisationbaseline
No-shows~15%
Gap between stagesweeks
Reminding patientsfront desk
Lab ordersphone and sheet
Payment by stageby hand
After
Finish the plan~75%
Chair utilisation+15–20%
No-shows~6%
Gap between stagesdays
Reminding patientsthe system
Lab ordersin the system
Payment by stageautomatic
Limits
What stayed with people, deliberately.
The treatment plan itself. The dentist writes it; the platform watches that it is followed, not what is in it.
Approving an instalment arrangement for a particular patient. The system calculates, a person decides.
Moving an appointment when a patient calls with a real problem. That needs the front desk, not an automation.
Accepting work back from the lab. Shade and fit are checked by the dentist.
Stack
Python Django PostgreSQL Practice system integrations Dental lab exchange Payments and instalments Monitoring and alerts
Straight about the bottleneck

We planned from the chair, not from the dentist.

Three practices, twelve chairs. A treatment plan stretches over months, but a chair stands idle right now, and it is the chair that caps revenue rather than the number of dentists. So the schedule is assembled from chairs and equipment: the system knows how long a procedure takes, what it needs and when the lab work arrives, and fits visits together so a gap is closed by the next suitable stage rather than by whichever patient happens to be free. The 15–20% came without hiring anyone and without adding a chair. The whole loop took about two months: a dental practice is process-wise simpler than a retailer, and the lab was the only outside system we had to agree an exchange with.

Related

What this case is made of.

The service pages explain the method behind this project; the solution pages take the same building blocks on their own, each with its own scope and price.

Want the same for your process?

A free mini-audit projects the ROI for your highest-impact process — then the build is a fixed price.

Get a free mini-audit →