ConnectWiz + Estesoft Stella

Intégration en production

Stella reste votre CRM. Les conversations le savent enfin.

Le premier fournisseur branché sur notre port CRM indépendant du fournisseur : le contexte client en direct d’Estesoft Stella à l’intérieur de chaque conversation, les rendez-vous réécrits dans l’agenda de Stella — et une série de refus assumés, écrits noir sur blanc, sur ce qu’un outil de communication ne devrait jamais toucher.

Un contexte verrouillé sur l’identité Les réservations repartent vers la source Données médicales : jamais lues
Estesoft Stella × ConnectWiz
Verrouillé sur ce client
Rendez-vous · devis · solde sous les yeux
Réservation en conversation → agenda Stella
Dossiers de soins : jamais lus
10
Opérations de lecture nommées une par une — rendez-vous, devis, commandes, solde, notes, documents, catalogue, personnel, établissements, recherche de client
7
Opérations d’écriture définies — six ouvertes, une retenue tant qu’elle n’est pas mesurée, et nous disons laquelle
4
Portes sur chaque écriture — adaptateur, capacité, interrupteur par opération, propriété des données
5
Classes d’enregistrements que le moteur de migration emporte — rendez-vous, devis, ventes, créances, notes

CRM

Ce qu’il fait — précisément

Le contexte en direct, verrouillé sur l’identité

Les rendez-vous, devis, soldes restant dus, notes et documents de ce client s’affichent sur la conversation — et l’IA peut les lire pour ce client précis, résolu depuis la conversation elle-même, jamais depuis un identifiant deviné.

Les réservations repartent vers la source

Un rendez-vous pris en conversation arrive dans l’agenda de Stella — et là où l’API de l’éditeur ne peut pas porter un détail, la synchronisation dit ce qu’elle a laissé tomber au lieu de le laisser tomber en silence.

L’IA lit, elle n’écrit jamais

Une règle permanente sur tout le port CRM : les lectures sont verrouillées sur l’identité et les écritures restent humaines — une IA capable de mal lire un solde est la répétition bon marché de celle qui inscrira le mauvais patient.

La migration quand vous le décidez

Un moteur en file d’attente et reprenable importe dans ConnectWiz les rendez-vous, devis, ventes, créances et notes — les enregistrements sautés sont signalés un par un, et la propriété des données ne bascule qu’en toute dernière étape.

Paiements et commandes repartent vers Stella

Enregistrer un paiement ou créer une commande dans ConnectWiz peut être poussé vers Stella — ouvert sur décision explicite du propriétaire, derrière les mêmes quatre portes et le même mode répétition que tout le reste.

Incrémental, pas un miroir

L’interrogation des changements existe pour rattraper les événements manqués — pas pour tenir une deuxième copie du registre de la clinique. Perdre cette distinction transforme un cache en base de données ; c’est donc écrit noir sur blanc.

Côté technique

Le chemin d’écriture : quatre portes et une répétition

Désactivé par défaut, opération par opération

Chaque écriture est livrée éteinte, et chacune des sept opérations — notes, rendez-vous, annulations, clients, devis, commandes, paiements — a son propre interrupteur. Ici, la sécurité est une absence : si une porte refuse, il n’existe aucun objet d’écriture à appeler.

La propriété prime sur l’interrupteur

Au-dessus des interrupteurs par opération se trouve la propriété des données : un domaine que votre espace de travail possède n’écrit jamais vers Stella, quoi que dise l’interrupteur. L’ordre des portes est fixe et documenté.

Répéter sur le vrai chemin de code

Le mode à blanc construit exactement la charge utile que l’écriture réelle enverrait et ne s’arrête qu’au transport — une répétition qui emprunte un autre chemin de code ne prouve rien, il n’y en a donc pas.

Les écritures se vérifient elles-mêmes

Après chaque écriture, l’intégration relit ce qu’elle a créé et compare. Un écart remonte comme un avertissement destiné à un humain — jamais comme une correction automatique, parce que l’API de l’éditeur n’a aucune clé d’idempotency qui rendrait la correction sûre.

Une migration dans le bon ordre

Les rendez-vous s’importent en premier — délibérément, parce que l’agenda est la seule surface capable de découvrir les personnes à l’échelle de tout le locataire. Chaque ligne sautée est comptée avec son motif : hors fenêtre temporelle, forme inconnue, contact introuvable.

Les lectures de l’IA sont verrouillées trois fois

L’outil CRM de l’IA n’annonce que les actions dont votre espace de travail dispose réellement, revalide l’action au moment de l’appel et résout le client depuis la conversation elle-même — une option hallucinée ou un identifiant deviné meurt avant le transport.

Mise en place

Comment ça se connecte

01

