intake.dental does not replace your practice management system, and setup does not involve a migration. The platform connects to the PMS you already run — Dentrix, Eaglesoft, Open Dental, or another supported system — and reads and writes data into it through the PMS's own interfaces, usually within seconds to a few minutes per transaction. Your PMS stays the single source of truth for the chart, the ledger, and the schedule; nothing about that changes.
Why "sits on top" is the right mental model
Every dentist who looks at a new front-office or clinical tool asks the same question before pricing: is this going to force us onto a new database, or make my assistants type everything twice? It's a fair question, because most practice software in the last fifteen years has been sold as a replacement — rip out the old system, migrate the records, retrain the team, hope nothing gets lost in the conversion.
We built intake.dental differently because we run our own offices on it. The platform is a layer, not a database. When a patient calls, fills out a form, or gets their insurance checked, that event happens inside intake.dental and then gets written into your PMS the same way a staff member would enter it — into the same patient record, same ledger, same appointment slot. You can review the full feature set to see which modules touch the PMS and which ones operate alongside it.
What syncs, in which direction, and how fast
Not every piece of data flows the same way. Some things originate in the PMS and get pulled into intake.dental for context; others originate in intake.dental and get pushed into the PMS as the record of truth. Here's the breakdown we actually run on:
- Patient demographics and appointment schedule — pulled from the PMS continuously, so the AI receptionist and online scheduling always see real open chair time, not a cached copy.
- Digital intake form answers — written into the matching patient's PMS record as soon as the patient submits, typically within 60-90 seconds, populating medical history, consent, and contact fields without a staff member retyping anything.
- Insurance verification results — pulled nightly (and on-demand before same-day add-ons) and written back as per-procedure estimates attached to the scheduled treatment, through automatic insurance verification.
- Clinical notes — drafted from the visit and pushed into the chart note field once the provider reviews and signs, via AI clinical notes; the PMS note is the final, legal record.
- Perio charting — numbers captured hands-free at chairside write directly into the PMS perio module in the same format a hygienist would type, preserving your existing trend reports.
- Call logs and virtual consult outcomes — logged in intake.dental and linked to the PMS patient record, with booked appointments or treatment-plan acceptance pushed to the schedule and ledger.
Sync speed depends on the field and the PMS's own API limits, but the practical range across our offices is seconds for schedule and demographic data, and under five minutes for clinical and insurance writes. Nothing waits for an overnight batch job except the verification run itself, which checks every patient on tomorrow's schedule while the office is closed.
What stays the source of truth — and what doesn't need to
The PMS remains the legal and clinical record. If a payer audits a claim, if a patient disputes a balance, if a board reviews a chart, the PMS entry is what matters, and intake.dental is built to make sure that entry is complete and timely rather than to compete with it. We don't maintain a parallel patient chart.
What intake.dental does hold as its own source of truth is the material your PMS was never built to store: call transcripts and recordings, video from virtual consultations, the specific benefit breakdown behind an estimate, and the communication history across text, email, and phone. Those records link to the PMS patient ID so your team can pull them up from either side, but they don't need to live inside the PMS database to be useful — and trying to force them in is usually what bloats a PMS and slows it down.
No shadow spreadsheet, no second login for patients
The practices we talk to that are burned on "integration" usually mean they ended up running a second system that didn't actually talk to the first — a scheduling app with its own calendar, a forms tool that emailed a PDF someone then retyped. That's double entry with extra steps. The test we hold ourselves to is simple: if a staff member can find a reason to open a second screen and retype something, the integration isn't done.
The double-entry math, in actual minutes
Here's what manual re-entry costs a mid-size practice, using numbers pulled from our own front desks before we automated the write-back:
A new patient intake form has roughly 40 fields a front desk member would otherwise retype into the PMS — medical history, insurance IDs, consent checkboxes. At 4 minutes of retyping per form, 8 new patient forms a day comes to 32 minutes daily. Over a 20-day scheduling month, that's 640 minutes, or 10.7 hours a month of a trained team member's time spent on data entry that produces zero clinical or financial value. Add the roughly 3 minutes per patient a front desk spends manually writing insurance verification notes into the ledger — on a 24-patient day, that's another 72 minutes daily, or 24 hours a month. Combined, a single front desk seat can lose close to 35 hours a month to work the sync is designed to remove entirely.
That math is also why we frame this as an AI front office problem rather than a forms problem or a scheduling problem in isolation — the time loss compounds across every point where a human has to bridge two systems by hand.
What go-live actually looks like
Because there's no database to convert, the setup sequence is short:
- We confirm your PMS version supports the integration method we use (API or a secure local connector, depending on the system).
- Your office manager grants a connection with the same permission level a staff login already has — we don't need admin rights to your billing software or your bank.
- We run a test batch: a handful of real appointments, forms, and a verification cycle, checked against what actually lands in the PMS.
- Front desk and clinical staff get a walkthrough of what now happens automatically versus what still needs a human decision — approving a treatment estimate, signing a note, confirming a flagged sync.
Most offices are fully live within a week, and nothing about daily workflow changes for the PMS itself — your team still opens the same software to pull up a chart or post a payment. You can see current plans on the pricing page or put time on the calendar through schedule a demo if you want to see the sync running against a copy of your own PMS setup before committing to anything.
Where the limits are
We'd rather state this plainly than let you find out later. Some older or heavily customized PMS installs have API limits on how often certain fields can be written, which can push a sync from "seconds" to "a few minutes" for specific data types like ledger entries. A handful of legacy systems don't expose a live API at all, in which case we use a secure local connector instead, with the same source-of-truth rules but a slightly different setup step. And any field your PMS doesn't have — like a video consult recording — simply won't live inside it, by design, because that's not what the PMS is for.