ConnectWiz Booking

L’agenda de rendez-vous avec une vraie base de données derrière.

Pris par un agent, par l’IA, par un flow ou par le client lui-même — chaque rendez-vous arrive dans un registre unique où salles, équipements et praticiens se croisent correctement, où la double réservation est bloquée par la couche de stockage elle-même, et où vos vrais agendas se synchronisent dans les deux sens.

Quatre portes de réservation, une seule vérité Les conflits bloqués par la base de données Synchronisation Google · Outlook · Apple
La disponibilité — tranchée par la base de données
Jeudi
Salle + équipement + médecin : libres
Chevauchement — rejeté par la base
14h30 réservé
Envoyé vers Google · créneau occupé retranché
4
Portes de réservation — le panneau, l’IA, une étape de flow et la réservation en autonomie depuis le widget
0
Double réservation possible — les chevauchements sont rejetés par une contrainte de base de données, pas par une règle applicative qui peut être prise de vitesse
3
Fournisseurs d’agenda synchronisés dans les deux sens — Google, Outlook/Microsoft 365 et Apple/CalDAV
15 min
Cadence du moteur de rappels — les rappels clients et les alertes internes partent selon le délai que vous avez réglé

Quatre portes

Tout le monde réserve contre la même vérité

L’équipe, dans l’agenda

Un agenda en vue journée et une gestion complète des rendez-vous — types, lieux, praticiens, variantes de prestation, libellés de statut définis par vous, traitement des absences et lignes de facturation.

L’IA, en deux verbes

Wiz propose de vrais créneaux libres, puis réserve celui que le client choisit — deux étapes, délibérément, parce que réserver d’office le premier créneau libre pour quelqu’un est un truc de démo, pas du service.

Les flows, comme étape

Le nœud de réservation glisse la proposition de créneaux dans n’importe quelle automatisation — le flow de relance qui se termine par un rendez-vous repris, sans humain dans la boucle.

Les visiteurs, en autonomie

Le widget de site web : sa mini-application de réservation laisse le client choisir lui-même dans la disponibilité en direct, et elle n’apparaît que si vous proposez réellement des prestations réservables.

Le modèle de ressources

Salles, équipements, personnes — qui se croisent comme dans la réalité

« Disponible » est une question à trois entrées : le praticien, la salle et l’équipement doivent être libres en même temps. La plupart des outils de réservation modélisent un seul axe et croisent les doigts ; celui-ci modélise l’intersection.

Illustration 3D abstraite : une grille d’agenda avec un créneau émeraude, trois sphères de ressources verrouillées par un anneau lumineux, et un créneau qui empiète repoussé par un champ de force

Rôles et contenants

Un rendez-vous retient plusieurs ressources par rôle — salle, équipement, praticien — et les liens de contenance font qu’un équipement placé dans une salle occupée est correctement indisponible, même si personne n’a réservé l’équipement.

Une contrainte, pas une règle

La prévention des chevauchements vit dans la couche de stockage, sous forme de contrainte d’exclusion — deux requêtes en course ne peuvent pas gagner toutes les deux, parce que la seconde écriture est physiquement rejetée. Un moteur de règles promet ; une contrainte garantit.

La capacité en unités

Un cours à huit places, c’est huit unités, pas un compteur — si bien qu’« il en reste une » est un fait qui désigne une unité précise, et qu’un remboursement ne corrompt pas l’arithmétique.

L’éligibilité, à part

« Cette salle peut-elle accueillir cette prestation » est une matrice à part, distincte de l’occupation — une ressource libre mais inadaptée n’est donc jamais proposée, et la raison est consultable.

Synchronisation des agendas

Vos agendas, retranchés de la disponibilité

Les réservations sortent

Les rendez-vous apparaissent comme événements dans les agendas Google, Outlook ou Apple — et disparaissent à l’annulation. L’agenda du téléphone du praticien n’a jamais un jour de retard sur l’agenda du cabinet.

Les créneaux occupés entrent

Les événements externes se retranchent de la disponibilité — l’IA ne propose jamais jeudi 15h00 si votre Google Calendar personnel y a déjà le dentiste.

Un rôle et un sens par source

Chaque source connectée a son propre réglage — lecture, écriture, les deux, ou occupé seulement — pour que l’agenda partagé de la clinique et un agenda personnel jouent des rôles différents sans se battre.

Rappels et exploitation

Le suivi, automatisé

Des rappels qui partent vraiment

Confirmations et rappels au client selon le délai que vous avez réglé — par e-mail, avec SMS en option — plus des alertes internes à chaque nouvelle réservation. « Je reviens vers vous » cesse de dépendre de la mémoire de quelqu’un.

Les rendez-vous consomment du stock

Une intervention peut consommer des pièces prises sur le registre de stock — le soin et les matériaux qu’il a consommés se rapprochent en un seul geste.

L’historique migre avec vous

Vous arrivez d’un autre CRM ? Le moteur de migration importe votre historique de rendez-vous dans le même registre — l’agenda ne démarre pas amnésique.

Les petits caractères, en clair

Annoncé avant que vous n’organisiez tout autour

Pas encore de lien de réservation autonome

La réservation en autonomie vit à l’intérieur du widget de chat du site — il n’existe pas encore de page de réservation publique façon Calendly que vous pourriez envoyer par e-mail. Si c’est votre mode de fonctionnement principal, dites-le-nous ; cela oriente la feuille de route.

Les CRM externes en portent moins

Quand une réservation s’écrit dans un CRM connecté, le détail des équipements et des consommations peut ne pas survivre — les API des éditeurs n’exposent pas ces axes, et la synchronisation dit ce qu’elle a laissé tomber au lieu de le laisser tomber en silence.

Le registre est le nôtre, toujours

Quels que soient les agendas et les CRM connectés, le registre des réservations reste une table propre à ConnectWiz — les systèmes externes sont des sources et des miroirs, jamais la référence. C’est une position de conception, et elle est annoncée.

FAQ des réservations

Avant de planifier

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

Quatre portes : votre équipe depuis le panneau et l’agenda en vue journée, Wiz l’agent IA à l’intérieur de n’importe quelle conversation, l’étape de réservation d’un flow d’automatisation, et les visiteurs qui réservent eux-mêmes dans le widget de chat du site. Les quatre écrivent dans le même registre contre la même disponibilité : il n’existe donc qu’une seule vérité sur qui occupe quel créneau.

Par la base de données elle-même — une contrainte d’exclusion au niveau du stockage rend physiquement impossible l’écriture de deux réservations qui se chevauchent sur la même ressource, quelle que soit la porte qui a essayé. Une règle applicative peut être prise de vitesse ; une contrainte, non.

Oui — Google, Outlook/Microsoft 365 et Apple/CalDAV, dans les deux sens : les réservations partent sous forme d’événements (et disparaissent à l’annulation), et les créneaux occupés de l’extérieur entrent et se retranchent de la disponibilité, si bien que l’IA ne propose jamais un créneau que votre agenda personnel a déjà pris. Chaque source a son propre réglage de rôle et de sens — lecture, écriture, les deux, ou occupé seulement.

En deux étapes, délibérément : elle propose d’abord de vrais créneaux disponibles, puis réserve celui que le client choisit. Fondre les deux en une seule étape reviendrait à réserver d’office le premier créneau libre pour quelqu’un — pratique en démo, hostile dans la vraie vie.

Chaque « vous avez quoi de libre ? » peut se terminer par un créneau retenu.

Paramétrez vos ressources une fois — ensuite, agents, IA, flows et clients réservent contre la même vérité.