What a dental CRM has to track for full-arch, and what yours doesn't

Open the practice management software in a full-arch office and look at what it is confident about. Appointments. Recall intervals. Production posted per visit. Insurance.

Now look for the enquiry that came in during March, spoke to three different people, went quiet for six weeks, and either turns into a $30,000 case in June or does not. There is no object for that. So it lives in an inbox, a spreadsheet somebody maintains, and memory.

Your software models a visit. A full-arch case is a decision.

Hygiene and restorative work fit the appointment model cleanly. The patient comes in, something gets done, production posts against the visit, and the recall interval brings them back. Every mainstream dental CRM is built around that loop, because that loop is most of dentistry.

Full-arch does not behave like that. It is one decision, made over weeks, usually involving someone who was never in the room, frequently gated on financing, carrying a value somewhere in the $20,000 to $45,000 band. The consult is a milestone inside that decision rather than the unit of work.

When there is no record for the decision itself, the practice can only be told about the milestones. You can pull a report on consults seated last quarter. You cannot pull one on the eleven enquiries that never got that far, because nothing about them was written anywhere a query can reach.

Make the enquiry a record with a state

The smallest change with the biggest return is giving every full-arch enquiry its own record the moment it arrives, with a stage on it that somebody has to move.

A workable set of stages: new, contacted, qualified, consult booked, consult seated, plan presented, financing pending, started, lost. Nine is not a magic number and your practice may need seven. What matters is that each stage is a real state a patient can be in, and that moving between them writes a timestamp.

Those timestamps are the whole point. Once they exist you can see that enquiries sit an average of nine days between plan presented and financing pending, and that the ones sitting longer than three weeks almost never start. Nobody can see that from a calendar. The stage list also forces a decision the practice usually avoids: every enquiry has to end somewhere, either started or lost. The ones quietly aging in the middle are the ones that were never counted as losses, and they are usually the biggest group.

The fields that are not in the default setup

The five things a front desk should be collecting on the first call are worth nothing if they land as a free-text note. “Wants implants, spoke Tuesday, will think about it” is indistinguishable from an empty record as far as any report is concerned.

So these need to be actual fields, with picklists where a picklist is possible:

Expected scope and case value band. Single arch, dual arch, still unclear. Attached to a value band rather than a guessed number, because bands are what let you forecast without inventing precision you do not have.

Financing status, with its own dates. Not applied, applied, approved, declined, self-pay. This is the field that explains the gap between a signed plan and a scheduled surgery, and it is almost never modelled anywhere.

The other decision maker. A spouse, an adult child, whoever the case actually gets decided with at home. A yes or no field is enough to make it countable.

Loss reason, from a fixed list. Cost, candidacy, timing, went elsewhere, no contact, no reason recorded. That last option has to exist and it has to be used honestly, because the size of it tells you how much of your pipeline data you can trust.

Free text is where all of this normally dies. It is not that the notes are wrong. It is that nothing written in prose can be grouped, counted, or compared across a quarter, which means it can never turn into a decision about where to spend.

Source is the field that breaks first

Every practice thinks it tracks source. Almost none of them do it in a way that survives the journey.

Two failures cause most of it. The first is overwriting: the record says “phone” because the last person to touch it took a call, when the enquiry actually started as a paid social ad three weeks earlier. The second is a picklist where “Google” is a valid answer, which merges organic search, paid search and the map pack into one meaningless bucket.

Store two fields and never let a later touch edit the first. The original tracked source, captured at creation and locked. The patient-reported source, asked in conversation, stored separately. They will disagree, often. The disagreement is itself useful, because it tells you which channels get credit in the patient’s head versus which ones actually did the work.

Without this, judging whether a channel pays comes down to opinion and whoever argues hardest in the meeting.

The reports these fields exist to produce

Fields nobody reports on stop being filled in, usually inside a month. So build the reports first and work backwards.

Consult-to-close by source, with expected case value attached, is the one that changes budget decisions. A channel producing plenty of consults that close at half the rate of another is a worse channel even when its cost per lead looks better.

Median and 90th percentile time in each stage is the one that changes operations. The tail is where cases are lost, and the tail is invisible in any average.

Then loss reasons, counted, month over month. This report is uncomfortable the first time you run it and it is the reason the rest of the system is worth building. A practice that discovers a third of its losses are filed as “no reason recorded” has learned something more actionable than any close rate.

None of this requires new software in most cases. It requires deciding that the enquiry is a first-class object in whatever system you already run, and that somebody owns keeping it accurate. Our lead qualification work writes into the systems practices already have for exactly that reason. The tool is rarely the constraint. The missing record is.