Solutions · Beauty & wellness
Nous connectons l’assistant à votre système de réservation via six outils qu’il appelle pendant la conversation : les services avec les prix réels, les spécialistes avec les procédures de chacun, la disponibilité, la création, l’annulation et le déplacement d’une réservation. La source de vérité reste votre agenda ; nous n’en tenons pas un second.
Déjà construitConectorul e scris și rulat: 946 de linii în modulul de integrare cu sistemul de programări Altegio, cu șase unelte expuse agentului, fiecare cu termen propriu de execuție — 15 secunde pentru lista de servicii, 30 pentru disponibilitate, 20 pentru creare, anulare și mutare. Uneltele sunt legate în punctul unic de execuție al agentului, alături de celelalte 15 tipuri de unelte interne ale platformei. A doua implementare pe care ne sprijinim e platforma de asistenți în sine, în producție: canale cu cod propriu, bază de cunoștințe indexată și predare către om cu evidență în baza de date. Rezerva: conectorul e scris pentru un singur sistem de programări. Dacă salonul tău folosește altceva, prima etapă e o verificare de compatibilitate, nu o promisiune.
Dans un salon, presque chaque message reçu correspond à la même conversation en quatre répliques : quels services avez-vous, combien cela coûte, qui le fait, quand c’est libre. Cela se répète des dizaines de fois par jour, presque toujours en dehors des horaires ou exactement au moment où l’administrateur a les mains prises. Un assistant qui répond aux trois premières questions et s’arrête à la quatrième ne résout rien — la personne appellera quand même, et vous paierez quand même quelqu’un pour répondre.
C’est pourquoi nous avons poussé l’intégration jusqu’au bout : l’agent ne dit pas seulement quels créneaux sont libres, il crée aussi la réservation dans le système du salon, l’annule et la déplace. La réservation s’écrit directement dans votre agenda, via l’interface du système que vous utilisez déjà. Nous ne gardons pas chez nous un second agenda qu’il faudrait ensuite accorder avec le premier — la source de vérité reste unique, car deux agendas signifient, tôt ou tard, deux clients au même créneau.
Le détail de terrain qui fait la différence entre une intégration qui fonctionne et une autre qui « répond toujours qu’il n’y a pas de place » est une règle du système de réservation, écrite telle quelle dans notre code : le service et le spécialiste voyagent ensemble. Si vous demandez les créneaux d’un spécialiste pour un service qu’il ne fait pas, vous obtenez zéro résultat — non pas une erreur, mais une réponse vide, qui ressemble exactement à « nous n’avons pas de place ». C’est pourquoi l’outil de disponibilité ne renvoie pas « libre/occupé » : il renvoie quels spécialistes font le service demandé et les premiers créneaux libres pour chacun, triés par le plus tôt, afin que l’agent propose une alternative concrète au lieu de fermer la conversation.
Et la durée réelle d’une procédure est un deuxième piège de la même famille : la liste globale des services renvoie une durée vide, et la vraie durée n’apparaît que lorsque vous interrogez de manière filtrée par spécialiste. Sans cette correction, l’agent propose des créneaux qui n’entrent pas dans l’agenda. Ce sont des choses que vous n’apprenez pas dans la documentation, mais après que l’intégration a tourné sur des données réelles.
Ce que cela comprend
Le premier outil renvoie les services actifs, avec les vrais prix de votre agenda, filtrables selon une formulation libre du client en roumain ou en russe, les plus adaptés en premier. Délai d’exécution 15 secondes. Quand vous changez un prix dans le système, l’agent l’énonce changé — il n’existe pas chez nous de fichier qui reste en retard.
L’outil de disponibilité reçoit le service — par identifiant ou par dénomination recherchée — et, en option, le spécialiste préféré, qui est placé en premier, avec les alternatives affichées. Le résultat est la liste des spécialistes qui font ce service et les premiers créneaux libres pour chacun, triés par le plus tôt. Délai : 30 secondes, car la requête touche plusieurs points.
L’outil de création reçoit le spécialiste, le ou les services, la date et l’heure, le téléphone et le nom du client, éventuellement l’e-mail, un commentaire et la durée. Le résultat est une réservation dans l’agenda du salon, avec un identifiant. À partir de là, elle vit dans votre système, pas chez nous — l’administrateur la voit là où il regarde d’habitude.
L’annulation demande l’identifiant de la réservation et, éventuellement, le motif ; le déplacement change l’heure tout en conservant la réservation. Sans ces deux-là, toute intégration de réservations est à moitié faite : les clients annulent et déplacent plus souvent qu’ils ne réservent, et si l’agent ne peut pas le faire, le travail revient à l’humain exactement au moment le plus agaçant.
Le sixième outil renvoie la liste des spécialistes avec les procédures que chacun réalise et la durée de chaque procédure en minutes — il est possible de filtrer par le nom du spécialiste ou par service. C’est l’outil qui répond à « qui fait la laminage » et, plus important, c’est lui qui donne à l’agent la durée avant de proposer une heure. Détail qui n’apparaît qu’en pratique : la durée réelle n’apparaît que lorsque vous interrogez avec un filtre par spécialiste ; la liste globale est renvoyée vide.
Le jeton de partenaire est une seule clé, conservée dans l’environnement du serveur, jamais dans la base de données par outil. Vous connectez le salon avec l’identifiant de l’entreprise, qui est validé avant d’être enregistré : la liste publique des services pour cet identifiant est demandée et le nombre est compté. Si cela ne répond pas, l’intégration n’est pas enregistrée — mieux vaut échouer à la connexion qu’en face d’un client.
Le filtre de sécurité du fournisseur répond 403 à un identifiant client implicite, donc l’intégration envoie un identifiant propre. C’est le genre de détail qui, s’il n’est pas découvert, provoque des jours à chercher la cause au mauvais endroit — et il est écrit dans le commentaire du code justement pour que la personne suivante ne les perde plus.
Le fil a un état explicite `bot` ou `human`, le journal de prise en charge connaît la prise en charge par un humain, le retour au bot et la réactivation automatique, et le fil a séparément un état de respect du délai de réponse. Dans un salon, les moments qui demandent un humain sont prévisibles : la réclamation après une procédure, la demande de réduction, la question sur un problème de peau.
Il ne recommande pas de traitements et n’évalue pas un problème de peau, de cheveux ou d’ongles — même lorsque le client insiste, car la réponse serait une affirmation sur la santé de quelqu’un. Il ne négocie pas les prix et n’accorde pas de réductions sauf si la règle est écrite et vérifiable. Et il ne fonctionne pas à ce niveau si le salon n’a pas un système de réservation avec interface — alors il prend la demande et la transmet à un humain, ce qui est un travail différent et doit être dit avant.
Traseul
La première étape est une vérification, pas une promesse : quel système vous utilisez, quelle interface publique il a, s’il répond assez vite pour une conversation. Le connecteur que nous avons écrit est pour un système précis. Pour un autre, nous livrons le résultat de la vérification et l’estimation du travail, y compris lorsque la réponse est qu’il ne peut pas fonctionner au niveau de la réservation automatique.
La connexion se fait avec l’identifiant de votre entreprise, validé sur-le-champ par rapport à l’interface publique de réservation : les services sont demandés et comptés. Nous livrons l’intégration connectée, avec le nombre de services lus — si le chiffre ne correspond pas à la réalité du salon, cela se voit immédiatement, pas dans un mois.
Les six outils sont attachés à votre agent, pas à tous. Dans son rôle, nous écrivons explicitement ce qu’il n’a pas le droit de faire : recommander des traitements, évaluer un problème médical, promettre un résultat, accorder une réduction non confirmée. Nous livrons la configuration de l’agent et la liste des outils attachés.
Nous démarrons avec un transfert vers un humain configuré largement et avec le journal des requêtes activé. Nous lisons les conversations des premiers jours — c’est là que l’on voit les formulations locales que l’agent n’associe à aucun service. Nous livrons le rapport avec les correspondances manquées et les corrections apportées.
Les données
Les règles diffèrent d’un secteur à l’autre. Voici celles qui s’appliquent au beauty & wellness.
Un cas
La situation
Un assistant connecté au système de réservation d’un salon répondait correctement aux services et aux prix, mais à la question « quand est-ce libre » il renvoyait, pour certaines combinaisons, une réponse vide. Pas une erreur — une réponse vide, qui dans une conversation ressemble exactement à « nous n’avons pas de place ».
Ce que nous avons construit
La cause est une règle du système de prise de rendez-vous : le service et le spécialiste voyagent ensemble. Les créneaux d’un spécialiste pour un service qu’il ne réalise pas renvoient zéro résultat. J’ai réécrit l’outil de disponibilité pour qu’il parte du service, et non de la personne : il renvoie les spécialistes qui effectuent ce service et les premiers créneaux libres pour chacun, triés du plus tôt au plus tard, avec le spécialiste préféré placé en premier, mais en conservant les alternatives. Dans la même étape, j’ai aussi corrigé la durée des procédures, qui provient vide de la liste globale et n’est réelle qu’une fois filtrée par spécialiste, et j’ai ajouté un identifiant propre au client, car le filtre de sécurité du fournisseur répond 403 à celui par défaut.
Ce qui en est sorti
La conversation ne se termine plus par « ce n’est pas disponible ». L’agent propose une alternative concrète — un autre spécialiste, un autre horaire — et peut créer, annuler ou déplacer le rendez-vous dans l’agenda du salon, qui reste l’unique source de vérité.
Ce que le cas ne dit pas
Les corrections sont spécifiques au système de prise de rendez-vous pour lequel le connecteur est écrit. Pour un autre système, ses règles de terrain sont différentes et se découvrent de la même façon : en l’exécutant sur des données réelles, pas en lisant la documentation.
Questions
Il programme. Il existe un outil de création qui écrit le rendez-vous dans le système du salon, avec spécialiste, service, date, heure, téléphone et nom, et renvoie l’identifiant du rendez-vous. L’annulation et le déplacement sont aussi des outils. Si un fournisseur dit « programmer » mais ne peut pas annuler ni déplacer, l’intégration est à moitié faite.
La raison la plus fréquente, dans le système avec lequel nous travaillons, est que le service et le spécialiste voyagent ensemble : si l’on demande les créneaux d’un spécialiste pour un service qu’il ne réalise pas, la réponse est zéro résultat, pas une erreur. C’est pourquoi notre outil de disponibilité part du service et renvoie les spécialistes qui le réalisent, avec les premiers créneaux libres de chacun. C’est une correction écrite dans le code, pas un réglage.
Ce qui change, c’est ce que l’agent peut faire : il prend la demande complète — service, spécialiste préféré, intervalle, contact — et la transmet à une personne, au lieu de réserver. C’est utile, mais c’est un autre travail et nous l’appelons autrement. Nous ne vous vendons pas une « prise de rendez-vous automatique » au-dessus d’un agenda papier.
Oui, et c’est le comportement implicite de l’outil : le spécialiste préféré est placé en premier, mais les alternatives sont affichées, avec les premiers créneaux libres pour chacun, triés du plus tôt au plus tard. Un agent qui répond « ce n’est pas disponible » et se tait perd exactement le client qui était prêt à venir.
À partir de l’outil des spécialistes, qui renvoie les procédures de chacun avec la durée en minutes. Le détail qui compte : la liste globale de services renvoie une durée vide, et la durée réelle n’apparaît que filtrée par spécialiste. Sans cette correction, l’agent proposerait des heures qui ne rentrent pas. C’est écrit dans le code parce que nous l’avons découvert sur des données réelles.
Il le note dans le rendez-vous, si vous lui avez demandé cela, et ne donne aucun conseil. Il n’évalue pas, ne recommande pas un produit, ne dit pas si la procédure convient — ce serait une affirmation sur la santé d’une personne, faite par un système automatique. Il transmet la conversation à un spécialiste. L’information écrite par le client est donnée d’une catégorie spéciale et est traitée comme telle, y compris pour le délai de conservation.
L’erreur est visible et réparable au même endroit où elle s’est produite : le rendez-vous est dans votre agenda, et les mêmes outils peuvent l’annuler ou le déplacer. La plateforme conserve la trace de l’exécution — quel outil a été appelé, avec quels paramètres et avec quel résultat — donc on peut reconstituer ce qui s’est passé. Lors de la configuration, nous définissons ce qu’il a le droit de faire seul et ce qui exige la confirmation d’une personne, et cela s’écrit, cela ne se suppose pas.
Seulement si vous lui donnez explicitement accès. Les outils connectés aujourd’hui couvrent les services, les spécialistes, la disponibilité, la création, l’annulation et le déplacement. L’historique des visites est une autre catégorie de données, avec d’autres conséquences, et ne s’active pas par réflexe parce que « c’est utile ».
Sur ceux sur lesquels vos clients écrivent déjà et qui ont leur propre code dans la plateforme : Instagram Direct et Messenger — d’où provient la plus grande partie des messages dans un salon — Telegram, WhatsApp via Cloud API et le widget de la page. Les outils de programmation sont les mêmes sur tous ; il n’existe pas de version plus faible sur un canal.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.