What we've built, told straight

Fusion Dental Implants: patient communication built around their Salesforce

Customer: Fusion Dental Implants, Northern California — same-day dental implants, two centers (Roseville, El Dorado Hills). What we built: the patient messaging, appointment confirmation and call layer around their existing Salesforce. Status: in production. Figures below cover May–August 2026, pulled read-only from the production database and live Salesforce on 21 September 2026.

The situation

A same-day implant practice lives on response speed. A patient who asks a question on Tuesday evening and hears back on Thursday has already called someone else. But every inbound message competes with a front office that is treating patients, and the messages arrive on every channel at once.

What we built

• A messaging layer that sends and follows up on patient messages.
• Appointment confirmations that go out automatically and write back to the CRM.
• A voice layer for outbound call attempts, logged against the same records.
• Everything anchored in their existing Salesforce, not a second system beside it. Records are created and updated where the practice already works.

The messaging paths run on Claude models in the current code; parts of the call analysis still use a different provider. We say that precisely because it is how the system actually looks — not how it would sound best.

What it handles across four months

Between May and August 2026 the production system recorded:

• 5,917 outbound messaging rows
• 1,093 appointment confirmation records
• 7,199 Salesforce lead records created (across all business units)
• 1,089 voice call rows — outbound call attempts, logged against the same records

These are logged operational activity. They are not a claim that the AI handled each one alone.

What we do not claim, and why that matters

We cannot show a verified before-and-after for this system, and we will not invent one. Our own inbound logging changed part-way through the period, which removes the honest baseline any improvement claim would need — our gap, not the customer's. So no "40% faster replies", no "hours saved per week".

That restraint is the method, not an apology. Before we write a number into a slide, we go back to the production database and try to break it. A system you cannot audit is a system you cannot trust, and a customer who is handed unverified numbers is a customer who will be handed unverified work.

What we are adding next: per-message model and authorship logging, so that in a few months the impact question can be answered with evidence rather than opinion.

Fassadenklar: from a CRM deal to a priced quote, with the building measured from public data

Customer: Fassadenklar (fassadenklar.de) — facade cleaning and coating, Germany. What we built: Pipedrive deal → automatic building measurement from official 3D city data → draft quote in sevDesk. Status: live in production since 16/17 September 2026. The Claude cross-check was enabled on the live service on 23 September 2026 (deployment v85, verified in the running app).

The situation

Quoting facade work means knowing the surface area of a building. Somebody drives there, or measures on a map, or guesses — and the quote waits. Multiply that by every enquiry and the slow step is not the work, it is the paperwork before the work.

There was a second problem. The quoting software they wanted to integrate with never granted API access; the request sat open for five months. A pipeline that depends on a vendor's goodwill is not a pipeline.

What we built

1. A deal is marked for a quote in Pipedrive. A webhook fires.
2. The building is measured from official LoD2 city models — the same public 3D data the surveying offices publish. No site visit, no manual tracing.
3. A vision model classifies the surfaces: how many storeys, balconies, access difficulty, and a confidence score.
4. When confidence is low, two models look at the same satellite overlay — Gemini and Claude. The building is only re-selected when both name the same one. Disagreement means nothing changes and the deal is flagged. An abstention is a better answer than a confident wrong one.
5. A draft quote is created in sevDesk, positions and prices from a fixed template. No model writes a price. A quote is a contract, so the contractual parts are deterministic by design.
6. A human reviews and sends. Nothing reaches a customer unsupervised.

We swapped the blocked vendor for sevDesk and had the first draft quotes out of the system the same week. A cross-check run costs about €0.06 on the deals where it triggers.

Two runs on the live system

Both were live test runs on the production service, on production data, before the first customer drafts:

• Leonberg — two buildings, 245.18 m² and 187.36 m², one quote: €3,460.32 net.
• Berlin — 849.42 m², with a 112.35 m² party wall correctly excluded from billing. Quote: €6,795.36. A party wall sits on the boundary and cannot be charged. The system catches it; at 8pm it is easy to miss.

Week one, told straight

The pipeline is days old, so here is the whole picture rather than the flattering half. In the first days it produced clean drafts on production runs, measured one address range as nine separate buildings — a defect we found and diagnosed, with the fix scheduled — and lost one webhook to a hosting outage that took the app down. No validated accuracy rate exists yet, and we will not publish one until the sample is big enough to mean something.

That is what week one of a production system looks like. Anyone showing you only the good half is showing you a demo.

Already live, and worth saying plainly: the quote's intro paragraph is written by Claude and rule-guarded. On the Berlin run it recited a figure, so the guard threw it away and the quote went out without it. Exactly the behaviour we build for — the rule decides, not the model.

What is next: the measurement fix for address ranges, and calibration against surveyed ground truth.