Solutions · Beauty & wellness
We connect the assistant to your booking system through six tools it calls during the conversation: services with real prices, specialists with each of their procedures, availability, creating, cancelling, and moving an appointment. Your calendar remains the source of truth; we do not keep a second one.
Already builtThe connector is written and running: 946 lines in the integration module with the Altegio scheduling system, with six tools exposed to the agent, each with its own execution term — 15 seconds for the services list, 30 for availability, 20 for creation, cancellation and move. The tools are linked in the agent’s single execution point, alongside the platform’s other 15 types of internal tools. The second implementation we rely on is the assistants platform itself, in production: channels with their own code, indexed knowledge base and handover to a person with recording in the database. The reservation: the connector is written for a single scheduling system. If your salon uses something else, the first stage is a compatibility check, not a promise.
In a salon, almost every message received is the same conversation in four replies: what services do you offer, how much do they cost, who does them, when is it free. It repeats dozens of times a day, almost always outside working hours or exactly when the administrator has their hands full. An assistant that answers the first three questions and stops at the fourth solves nothing — the person will still call, and you will still pay someone to answer.
That is why we built the integration all the way through: the agent not only says which slots are free, but creates the appointment in the salon system, cancels it, and moves it. The appointment is written directly into your calendar, through the interface of the system you already use. We do not keep a second calendar that then has to be reconciled with the first — the source of truth remains a single one, because two calendars mean, sooner or later, two clients at the same time.
The field detail that makes the difference between an integration that works and one that “always says it is not free” is a rule of the booking system, written as such in our code: the service and the specialist travel together. If you request the hours of a specialist for a service they do not provide, you get zero results — not an error, but an empty response, which looks exactly like “we do not have any slots”. That is why the availability tool does not return “free/busy”: it returns which specialists provide the requested service and the first free slots for each, sorted by the earliest, so the agent can suggest a concrete alternative instead of ending the conversation.
And the real duration of a procedure is a second trap in the same family: the global service list returns an empty duration, and the true duration appears only when you ask filtered by specialist. Without that correction, the agent suggests slots that do not fit into the calendar. These are things you do not learn from the documentation, but only after the integration has run on real data.
What it covers
The first tool returns active services, with the real prices from your calendar, filterable by a free-form customer query in Romanian or Russian, the most suitable first. Execution time 15 seconds. When you change a price in the system, the agent says it changed — there is no file on our side that can lag behind.
The availability tool receives the service — by identifier or by the searched name — and, optionally, the preferred specialist, who is placed first, but with alternatives shown. The result is the list of specialists who provide that service and the first free slots for each, sorted by the earliest. Term: 30 seconds, because the query touches several points.
The creation tool receives the specialist, the service or services, the date and time, the client’s phone number and name, optionally the e-mail, a comment, and the duration. The result is an appointment in the salon’s calendar, with an identifier. From there on it lives in your system, not with us — the administrator sees it where they usually look.
Cancellation requires the booking identifier and, optionally, the reason; rescheduling changes the time while keeping the booking. Without these two, any booking integration is only half there: clients cancel and reschedule more often than they book, and if the agent cannot, the work returns to a human at the most irritating moment.
The sixth tool returns the list of specialists with the procedures each one performs and the duration of each procedure in minutes — it can be filtered by the specialist’s name or by service. It is the tool that answers “who does the lamination” and, more importantly, the one that gives the agent the duration before it proposes a time. A detail that is discovered only in practice: the real duration appears only when you ask filtered by specialist; the global list returns empty.
The partner token is a single key, kept in the server environment, never in the per-tool database. You connect the salon with the company identifier, which is validated before being saved: the public service list for that identifier is requested and counted. If it does not respond, the integration is not saved — better to fail at connection than in front of a client.
The provider’s security filter returns 403 for a default client identifier, so the integration sends its own identifier. It is the kind of detail that, if undiscovered, creates days of looking for the cause in the wrong place — and it is written in the code comment precisely so the next person does not lose them either.
The thread has explicit `bot` or `human` state, the handover log knows human takeover, return to bot and automatic reactivation, and the thread has separate response-time compliance state. In a salon, the moments that require a human are predictable: a complaint after a procedure, a request for a discount, a question about a skin issue.
It does not recommend treatments and does not assess a skin, hair or nail issue — not even when the client insists, because the answer would be a statement about someone’s health. It does not negotiate prices and does not grant discounts unless the rule is written and verifiable. And it does not work at this level if the salon does not have a booking system with an interface — then it takes the request and passes it to a human, which is a different job and must be said in advance.
Traseul
The first stage is a check, not a promise: what system you use, what public interface it has, whether it responds quickly enough for a conversation. The connector we have written is for a specific system. For another one, we deliver the check result and the work estimate, including when the answer is that there is no way it can work at the level of automated booking.
Connection is made with your company identifier, validated immediately against the public booking interface: the services are requested and counted. We deliver the connected integration, with the number of services read — if the figure does not match the salon’s reality, it is visible immediately, not in a month.
The six tools are attached to your agent, not to everyone. In its role we explicitly write what it is not allowed to do: recommend treatments, assess a medical issue, promise an outcome, grant an unconfirmed discount. We deliver the agent configuration and the list of attached tools.
We start with wide human handover enabled and query logging turned on. We read the conversations from the first days — that is where the local formulations appear that the agent does not match to any service. We deliver the report with the missed matches and the corrections made.
The data
The rules differ from one industry to another. These are the ones that apply in beauty & wellness.
A case
The situation
An assistant connected to a salon booking system was answering correctly about services and prices, but when asked ‘when is it free’ it returned, for certain combinations, an empty response. Not an error — an empty response, which in conversation looks exactly like ‘we have no availability’.
What we built
The cause is a rule of the booking system: the service and the specialist travel together. A specialist’s slots for a service they do not provide return zero results. We rewrote the availability tool so it starts from the service, not the person: it returns the specialists who provide that service and the first free slots for each, ordered by the earliest, with the preferred specialist listed first, but with alternatives retained. In the same stage we also fixed the procedure duration, which comes empty from the global list and is real only when filtered by specialist, and we set a dedicated client identifier, because the provider’s security filter returns 403 on the default one.
What came out
The conversation no longer ends with ‘not available’. The agent proposes a concrete alternative — another specialist, another time — and can create, cancel or move the booking in the salon diary, which remains the only source of truth.
What the case does not say
The fixes are specific to the booking system for which the connector is written. For another system, its field rules are different and are discovered the same way: by running on real data, not by reading the documentation.
Questions
It books. There is a creation tool that writes the appointment into the salon system, with specialist, service, date, time, phone number and name, and returns the appointment identifier. Cancellation and rescheduling are tools too. If a provider says “book” but cannot cancel and reschedule, the integration is half done.
The most common reason, in the system we work with, is that the service and specialist travel together: if you ask for a specialist’s slots for a service they do not perform, the reply is zero results, not an error. That is why our availability tool starts from the service and returns the specialists who perform it, with each of their first free slots. It is a correction written in code, not a setting.
What changes is what the agent can do: it takes the full request — service, preferred specialist, interval, contact — and passes it to a person instead of booking. It is useful, but it is a different job and we call it differently. We do not sell you “automatic booking” over a paper diary.
Yes, and that is the tool’s default behaviour: the preferred specialist is placed first, but alternatives are shown, with each person’s first free slots, ordered by the earliest. An agent that replies “not available” and goes silent loses exactly the client who was ready to come.
From the specialists tool, which returns each person’s procedures with the duration in minutes. The detail that matters: the global service list returns an empty duration, and the real duration appears only when filtered by specialist. Without that correction, the agent would suggest slots that do not fit. It is written in code because we discovered it on real data.
It notes it in the appointment, if you asked it to, and gives no advice. It does not assess, does not recommend a product, does not say whether the procedure is suitable — that would be a statement about a person’s health, made by an automated system. It passes the conversation to a specialist. The information written by the client is data from a special category and is treated as such, including for the retention period.
The mistake is visible and fixable in the same place where it was made: the appointment is in your diary, and the same tools can cancel or reschedule it. The platform keeps the execution trail — which tool was called, with which parameters and with what result — so it is possible to reconstruct what happened. During configuration we decide what it is allowed to do on its own and what requires human confirmation, and that is written, not implied.
Only if you give it access to it, explicitly. The connected tools we have today cover services, specialists, availability, creation, cancellation and rescheduling. Visit history is another category of data, with other consequences, and it is not enabled by reflex just because “it is useful”.
On the ones your clients already write on and which have their own code in the platform: Instagram Direct and Messenger — where most messages in a salon come from — Telegram, WhatsApp via Cloud API and the widget on the page. The booking tools are the same on all of them; there is no weaker version on any channel.
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.