Client case · Bitrix24

Dental clinic with an in-house laboratory: how we connected the clinic, the workshop, and the documentation in a single CRM

A multi-location dental clinic with its own lab — four functional blocks, one order, and zero transparency. We built the process from scratch in Bitrix24.

~40people in the team, active users in the system
30control points in a single order
10 secto answer where a patient's work is now
3smart processes connected to the main pipeline

About the client

A multi-location dental clinic in Romania with its own in-house dental laboratory. The team consists of about 40 people: dentists, technicians, patient managers, call-center operators, a photo-video team, marketing, and management. The model is B2C: a patient comes in for treatment, the dentist designs a prosthetic work where needed (crown, bridge, denture, zirconia construction), the order goes to the in-house lab, and after fabrication returns to the dentist for placement.

The business specificity is vertical integration. The lab is not external — it is part of the clinic. This gives control over deadlines and quality but creates a unique operational challenge: a single order passes through four functional blocks (front office → dentist → laboratory → production workshop), and any communication breakdown between them turns into a delay.

What the client came to us with

Before Bitrix24 the clinic had a picture typical for the industry: patients lived in the medical information system, prosthetic orders lived on paper job tickets that technicians physically carried between rooms. Work statuses were tracked in Excel or “from memory”. Photo materials (“before/after”) were collected chaotically.

Main pain points:

The clinic evaluated options: a specialized laboratory system, customizing the existing medical information system, a separate CRM for orthopedics. The choice fell on Bitrix24 for three reasons: a unified workspace for the whole team, a deeply configurable CRM for non-standard processes, and a total cost of ownership incomparable with industry-specific software licensing.

The client came to us through a referral. An additional argument was that we agreed to build the process from scratch around their real operations, rather than forcing the business into a pre-built template.

How we built this

First — the map of the real process

Before configuring anything, we ran three working sessions — separately with managers, separately with dentists, separately with the lab. The goal was to put the real process on the table, not the one imagined by management.

What emerged: a single order has up to 30 control points — from the job ticket number and Vita shade scale to the inventory of physical components (impressions, screws, articulators). Zirconia works differ technologically from metal-ceramic so much that they cannot be pushed through the same pipeline. The production workshop is a separate world with its own operations, and a single customer deal can spawn several production units.

Architecture: pipeline plus smart processes

We built a multi-level model in Bitrix24.

This model solves three problems at once: the patient manager gets a single interface “I see everything about the order”, the lab works at its own level of detail, management sees aggregated analytics.

Bitrix24 deal card with the dental lab pipeline and patient job ticket
The digital lab job ticket in Bitrix24: the pipeline with work stages, order data and the production checklist (data anonymized).

The digital lab job ticket

We moved the paper ticket into Bitrix24 as a set of custom deal fields, grouped into logical blocks: identification and deadlines, work parameters, clinical part, production checklist, end-to-end readiness, photo protocol, external integrations, and inventory of physical components.

The last block — about inventory — is often underestimated, and unfairly so. If an impression or a screw gets lost between rooms, without tracking you find out too late. That's why every component of the deal is described: how much was sent to the lab, how much came back.

Bitrix24 as an orchestration layer

A principled decision: Bitrix24 works not as an “all-in-one” system, but as a coordination layer on top of specialized systems. We did not try to replace the radiology and digital imaging system, the cloud storage for scans, or the lab's CAD system.

Instead, bridge fields appeared in the deal card: patient ID in external systems, links to scan folders, CAD model file names. The manager sees in Bitrix24 that the patient folder is created, the scan is uploaded, the CAD model is ready — but the files themselves stay in the specialized systems where they belong. Trying to stuff X-rays into a CRM creates more problems than it solves.

The photo protocol as part of the clinical procedure

“Before” and “after” photos in dentistry are first and foremost clinical documentation: fixing the initial state, verifying that the result matches the treatment plan, legal protection in case of disputes. Marketing use is secondary, and only with the patient's explicit consent.

We embedded a photo checklist directly into the deal card. The manager sees four separate fields: “Materials BEFORE photographed? Uploaded? Materials AFTER photographed? Uploaded?” The photo-video operator gets a task at a specific deal stage. If the photo isn't captured, the deal doesn't move forward without a tick.

A side effect: the marketing team got a structured archive of “before/after” pairs tied to works, from which cases for publication are selected after the patient's consent.

What was difficult

To avoid idealizing, here are the real difficulties.

What's used daily

What this gave the client

Technical outline

What's in progress now

The implementation didn't end at “turnkey delivery”. Currently in active phase — configuring management dashboards with aggregated analytics on the production cycle.

This is the second phase of any serious implementation: the first stage gives transparency and order, the second automates what becomes visible and measurable after the first stage.

Who this is useful for

If you run a dental clinic with an in-house laboratory — you almost certainly recognized your own pain points in this text: paper tickets, lost impressions, unpredictable fabrication times, unsystematic photo protocol. The architecture transfers to similar clinics with minimal adaptations: the set of materials and types of works changes, the team composition changes, but structurally the process is the same.

The case is anonymized at the client's request. All structural indicators are real.

Want the same result in your clinic?

Let's discuss how this architecture applies to your processes — no pre-built templates.

Discuss your project