D’abord synchroniser le vrai planning
Je ne stockerais pas le planning dans le prompt. Le bot peut poliment proposer un créneau, mais la seule source de temps libre doit être le calendrier, vérifié juste avant de créer le rendez-vous.
L’erreur que j’éliminerais d’abord : Le message « vous êtes réservé à 15 h » ne signifie pas que l’événement a été créé. Double-clic, fuseau horaire et réservation parallèle transforment facilement une réunion en deux.
Que préparer et quel résultat attendre
- Résultat : Le client choisit un créneau disponible, reçoit confirmation et rappel, et la reprogrammation ne crée pas une deuxième réunion.
- Créez un tableau de services : service_id, duration, buffer, calendar, business hours, time zone, qui approuve les exceptions.
- Gardez les données source et les droits d’accès séparés du résultat pour auditer ce que la réservation de services IA a réellement fait.
- Testez réservation, créneau occupé, reprogrammation, annulation, heure d’été et une demande depuis un autre fuseau.
Configurer réservation, rappels et reprogrammations
- Configurer d’abord le calendrier
Connectez un calendrier de travail et définissez horaires, pauses, buffer avant et après le rendez-vous, et délai minimum. Ne stockez pas les créneaux libres dans le prompt.
Проверьте: Un créneau libre est tiré du calendrier juste avant de le montrer au client.
Если не сработало: Synchronisez un calendrier de test et désactivez les écritures sur le calendrier partagé.
- Traiter le service comme un objet séparé
Pour chaque service définissez service_id, duration et personnel requis. L’IA peut comprendre le nom du service, mais prenez durée et prix dans le tableau.
Проверьте: Le même service donne le même créneau quelle que soit la formulation du client.
Если не сработало: Remplacez le texte libre par des boutons ou une liste de valeurs autorisées.
- Confirmer le créneau avant de créer le rendez-vous
Après le choix de l’heure, redemandez availability, puis créez l’événement avec nom, contact, service et fuseau. Sauvegardez event_id.
Проверьте: Un double-clic ou un webhook répété ne crée pas deux rendez-vous.
Если не сработало: Vérifiez event_id et bloquez la réservation en double.
- Séparer reprogrammation et nouvelle réservation
La reprogrammation doit trouver l’event_id existant, vérifier le nouveau créneau et mettre à jour l’événement. Si l’id manque, routez la demande vers un humain.
Проверьте: L’historique conserve l’ancienne et la nouvelle heure.
Если не сработало: Ne supprimez pas l’ancien événement tant que le nouveau n’est pas confirmé.
Le setup qui empêche les doubles réservations
Dans le tableau des services définissez service_id, duration_minutes, buffer_before, buffer_after, calendar_id et timezone. L’IA peut comprendre que la personne veut une « consultation », mais prenez durée et calendrier dans le tableau.
Après le choix du créneau, rappelez availability, puis créez l’événement et sauvegardez event_id. Sur un webhook répété cherchez d’abord event_id ou client_request_id. Pour reprogrammer, créez d’abord le nouveau créneau et ne supprimez l’ancien événement qu’après confirmation.
- Testez l’heure d’été et une demande depuis un autre fuseau.
- Ne promettez pas de créneau tant que le calendrier n’a pas renvoyé un event_id confirmé.
Ce qu’il faut laisser à un humain
Passez à l’équipe quelques cas : client VIP, paiement échoué, pas de spécialiste adapté, reprogrammation hors règles et conflits de calendrier. Dans les autres cas l’IA peut collecter des données, mais l’action finale doit encore passer par l’API calendrier.
Je vérifie le créneau deux fois — je ne promets pas de mémoire
Dans le calendrier stockez `event_id`, `client_request_id`, `service_id`, `duration_minutes`, `buffer_before`, `buffer_after` et `timezone`. Après le choix de l’heure rappelez availability puis seulement créez l’event. Si un webhook répété arrive avec le même `client_request_id`, renvoyez l’`event_id` existant au lieu de créer une nouvelle réunion.
Pour reprogrammer d’abord réservez le nouveau créneau, obtenez confirmation, puis changez l’ancien événement. Si le nouveau créneau n’a pas été créé, ne supprimez pas l’ancienne réunion. Cette règle simple évite « le bot a annulé l’ancienne mais n’a jamais placé la nouvelle ».
Ce que l’IA peut gérer vs ce qui doit venir du calendrier
| Critère | Question | Bon signe |
|---|---|---|
| Entrée | Qu’est-ce qui entre exactement dans la réservation de services IA ? | Créez un tableau de services : service_id, duration, buffer, calendar, business hours, time zone, qui approuve les exceptions. |
| Action | Que le système a-t-il le droit de faire seul ? | Uniquement des actions pré-listées, sans accès à tout le compte |
| Vérification | Comment savoir que le résultat est acceptable ? | Testez réservation, créneau occupé, reprogrammation, annulation, heure d’été et une demande depuis un autre fuseau. |
| Échec | Où va un cas peu clair ? | Ne promettez pas de créneau dans le message : mettez la demande en needs_confirmation et passez au manager l’heure exacte et la demande originale. |
Ce qui doit changer après la mise en place
Le client choisit un créneau disponible, reçoit confirmation et rappel, et la reprogrammation ne crée pas une deuxième réunion.
Pourquoi le bot réserve des gens sur des créneaux inexistants
Stocker le planning dans le prompt au lieu du calendrier.
Ignorer le fuseau horaire du client.
Traiter une confirmation envoyée comme preuve que l’événement a été créé.
Autoriser la reprogrammation sans vérifier quelle réunion est modifiée.
Quand la réservation devient un vrai système de réservation
Vous avez besoin d’un spécialiste s’il y a plusieurs intervenants, des durées différentes, des paiements ou des contraintes médicales/juridiques.
Que tester avant d’ouvrir la réservation
Pour qui est cette approche de réservation de services IA ?
La réservation automatique doit voir de vrais créneaux libres, tenir compte de la durée et du fuseau horaire, et ne reprogrammer ou annuler qu’après contrôles d’identité et de règles métier.
Par où commencer si tout est encore manuel ?
Créez un tableau de services : service_id, duration, buffer, calendar, business hours, time zone, qui approuve les exceptions.
Comment vérifier que le setup ne vous nuira pas ?
Testez réservation, créneau occupé, reprogrammation, annulation, heure d’été et une demande depuis un autre fuseau.
Et si le résultat n’est pas clair ?
Ne promettez pas de créneau dans le message : mettez la demande en needs_confirmation et passez au manager l’heure exacte et la demande originale.