Connecter Stella

Ajoutez vos identifiants Stella ; le connecteur les valide contre l’API en direct avant le moindre enregistrement.

02

Travailler avec le contexte

La conversation affiche la fiche CRM du client ; agents et IA répondent à partir de faits, pas de souvenirs.

03

Migrer si et quand vous voulez

Lancez la migration accompagnée pour faire entrer tout l’historique — l’ancien système fait foi jusqu’à ce que vous basculiez la propriété.

Mieux ensemble

Avec quoi il se combine

Le moteur de réservation

Les rendez-vous pris en conversation arrivent dans l’agenda de Stella, et le système de réservation retranche les rendez-vous Stella de la disponibilité — un seul agenda qui fait foi.

La fiche dans la boîte de réception

L’agent voit le contexte CRM du client en direct — rendez-vous, devis, solde — à côté de la conversation, dans la boîte partagée.

Wiz, en lecture seule

Notre agent IA répond à « quand est mon rendez-vous ? » à partir des données Stella, verrouillé sur l’identité de la personne dans le fil — et, par règle permanente, il ne peut pas écrire.

Sécurité et garanties

Les garanties ennuyeuses

Données de santé : jamais lues

Les dossiers de soins sont des données de catégorie particulière au sens de la loi turque KVKK. Les faire remonter sur un écran de support élargirait la population qui les traite, des médecins de la clinique à toute l’équipe — les endpoints existent donc, et nous les refusons, noir sur blanc.

Pas de mains invisibles

Nous ne clôturons jamais les tâches de la clinique, ne modifions jamais ses segments clients, ne touchons jamais son registre comptable — chacun de ces points est un refus documenté, parce qu’automatiser depuis une conversation le processus métier de quelqu’un d’autre est la classe d’erreur la plus coûteuse de ce produit.

Les tokens ne passent pas par les URL

L’éditeur propose un endpoint de vérification de token qui place les identifiants dans l’URL — là où les journaux et les proxys les voient. Nous ne l’appelons jamais. Le traitement des identifiants se décide endpoint par endpoint.

Suppressions : non proposées

Les endpoints de suppression de l’éditeur pour les clients, les prospects, les factures et les devis restent inutilisés — leur comportement, suppression douce ou définitive, n’est pas vérifié, et supprimer le dossier d’un patient n’apparaît dans aucun scénario d’usage que nous sommes prêts à assumer.

Les petits caractères, en clair

Les limites, annoncées

Des refus assumés

Les dossiers de traitement médical ne sont jamais lus ni affichés, les libellés de cycle de vie de l’éditeur ne sont jamais écrasés, et aucun miroir complet dans les deux sens n’est prétendu — chaque refus est une décision de conception documentée, pas un manque.

Les autres CRM

Le port est indépendant du fournisseur par conception — Stella est le premier fournisseur, pas le dernier. Vous tournez sur autre chose ? Dites-le-nous ; cela oriente la file.

FAQ Estesoft Stella

Des réponses directes

Tout le reste est dans la FAQ, ou écrivez-nous directement.

Les rendez-vous, devis, commandes, solde restant dû, notes et documents du client lui-même, sur la conversation où il vous parle — plus le catalogue, le personnel et les établissements de l’entreprise, dans lesquels l’IA puise pour répondre. Toutes les lectures sont verrouillées sur le client présent dans le fil.

Par règle : sur ce port, l’IA est en lecture seule, et les lectures sont verrouillées sur l’identité. Une écriture erronée dans le CRM d’une clinique est un incident bien réel ; nous gardons les écritures humaines et auditables.

Oui — le moteur de migration importe les rendez-vous, les devis, les ventes, les créances et les notes, dans une exécution en file d’attente et reprenable qui signale un par un les enregistrements sautés. La propriété est transférée en dernière étape explicite : rien ne reste à moitié déplacé.

Six : les notes client, les rendez-vous (création et annulation), les nouveaux clients, les devis, les commandes et les paiements — chacune derrière son propre interrupteur, toutes désactivées par défaut, toutes démarrées en mode répétition. Le téléversement de fichiers est défini mais maintenu fermé tant que le comportement de l’endpoint de l’éditeur n’est pas mesuré — c’est un manque de mesure, pas une décision.

Chaque saut est compté avec son motif : les lignes hors de la fenêtre choisie, celles dont le moteur ne reconnaît pas la forme, celles qui nomment un client impossible à rattacher. Ce décompte est le rapport — vous terminez la migration en sachant ce qui n’a pas bougé, et pourquoi.

Mieux vaut une intégration honnête qu’une intégration tapageuse.

Chaque intégration est décrite par ce qu’elle fait vraiment — sens de la synchronisation, propriété des données et limites comprises.