For Sales

Status: unreleased, beta-gated. Do not commit to dates or sell it as available. It is a roadmap/design-partner conversation, not a shipping feature.

Who this lands with

The buyer is almost always the clinic owner or practice manager, and the pain is felt by two people they employ:

• The receptionist, who loses hours a week in the payer portal.
• The accountant, who eats the cost when a treatment is invoiced and then rejected.

The dentist benefits but rarely champions it. Sell to the person who counts the money.

Qualifying questions

Ask these early. They tell you within two minutes whether this is a real opportunity.

1. **"Walk me through what happens when an insured patient walks in — from the door to the

chair."** Listen for a portal, a second login, and re-typing.

1. "How do you find out which insurer a patient actually has?" If the answer involves

asking the patient and hoping, discovery is your wedge.

1. "Who checks whether the payer has answered a pre-auth, and how often?" If a named

person checks a portal three times a day, the polling job is the story.

1. "Has a treatment ever been invoiced before the approval came back?" The follow-up —

"what happened?" — usually produces a number. That number is your ROI case.

1. "How many branches, and does each have its own NPHIES provider code?" Multi-branch

raises the value and shapes the setup conversation.

1. "Roughly what share of your patients are insured?" Under ~20%, this is a nice-to-have.

The pitch, in three beats

Beat 1 — the portal tax. "Every insured patient costs you two logins and a re-typing session before anyone touches a tooth. And the re-typing is where the rejections come from — a transposed procedure code the payer bounces three days later."

Beat 2 — collapse it into the chart. "The receptionist types the national ID once. Dentolize asks the exchange who insures them, and if that insurer isn't in your system yet, it offers to create it — pre-filled with the payer's own data. Eligibility is one click. And when the dentist plans treatment, the pre-auth is submitted straight from the chart, already carrying the procedures, teeth, prices and practitioner."

Beat 3 — and then it holds the line. (This is the beat that closes.) "Here's what most systems don't do. While that approval is pending, Dentolize won't let anyone invoice that treatment, change its price, or move it to a different tooth. If the payer partially approves, the approved amounts land on the operations automatically. If you cancel, the treatment unlocks so you can fix it and re-send. You physically cannot bill something the payer hasn't agreed to."

Objection handling

"We already use the payer portal — it's free." The portal is free; the labour isn't. The cost is the re-keying and the checking, plus the rejections that come from transcription errors. Ask them to count how many pre-auths they raise a week and multiply by the minutes. Also: the portal can't stop your team invoicing a treatment that hasn't been approved. That's the expensive failure, and it's the one this prevents.

"Our system already sends claims to NPHIES." Careful — check what they actually mean. Claim submission and pre-authorization are different steps. This is pre-auth: getting the payer to commit before treatment. And even if they do have pre-auth, ask whether their treatment records lock while it's pending, and whether approved amounts flow back onto the line items automatically. That's usually where the gap is.

"How long does approval take?" The payer decides, not us. What we control is that you find out as soon as they answer — we're polling every minute, so nobody has to sit refreshing a portal. Do not promise timings.

"What happens if the connection to NPHIES goes down?" The clinic keeps working. Approvals stay pending and get picked up on the next successful poll. Nothing is lost, and nothing about normal charting or invoicing stops. There's also a manual-update path so an approval that arrives by phone or email can be recorded properly — and it's permanently marked as manually entered, with the user's name, so it can never be confused with a payer-confirmed figure.

"Who can see and change this? We can't have reception cancelling approvals." Nine separate permissions, configured per role. Submitting, cancelling, manually updating and managing the credential are all distinct. A typical setup gives reception discovery and eligibility only, doctors submission, and restricts cancellation to managers.

"Where does our DHS client secret live?" Validated against DHS before it's stored, encrypted at rest with AES-256-GCM, and never displayed again — the screen only ever shows the last four characters. Rotating it is a separate deliberate action, and the old secret is only replaced once the new one is proven to work. This is worth volunteering, not just answering.

"Can we try it?" Honest answer: it's in a controlled beta. It's enabled per clinic, not by a software update. That is a genuine advantage in the design-partner conversation — say you'd want them in the first cohort, and be clear that means shaping it, not just receiving it.

"What if it's wrong? What if it says approved and the payer says no?" Dentolize records exactly what was sent and exactly what came back, on every approval, and you can inspect both. Nothing is inferred — if the payer's answer isn't recognisable, the approval is flagged as an error rather than guessed at.

Competitive angle

The differentiator is not "we connect to NPHIES." Competitors do or will. It is:

If you only get one sentence against a competitor, use: "Ask them what happens if someone tries to invoice a treatment while its approval is still pending."

What not to say

• ❌ Any date, or "next release".
• ❌ "NPHIES certified."
• ❌ "Instant" or "real-time" approvals.
• ❌ "Automatic claim submission" — it's pre-auth.
• ❌ Anything about the global approvals log under Logs. That screen is not implemented

on this branch; only the per-patient Approvals tab works. See Known Gaps.

• ❌ Any mobile claim. There is no DHS UI in the mobile app at all — mobile only blocks

actions on operations that have pending approvals.

Setup expectations to set honestly

Onboarding is short but has hard prerequisites. Say this up front:

1. The clinic must obtain its own DHS client secret. We cannot get it for them.
2. Every branch that will file claims needs its NPHIES provider code.
3. Insurance companies need their NPHIES insurer code — though discovery will create new

ones correctly as it goes.

1. Permission groups need the DHS permissions granted; nothing is enabled by default.

Until step 2 is done for a branch, no DHS controls appear on any patient screen in that branch. That is by design, and it is the single most common "it's not working" call — flag it during onboarding, not after.