ConnectWiz + Estesoft Stella
Live integrationStella stays your CRM. Conversations finally know it.
The first provider on our provider-agnostic CRM port: live customer context from Estesoft Stella inside every conversation, bookings written back to the Stella diary — and a set of deliberate refusals, written down, about what a communications product should never touch.
CRM
What it does — precisely
Live context, identity-locked
This customer’s appointments, quotes, outstanding balance, notes and documents surface on the conversation — and the AI can read them for exactly this customer, resolved from the conversation itself, never from a guessed ID.
Bookings write back
An appointment made in chat lands in Stella’s diary — and where the vendor’s API can’t carry a detail, the sync says what it dropped instead of dropping it silently.
The AI reads, never writes
A standing rule on the whole CRM port: reads are identity-locked and writes stay human — an AI that could misread a balance is the cheap rehearsal for one that books the wrong patient.
Migration when you choose
A queued, resumable engine imports appointments, quotes, sales, receivables and notes into ConnectWiz — skips are reported by name, and data ownership flips only as the final step.
Payments and orders write back
Recording a payment or creating an order in ConnectWiz can post to Stella — opened by an explicit owner decision, behind the same four gates and rehearse mode as everything else.
Incremental, not a mirror
Change polling exists to catch missed events — not to keep a second copy of the clinic’s ledger. Losing that distinction turns a cache into a database, so it’s written down.
Under the hood
The write path: four gates and a rehearsal
Off is the default, per operation
Every write ships switched off, and each of the seven operations — notes, appointments, cancellations, customers, quotes, orders, payments — has its own switch. Safety here is an absence: if a gate fails, there is no writer object to call.
Ownership outranks the switch
Above the per-operation switches sits data ownership: a domain your workspace owns never writes out to Stella, whatever the switch says. The gate order is fixed and documented.
Rehearse on the live code path
Dry-run mode builds the exact payload the live write would send and stops only at the transport — a rehearsal that takes a different code path proves nothing, so there isn’t one.
Writes verify themselves
After each write, the integration reads back what it created and compares. A mismatch surfaces as a warning for a human — never an auto-correction, because the vendor API has no idempotency key to make correction safe.
Migration in the right order
Appointments import first — deliberately, because the diary is the only surface that can discover people tenant-wide. Every skipped row is tallied by name: no time window, unknown shape, missing contact.
AI reads are triple-locked
The AI’s CRM tool advertises only the actions your workspace actually has, re-validates the action at call time, and resolves the customer from the conversation itself — a hallucinated option or a guessed ID dies before the transport.
Setup
How it connects
Connect Stella
Add your Stella credentials; the connector validates against the live API before anything saves.
Work with context
Conversations show the customer’s CRM card; agents and the AI answer from facts, not memory.
Migrate if and when
Run the assisted migration to bring full history in — the old system stays authoritative until you flip ownership.
Better together
What it composes with
Booking engine
Chat bookings land in the Stella diary, and the booking system subtracts Stella appointments from availability — one diary truth.
The inbox card
Agents see the customer’s live CRM context — appointments, quotes, balance — beside the conversation in the shared inbox.
Wiz, read-only
The AI agent answers "when is my appointment?" from Stella facts, identity-locked to the person in the thread — and by standing rule cannot write.
Security & guarantees
The boring guarantees
Health data: never read
Treatment records are special-category data under KVKK. Reading them into a support screen would widen the processing population from the clinic’s physicians to the whole team — so the endpoints exist and we refuse them, in writing.
No invisible hands
We never close the clinic’s tasks, never change its customer segments, never touch its accounting ledger — each is a documented refusal, because automating someone else’s business process from a chat is the product’s most expensive error class.
Tokens stay out of URLs
The vendor offers a token-check endpoint that puts credentials in the URL — where logs and proxies see them. We never call it. Credential handling is chosen endpoint by endpoint.
Deletes: not offered
The vendor’s delete endpoints for customers, leads, bills and quotes go unused — soft-versus-hard behavior is unverified, and deleting a patient record appears in no user story we’re willing to own.
The honest fine print
Boundaries, stated
Deliberate refusals
Medical treatment records are never read or displayed, the vendor’s lifecycle labels are never overwritten, and no full two-way mirror is pretended — each refusal is a documented design decision, not a gap.
Other CRMs
The port is provider-agnostic by design — Stella is the first provider, not the last. Running something else? Tell us; it shapes the queue.
Connected honestly beats connected loudly.
Every integration here is described by what it really does — direction, ownership and limits included.