For Sales

Status check before you say anything to a prospect

This is an unreleased, draft PR. It is not merged, not deployed, and its own author labeled it "not for review or merge yet." Do not represent this as a current or near-term deliverable in a deal unless you've confirmed its actual release status separately — this document describes what the code does, not when a customer gets it.

The pitch, scoped honestly

"Dentolize is building the ability to connect Claude directly to your clinic's data, starting with inventory reporting — stock levels, usage, and supplier spend — without exporting anything or copy-pasting numbers into a chat window." That's the accurate, defensible pitch today. Don't extend it to patients, appointments, or finances — those aren't built.

Objections you'll hear, and honest answers

"Is our patient data going to an AI company?" Not in this phase. The three tools that exist only touch inventory — stock items, transactions, purchase orders, and suppliers. There is no tool that reads a patient record, an appointment, or a clinical note. The authorization scopes for those areas are reserved in the design, but nothing implements them yet, so there is nothing to turn off — because nothing is on.

"What if a staff member's login gets phished — does Claude now have my whole clinic?" The connection can only ever see what that staff member could already see in clinic-web — permissions carry over exactly, not more, not less. And the worst case is bounded by design: a compromised token can generate unwanted read traffic against one clinic, never write anything, never touch a second clinic, and can be shut off instantly by revoking it. See Tenant isolation and the read-only role and Security hardening and bugs fixed for the specifics behind that claim — it's backed by a two-clinic leak test suite and a dedicated abuse/rate-limiting design, not just an assurance.

"Do we need a new login or account for this?" No — it uses the clinic's existing Dentolize login, including whatever 2FA the clinic already has enabled. There's nothing new for staff to be issued or trained on to connect it.

"Can it change or delete anything in our system?" No, and this is enforced two independent ways: the tools only ever run select queries, and the database account they connect through has no write permission at all — Postgres refuses a write before Dentolize's own code is even involved. This isn't a policy that could be misconfigured; it's architecturally impossible in this phase.

"What happens if we want to disconnect it?" Revocation is immediate — the next request the moment a token is revoked. There's currently no self-service screen for a doctor or owner to do this themselves (that's explicitly called out as future work); today it would need an internal action. Don't promise self-service revocation exists yet.

Competitive angle

The specific, defensible differentiator is that this isn't a general-purpose AI bolt-on with broad database access — it's scoped per-tenant at the database layer (row-level security, not just an application-level filter that could have a bug), and it's read-only by database permission, not by convention. If a competitor's AI integration story can't say the same about how isolation is enforced, that's a real, technical difference worth drawing out — not a marketing claim, an architecture one.