Checklist chatbot
Checklist chatbot pour la prise de rendez-vous WhatsApp
Une checklist pratique pour les équipes de service qui construisent un chatbot de booking sur WhatsApp ou Instagram. Utilisez-la pour confirmer les questions de qualification, les règles calendrier, les moments de handoff, les confirmations et la QA avant que des clients réels ne dépendent du workflow.
Modèle visible
Copiez la structure, puis adaptez-la à votre politique et à l’intention du client.
Le modèle est volontairement visible sur la page. Il ne s’agit pas d’un téléchargement fermé et il évite les promesses non étayées sur la conversion, le revenu ou le taux de réponse.
Blocs du workbench
4 blocks01
Scope
Définir le job de booking
Type de rendez-vous : {{service_name}} Objectif du booking : {{new_booking | reschedule | cancellation | qualification_only}} Données client requises : {{name}}, {{preferred_day}}, {{preferred_time}}, {{service_notes}} Revue équipe nécessaire quand : {{handoff_condition}}
Ne commencez pas par le copy. Commencez par le travail opérationnel que le chatbot doit accomplir.
02
Questions
Questions de qualification
Demandez seulement ce dont l’équipe a besoin pour booker ou router le rendez-vous : 1. De quel service avez-vous besoin ? 2. Quel jour et quelle plage horaire vous conviennent le mieux ? 3. Y a-t-il quelque chose que l’équipe doit savoir avant de confirmer ? 4. Préférez-vous le prochain créneau disponible ou une personne spécifique ?
Gardez la qualification courte. Les formulaires longs augmentent l’abandon et compliquent le handoff.
03
Calendrier
Disponibilité et confirmation
Vérifications calendrier : - Les horaires métier sont configurés. - Les jours bloqués et exceptions sont configurés. - La durée du rendez-vous est claire. - Le chatbot sait expliquer ce qui se passe quand aucun créneau compatible n’est disponible. - Le copy de confirmation ne promet pas un horaire avant que le rendez-vous ne soit réellement créé ou approuvé.
Dans Interlinked, connectez le workflow à Google Calendar et validez les règles de calendrier au setup.
04
Handoff
Revue manuelle
Routez vers l’équipe quand : - Le client demande un horaire indisponible. - La demande contient un contexte médical, juridique, financier ou sensible. - Le service exige une approbation équipe. - Le client est agacé, confus ou demande une exception. - Le chatbot n’arrive pas à déterminer quel service ou quelle durée s’applique.
La revue manuelle doit préserver le contexte de conversation, l’horaire souhaité et les notes client.
Notes d’implémentation
Comment transformer ce modèle en workflow dans Interlinked
01
Fixez les limites du rendez-vous
Documentez durée du service, horaires métier, jours bloqués, exceptions équipe, règles d’annulation ou de reprogrammation et le point exact où le rendez-vous devient confirmé. Le chatbot ne doit pas déduire ces détails à partir d’un copy vague.
02
Connectez Google Calendar avant le lancement
Les workflows de booking Interlinked dépendent de la disponibilité calendrier et des règles de scheduling configurées. Connectez le calendrier, testez les jours bloqués et vérifiez que l’événement créé respecte la durée et le contexte client.
03
Écrivez des chemins de qualification courts
Un chatbot de booking doit collecter assez d’informations pour trouver le bon chemin, pas interroger le client sans fin. Gardez le chemin principal court et envoyez les edge cases en handoff.
04
Concevez la réponse quand il n’y a pas de disponibilité
Le failure state le plus important est l’absence de créneau compatible. Donnez au client des options claires : choisir une autre fenêtre, demander une personne ou laisser des notes pour revue équipe.
Erreurs fréquentes
Confirmer un rendez-vous avant d’avoir vérifié le calendrier.
Utilisez un wording indiquant que le chatbot vérifie la disponibilité jusqu’à la création effective du rendez-vous ou son approbation par l’équipe.
Poser trop de questions d’intake.
Posez seulement les questions nécessaires pour identifier service, horaire et besoin de revue. Les informations supplémentaires peuvent venir après le handoff.
Ignorer les jours bloqués et les exceptions.
Testez week-ends, jours fériés, absences équipe, pauses déjeuner et règles de rendez-vous le jour même avant le lancement.
Laisser le chatbot gérer seul les cas sensibles.
Routez les cas incertains, sensibles, à haut risque ou avec clients mécontents vers une revue manuelle en conservant tout le contexte.
Checklist QA
- 01 Chaque service a une durée, une règle horaire et un owner du booking.
- 02 Google Calendar est connecté et testé avec des exemples disponibles, indisponibles et jours bloqués.
- 03 Le chatbot couvre nouveaux bookings, reprogrammations, annulations et chemins sans disponibilité.
- 04 Le message de confirmation n’apparaît qu’après création réelle du rendez-vous ou lorsque l’approbation équipe est claire.
- 05 Le handoff manuel garde visibles jour souhaité, horaire souhaité, service et notes client.
- 06 Le workflow a été testé depuis WhatsApp ou Instagram jusqu’à la revue CRM.
Contexte produit
Où ce modèle se connecte dans Interlinked
FAQ du modèle
Questions avant de l’adapter
Un chatbot de prise de rendez-vous peut-il créer des événements calendrier ?
Dans les workflows de scheduling Interlinked, le comportement dépend de la connexion calendrier configurée, des horaires métier, de la disponibilité et des règles du workflow. Testez le chemin complet avant que des clients réels ne s’y fient.
Le chatbot doit-il confirmer automatiquement tous les rendez-vous ?
Non. Certains services doivent exiger une revue humaine, surtout lorsqu’il y a durée variable, éligibilité, disponibilité du praticien, paiement, contexte sensible ou exceptions.
Quels canaux peuvent utiliser cette checklist ?
La checklist est écrite pour les workflows de booking WhatsApp et Instagram, mais les mêmes checks opérationnels s’appliquent à tout canal connecté qui route vers le CRM et la logique de scheduling Interlinked.
Quel est le test QA le plus important ?
Testez l’indisponibilité et le handoff. Un bon workflow de booking doit expliquer ce qui se passe quand l’horaire demandé n’existe pas et doit router les cas incertains vers une personne avec tout le contexte.
Parcours de lancement
Insérez le modèle dans un vrai workflow de conversation.
Utilisez la documentation produit comme source de vérité, puis testez le script ou la checklist avec un petit ensemble d’exemples internes avant de l’utiliser avec des clients.