Cal.com écrit le nom de votre client dans le titre
Cal.com fabrique lui-même le titre de chaque réservation, en collant le type de rendez-vous, le nom de l’hôte et le nom de la personne qui a réservé. Ouvrez n’importe quelle réservation dans votre compte, le titre s’y lit tel quel.
Ce titre est le champ qui a l’air le plus inoffensif de la réservation, et il contient le nom d’un tiers. Un connecteur qui le reprend parce que c’est le nom naturel d’une réunion écrit le nom de votre client sur le disque, sans que personne l’ait décidé.
Le connecteur Cal.com ne le reprend jamais. L’intitulé qu’il écrit est celui du type de rendez-vous, choisi par l’hôte et identique pour toutes les réservations du même créneau. Quand ce type n’est pas lisible, l’intitulé reste générique.
Le titre ne compte pas davantage comme une raison d’écrire. Une réservation sans type de rendez-vous ni lieu ne porte aucune connaissance utile, donc elle n’entre pas, même quand son titre est bien rempli.
La liste fermée des champs écrits
C’est cette liste qui décide de ce qu’une réservation devient dans votre Kastel, quoi que la réponse de Cal.com contienne. Un champ absent de la colonne de gauche n’est pas lu.
La dernière ligne surprend, parce qu’une adresse de réunion ressemble à une information de l’entreprise. Dans une réservation Cal.com, ce champ peut aussi porter l’adresse de la personne qui réserve, et rien ne distingue les deux au moment d’écrire. Le connecteur écarte donc les deux.
La réponse contient les participants, votre Kastel n’en garde que le compte
Cal.com renvoie les participants dans la même réponse que la réservation. Chez Calendly, l’identité des invités se lit par une requête séparée que le connecteur n’a jamais écrite. Ici la donnée arrive de toute façon, donc le contrôle doit se placer au moment d’écrire.
Le connecteur ne recopie pas la réponse reçue. Il construit une note à partir d’une liste fermée de champs, et cette liste ne contient ni nom, ni adresse mail, ni téléphone de participant, ni aucune réponse aux champs du formulaire de réservation, ni aucun champ d’adresse mail d’auteur d’action. De la liste des participants, seule la longueur est utilisée.
Cette façon de faire a un effet secondaire utile. Une réponse de forme inhabituelle donne moins de texte, jamais plus, parce qu’un champ imbriqué que le connecteur ne sait pas lire est ignoré au lieu d’être recopié tel quel. Un champ que Cal.com ajouterait dans une prochaine version n’a donc aucun chemin pour entrer.
Le lieu suit la même logique, plus strictement encore. Le connecteur écrit le nom de l’outil de visioconférence, ou la mention d’un rendez-vous en personne, d’un appel téléphonique ou d’une rencontre en ligne. Toute chaîne libre saisie comme lieu est écartée, adresse comprise, parce qu’une adresse écrite dans ce champ peut être celle du participant et que rien ne permet de faire la différence au moment d’écrire.
Un rendez-vous pris au nom d’une équipe n’est lisible par personne
Cal.com permet de partager un créneau au nom d’une équipe plutôt qu’au nom d’une personne. C’est le réglage que prennent les équipes commerciales et les équipes de recrutement, donc celui qui produit le plus de réservations.
Votre Kastel ne sait pas déplier une équipe Cal.com en liste de personnes. Il refuse donc de deviner, et un rendez-vous pris au nom d’une équipe n’est rangé dans aucun service tant qu’un administrateur n’a pas décidé. Deviner reviendrait à le ranger dans le service d’un membre au hasard, en le montrant à des gens étrangers à ce rendez-vous ou en le cachant à ceux qui l’ont pris. La règle générale est décrite dans gouverner son savoir.
Les réservations portées par une personne suivent l’hôte. Quand les hôtes appartiennent à plusieurs services, quand l’un d’eux est inconnu de votre gouvernance, ou quand une place d’hôte ne peut être rattachée à personne, la réservation attend elle aussi.
Une différence avec l’autre outil de réservation mérite d’être dite. Chez Cal.com, l’hôte d’une réservation peut changer, et l’appartenance d’une personne à une équipe aussi, sans que rien de visible bouge dans la réservation. Votre Kastel les rattrape à sa passe de rapprochement, en recalculant le service de chaque réservation suivie et en la déplaçant quand la réponse a changé. Entre deux passes, un changement d’hôte reste brièvement en retard.
Ce que les équipes nous demandent avant de brancher Cal.com
Une IA pourra-t-elle me dire avec qui j’ai rendez-vous demain ?
Non, pas par ce connecteur. Le nom, l’adresse mail et le téléphone des participants ne sont jamais écrits, et le titre qui les contiendrait n’est jamais repris. Une IA branchée saura qu’un rendez-vous de tel type existe, à telle heure, avec tel hôte de votre équipe, et combien de personnes sont attendues.
Nous hébergeons Cal.com nous-mêmes, est-ce que ça change quelque chose ?
L’adresse de l’interface est un réglage de votre installation, donc une instance que vous hébergez est prise en charge comme le service en ligne. Deux règles ne bougent pas. La connexion se fait toujours en HTTPS, et une instance posée sur votre réseau privé demande une autorisation explicite de la personne qui installe. La clé d’accès voyage dans un en-tête et jamais dans une adresse, donc elle ne se retrouve pas dans un journal de serveur.
Une réservation annulée sort-elle de votre Kastel ?
Non. Une annulation ou un refus marque la réservation comme disparue à la source, et elle est conservée, lisible par les mêmes personnes qu’avant, jusqu’à ce qu’un administrateur décide de l’effacer. Une réservation annulée avant d’avoir été lue, en revanche, n’entre jamais : une annulation ne vaut jamais comme contenu.
Et les rendez-vous déjà passés ?
Un rendez-vous passé reste une connaissance de l’entreprise et il est lu comme les autres, tout comme un rendez-vous qui attend encore la confirmation de son hôte. La fenêtre de lecture remonte à 180 jours par défaut et prend tous les rendez-vous à venir.
Ce que ce connecteur ne fait pas
Il ne lit pas les agendas de vos équipes. Seules les réservations prises à travers Cal.com entrent dans votre Kastel, et une réunion créée directement dans un agenda relève du connecteur Google Calendar.
Les intitulés se ressemblent, et c’est assumé. Comme l’intitulé écrit est celui du type de rendez-vous, dix réservations du même créneau portent le même. Une IA branchée les distingue par leur horaire et par leur hôte, jamais par leur objet.
Le nom du type de rendez-vous est du texte que votre équipe écrit. Un créneau nommé d’après un client, un projet confidentiel ou un motif médical entre avec ce nom.
Le rapprochement complet se paie. Chaque passage relit toutes les réservations de la fenêtre plutôt que les seules modifications, parce que l’interface de Cal.com sait dire ce qui a changé mais pas ce qui a été supprimé. Sans cette relecture entière, une annulation passerait inaperçue et votre Kastel garderait un rendez-vous que plus personne n’a.
Les connecteurs ne sont pas ce que vous payez.
La page des tarifs dit ce que contient le cœur gratuit, où commence le payant, et à partir de quelle taille une équipe a besoin d’autre chose.
Voir les tarifs
