The Owner's Morning Brief
One short list, before the first patient, of what is overdue, what failed and why, and the few things that genuinely need the owner. Assembled from what the other six systems actually did, not from what anyone reports.
- Tier
- Flagship
- Build order
- 7th of 7 for dental practices
- Shape of it
- 9 steps, 1 decision point, 1 escalation rule
- At launch
- Runs supervised, with you approving what goes out
The problem this solves
In a practice this size the owner is the escalation path by default, and they are also in a room with a patient for most of the working day. So things reach them at the end of the day, or at the end of the month when the numbers come in, by which point the fix is expensive.
The reporting that exists does not help. Practice management dashboards show production and collection, not exceptions. A production number does not tell an owner that eleven thousand pounds of accepted treatment has had no contact in three weeks, that the hygiene column has four holes next Tuesday, or that a flagged clinical question has been sitting unanswered since yesterday afternoon.
And the softest failure of all: people raise a problem when they are certain they cannot fix it themselves. By then it is a week old.
How it works, step by step
Every wait, threshold and branch below is a value we set with you during the build, against your stages and your language. None of it is a default we impose.
- What starts it
- It decides something
- It escalates to a person
Step 1Trigger
Every morning, before the first patient, one brief is assembled and sent.
Step 2
It is ordered by what needs a decision, not by category.
Step 3Escalation
Needs a clinician, now: any flagged clinical question not yet answered, and any triage item on the top rungs that has not been acknowledged. This is always first and it is never batched.
Step 4
Overdue: enquiries with no outcome, treatment plans past their next-contact date, unconfirmed appointments for today and tomorrow, verifications that could not be completed.
Step 5
Failed, and why: messages that did not deliver, forms not returned, claims rejected, automations that errored. Each with the reason, not just a count.
Step 6
Today's schedule risk: open chair time in the next forty-eight hours, by column and value, so it can still be filled.
Step 7
Unscheduled treatment by age band and value, which is the one number that changes how an owner spends their week.
Step 8
Nothing in the brief is self-reported. Every line traces to an event in a system and links to the record.
Step 9Branch
If there is nothing to raise, it says so in one line rather than padding itself.
How it gets built
Built inside what you already run
- Dentrix
- Eaglesoft
- Open Dental
- Curve
- or whatever your office already runs on
Nothing to log into and nothing to license. If a system needs a record your platform does not hold, we add the field to your platform rather than starting a second one beside it.
This is the actual build order, in the phases its own steps fall into. It runs in supervised mode first, with you approving what goes out, until you are happy with the tone.
- 1
Agree
Agree with the owner what genuinely requires them, and be strict. A brief that lists everything gets skimmed, then ignored.
The thresholds, the wording and the names are yours. We write them down with you and get the consequential ones signed off.
- 2
Agree
Set the thresholds: the treatment value above which they are told, the age at which an unanswered enquiry is raised, the amount of open chair time worth waking up to.
- 3
Build
Build the exception queries against system event data, not against the PMS dashboard.
Built inside the software you already run, against your stages and your language.
- 4
Agree
Set the send time against when the owner actually reads, which in this trade is usually before the first patient rather than the night before.
- 5
Prove
Review the brief with the owner weekly for the first month and cut every line they did not act on. It should get shorter, not longer.
It runs with a person approving what goes out until you are happy with the tone. Nothing sends unreviewed on day one.
What changes after it goes live
How it runs today
In a practice this size the owner is the escalation path by default, and they are also in a room with a patient for most of the working day. So things reach them at the end of the day, or at the end of the month when the numbers come in, by which point the fix is expensive.
After this one is live
Problems surface at a day old rather than a week old. Clinical questions stop waiting for somebody to notice them. The owner stops being the person who finds out last, and stops having to ask. And because it is assembled from events rather than from people, it does not depend on anybody being willing to raise something uncomfortable.
How to measure whether it worked
Your arithmeticRun with your numbers, not ours
This one does not have a revenue calculation and should not be given a fake one. It is the system that makes the other six trustworthy. The honest way to value it is to ask the owner what one week of an unattended problem has cost them before. They will have an example, and it will usually be clinical.
We agree the baseline before anything is built, and we do not take credit for things that were going to happen anyway. There is no figure on this page claiming what we have produced for somebody else, because there is no verified figure to publish.
What we will not do
This is from the same delivery document as everything above it. It is on the page because a supplier who has not thought about it will not tell you, and you would find out later.
Every system here touches protected health information and sends automated messages to patients in the United States. Two separate regimes apply and satisfying one does not satisfy the other. HIPAA governs the information and the vendors. The TCPA governs the calls and texts.
HIPAA
A dental practice transmitting claims or eligibility electronically is a covered entity, and its patient information is PHI.
- A signed Business Associate Agreement with every vendor that creates, receives, maintains or transmits PHI, before that vendor touches any of it. This includes the messaging platform, the SMS gateway, the hosting provider, the CRM, any analytics tool and any AI service in the path. The narrow conduit exception covers transmission-only services with no routine access; it does not cover an ordinary patient-engagement or automation platform.
- Minimum necessary. Send the fields the system needs, not the chart. A reminder needs a date, a provider and a contact number. It does not need a diagnosis.
- What goes in an unencrypted message. HIPAA does not ban PHI in SMS or email, and HHS explicitly permits appointment reminders without authorization. What does not belong in one: diagnoses, clinical findings, procedure names that reveal sensitive treatment, radiographs or images, medication details, insurance or balance information, and anything about a second patient.
- Offer and honour confidential communication requests. A patient can ask to be contacted a different way, and that request has to reach every system.
- Treatment, payment and operations do not need an authorization. Recall, appointment reminders, pre- and post-operative instructions, and a request to schedule treatment already recommended are ordinarily treatment-related. Promotion is different. "Book this month and save" is marketing whatever list it went to, and calling a sequence a recall does not make it one if the purpose is to sell.
- Financial remuneration changes the analysis. If a third party pays the practice or a vendor for a communication, HIPAA's marketing rules can apply to something that would otherwise be operations.
- Audit logs, role-based access, retention limits, a documented risk analysis and an incident response procedure, all of them boring and all of them the first thing asked for if anything goes wrong.
TCPA
HIPAA permission is not TCPA consent.
The FCC's healthcare treatment exemption can reduce the consent standard for messages from a covered entity, but it is narrow and it comes with hard conditions that shape every sequence in this playbook:
- Only to the wireless number the patient gave the practice.
- The provider's name and contact information in the message.
- Concise: generally no more than 160 characters for a text.
- No cost to the patient.
- One message per day, and no more than three per week, counting calls and texts together.
- An easy opt-out, honoured immediately.
That frequency limit is a design constraint, not a footnote. It is substantially stricter than what a normal marketing automation would send, and it means every sequence in this document has to be sparse and every message has to earn its place. A five-touch week is not an aggressive cadence here. It is non-compliant.
The exemption does not cover advertising, promotional offers, solicitation of new services, billing or debt collection, or anything unrelated to the patient's care. Those need consent on the ordinary standard, captured and documented per channel and per purpose. A phone number in the chart is not blanket permission for promotional automation.
The line that is never crossed
No automated system answers a clinical question. Ever. Not whether it will hurt, not whether a symptom is normal, not what medication to take, not whether treatment is needed. Every one of those routes to a clinician, and the patient is told a person is being reached. Every classifier in this playbook errs toward escalation, and every one of them is tested against deliberately ambiguous messages before it goes live.
Nothing in this document is legal, clinical or regulatory advice. State privacy and telemarketing law, dental board advertising rules, payer contracts and the exact sending technology can each add requirements, and this area has moved more than once recently. Every template stating a clinical or commercial term requires review by the practice's own counsel before it goes live.
Nothing here is legal advice. Rules in this area have moved more than once recently, and every template that states a commercial term or a guarantee goes to your own counsel before it goes live.
Seven systems fordental practices.
We build one at a time and prove it moved before starting the next. The tiers are the dependency order, not a price list.
Tier 1Foundational
Nothing arrives late or unowned. These come first because everything above them assumes they are true.
Tier 2Growth
The recoverable money. These work the pools the foundational systems have made visible for the first time.
Tier 3Flagship
One connected system end to end, plus what the owner reads on a Monday. Only once the pieces are proven individually.
- 5The Complete New Patient JourneyThe flagship, once the pieces are proven individually.
- 6Recare, Reactivation & Benefit TimingCompounds everything above, and depends on the required booking step System 5 introduces.
- 7The Owner's Morning Briefyou are hereOnly meaningful once there are systems to report on.
The tiers are the dependency order for dental practices, not a price list. Most firms do not start at the first one, because the order is a default and the call is where it gets changed.
A note on sequencing this trade
Do not build all seven at once.
Each stage is proven against its agreed measure before the next begins.
One sequencing note specific to dentistry. System 4's existing backlog should be worked by hand in week one, before any of it is automated. It is the fastest money in the engagement, it proves the value of the whole programme before a single sequence goes live, and working it manually is what tells you what the five branches should actually say.
Back to the dental practices overview for the stage map and where these fit.
Is this the oneyou need first?
Often it is not. On the call we look at what is actually costing you most right now, which is frequently a different system from the one that brought you to this page. If there is nothing worth building yet, we will say so.