ИИ-бот записи клиентов должен проверять свободное время до подтверждения брони

Если расписание уже работает, разговорный бот становится ещё одним входом в него. Выбор между готовым сервисом и своей онлайн-записью разобран отдельно. Здесь задача уже: принять фразу клиента и создать бронь.

VisitTime предлагает запись через бота и сайт. ИИ полезен там, где меню не хватает: клиент описывает желаемую услугу, а бот уточняет её до выбора времени.

Разработчику передают примеры обезличенных обращений из работы сети. Демо с заранее выбранной услугой проверяет меню, но не доказывает, что бот понял свободную фразу.

Что считать свободным временем для сети услуг? Нужен весь интервал работы, подходящий специалист и ресурсы услуги. Пустого начала в календаре недостаточно.

Бот получает длительность из каталога, а не из ответа модели. Если услуга занимает час, свободное начало перед занятой половиной часа не делает весь визит возможным.

Google Calendar возвращает занятые интервалы. Правила услуги, перерывы и наличие кабинета поверх них должна учитывать ваша система записи, проверено 8 октября 2026.

Перед созданием брони бот показывает клиенту собранный запрос. В нём стоят услуга, филиал и полная дата с временем, а не только пересказ «завтра вечером».

На границе суток слово «завтра» меняет смысл. Бот привязывает его к согласованному часовому поясу и просит подтвердить конкретную дату до обращения к расписанию.

Ответ клиента подтверждает его выбор, но ещё не занятие места. Пока идёт диалог, администратор сети может записать на это время другого посетителя.

Повторная проверка перед записью нужна, но сама по себе не исключает двойную бронь. Между ответом «свободно» и сохранением другой запрос тоже успеет занять место.

Система должна проверять доступность и занимать ресурс одной защищённой операцией. Этот запрет нужен всем каналам записи, включая администратора и виджет сайта.

Cal.com выделяет временный резерв отдельной операцией. В API создания брони есть параметр обхода конфликтов: его нельзя включать в обычном пути записи клиента.

Потерянный ответ не означает, что запись не создалась. При сбое связи бот сначала ищет результат своей операции, а не сразу отправляет новую бронь.

Для каждой попытки сохраняют постоянный идентификатор. Повтор с тем же идентификатором должен находить исходную запись; сохранённый только в памяти бота признак исчезнет после перезапуска.

Telegram повторно отправляет событие боту, если не получил успешный ответ. А клиент может сам отправить ту же фразу снова. Это разные повторы, и разработчик проверяет оба.

На демонстрации смотрят диалог и запись в расписании рядом. Без второго экрана фраза «вы записаны» может оказаться текстом модели, за которым нет визита.

Условия «готово» входят в задачу для агента до начала разработки. Для бота это проверяемые исходы, а не просьба «отвечать вежливо и не ошибаться».

Руководитель принимает сценарии на вымышленных клиентах. Подрядчик показывает переписку и соответствующую ей запись, включая случаи отказа расписания.

Инженер ведёт машину агентов: описывает ограничения, поручает правки и принимает результат. Эта роль показана на публичном экране машины. Число написанных строк не доказывает, что бронь создана правильно.

У нас есть опыт Telegram-интеграции в продукте курса агентной разработки. Там бот публикует материалы из очереди. Это опыт подключения и проверки отправки, а не готовый бот записи для сети услуг.

Агенту можно поручить диалог, подключение расписания и проверки сбоев. Порядок подтверждения инженер закрепляет в правилах для агентов. Указание модели «не допускать дублей» не заменяет запрет в системе записи.

Наши поломки полезны здесь способом проверки. Работающий процесс ещё не доказывает, что операция дошла до нужного получателя. В записи таким получателем служит расписание сети.

При нехватке прав бот должен остановиться на заявке. Передача администратору сохраняет неопределённый результат операции, чтобы человек сначала сверил его с расписанием и не создал дубль вручную.

В журнале бота связывают запрос с исходом операции. Руководитель видит, что подтверждено, что ждёт человека и где повторяется сбой. Эти случаи пополняют приёмочные проверки следующей правки.

Боту нужен способ узнать доступное время и оформить согласованный визит. Читать историю всех клиентов ради этой задачи не требуется. Права задают в подключении, а не только в инструкции модели.

Агент, который пишет код, и бот, который обслуживает клиентов, получают разные доступы. Для разработки подходят вымышленные обращения; работу с данными клиентов у агента мы разбирали отдельно.

Фраза клиента не должна открывать служебную команду. Просьба показать соседние записи остаётся просьбой без прав, даже если модель решила, что это удобно.

Начать стоит с ограниченного списка услуг и одного филиала. Бот распознаёт запрос, уточняет дату и создаёт запись через действующее расписание. Остальные сценарии идут после его приёмки.

До разработки инженер проверяет, умеет ли расписание защищать место от конкурирующих запросов. Если нет, первая версия собирает заявку для администратора и прямо сообщает, что бронь ещё не подтверждена.

До подключения бота руководителю нужен разбор своего процесса. Можно обсудить первую задачу с инженером: какие услуги распознавать и что считать подтверждённой записью.

Для такой очереди правок есть подписка на разработку. «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Инженер с машиной агентов сдаёт код в репозиторий клиента.

В работе находится одна задача, следующая ждёт в очереди; пауза доступна в любой месяц. Первой задачей можно поставить распознавание услуги и времени с подтверждением через расписание. Цена относится к разработке, не к готовому боту.

После запуска считайте подтверждения без записи, дубли и передачи человеку. Каждый сбой должен давать воспроизводимую проверку. Тогда следующая правка исправляет причину, которую уже умеют замечать.

1. Подключите диалог к действующему расписанию; отдельный календарь бота создаёт новый источник конфликтов.

2. Подтверждайте визит по созданной записи, после проверки всего интервала и нужных ресурсов.

3. Принимайте конфликт, повтор и потерянный ответ. При неизвестном результате сначала ищите прежнюю бронь.

4. Начните с одного маршрута записи. Каждый сбой после запуска превращайте в проверку следующей правки.