Relier un assistant téléphonique au système de rendez-vous

Un assistant téléphonique ne doit confirmer un rendez-vous qu’après confirmation du bon enregistrement par le système de réservation faisant autorité. Il lui faut des fonctions d’intégration limitées et des réponses indiquant l’état réel. Une liste de créneaux libres ne constitue pas encore une réservation.

Conserver les règles dans le système de réservation

Dans cet exemple fictif, une entreprise de logiciels propose à ses clients existants des entretiens de projet de 30 minutes pour la ressource consultation-a. La personne choisit le 19 novembre 2026 de 14:00 à 14:30, dans le fuseau Europe/Berlin. L’assistant relit la date, l’heure et la durée, puis attend son choix explicite.

Le service de réservation vérifie les types de rendez-vous autorisés, les droits et les chevauchements lors de l’écriture. Le site et le personnel doivent suivre la même règle d’attribution. Une synchronisation ultérieure du calendrier n’empêche pas deux canaux d’attribuer simultanément le même créneau.

Prévoir quatre fonctions limitées

ElevenLabs présente ce type de fonctions externes comme des outils webhook. Les noms et règles ci-dessus sont notre propre conception. Le serveur contrôle lui-même paramètres et droits ; un appel du modèle n’accorde aucun droit d’accès. Les clés d’accès n’ont pas leur place dans la conversation. Citer un identifiant de réservation ne prouve pas à lui seul le droit de la modifier.

Remplir la demande et la réponse

Le serveur attribue l’identifiant stable R-94 à cette demande de réservation. Une fois le rattachement de la personne au compte établi, la fonction reçoit ces données métier :

{"requestId":"R-94","resourceId":"consultation-a","start":"2026-11-19T14:00:00+01:00","timeZone":"Europe/Berlin","durationMinutes":30}

Il ne s’agit pas d’un appel direct à Google Calendar. La requête Freebusy de Google renvoie des périodes occupées ; le parcours de réservation choisi doit assurer séparément l’attribution exclusive. Dans l’exemple, vérification et réservation sont protégées contre les réservations concurrentes. Seule cette confirmation métier autorise une promesse de réservation :

{"requestId":"R-94","status":"confirmed","bookingId":"B-94"}

L’assistant peut alors confirmer l’horaire convenu. La création d’un événement ne prouve pas à elle seule qu’une invitation a été lue.

Vérifier quatre cas jusqu’au résultat enregistré

Répéter le même identifiant et les mêmes données dans le même périmètre de droits doit renvoyer le résultat existant. Une demande modifiée reçoit un nouvel identifiant. Si le résultat reste incertain, aucune seconde réservation n’est forcée avec un nouvel identifiant ; le parcours de résolution prévu prend le relais.

Un déplacement ne doit pas supprimer prématurément le rendez-vous initial. Si l’intégration ne permet pas un changement protégé, un parcours distinct est nécessaire à la place d’une promesse automatique. Les cas de recette détaillés montrent avant la mise en service si la conversation correspond bien à la réservation.

Sources

• ElevenLabs: Webhook tools

• Google Calendar: Freebusy query