Бот для записи клиентов: где живёт расписание и откуда берутся двойные записи

Разработчик бота для стоматологии выложил разбор: в первое же утро после запуска бот записал сорок семь человек на уже занятое время. К девяти утра к одному креслу пришли двое, к половине десятого трое.

Код при этом работал правильно. Бот проверял расписание, видел время свободным и подтверждал запись клиенту за три секунды, а сама запись доезжала до календаря за пять-восемь. В этот разрыв время выглядело свободным для всех остальных.

Ниже — кто владеет расписанием, что происходит между «клиент выбрал время» и «мастер увидел запись», сколько стоит такая связка и что в ней ломается на второй месяц.

Про уровни ботов, общие вилки цен и выбор канала есть отдельный разбор: чат-бот для бизнеса. Там запись стоит одним пунктом среди того, что умеет бот с кнопками. Соседняя половина темы — бот для обратной связи: здесь бот занимает время до визита, там снимает сигнал после. Здесь речь о том, что начинается после нажатия этой кнопки. Разделять стоит вот почему: запись — единственный сценарий, где на одно и то же время одновременно претендуют мессенджер, телефон и живая очередь у стойки.

Кто владеет расписанием

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

Источник правды

Три места, где может жить расписание

Авторитетным остаётся одно из них. Остальные — отражение, которое обновляется следом.

Своя база бота

Бот сам ведёт расписание: услуги, мастера, длительность, занятость.

Любые правила и исключения
Ничего не зависит от чужого API
Дешевле на старте

Упирается: если параллельно есть журнал или тетрадь, появляется второе расписание, и они разъезжаются за неделю.

Система записи

YCLIENTS, Dikidi и аналоги. Бот работает как ещё один канал записи.

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

Упирается: в то, что отдаёт API. У YCLIENTS он полноценный, с уведомлениями об изменениях; у Dikidi заметно у́же — сложную логику на нём не собрать.

Календарь мастера

Google- или Яндекс-календарь, в который бот кладёт события.

Самый быстрый старт
Мастер видит день в привычном приложении

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

Оценка по документации YCLIENTS и разборам систем записи, сентябрь 2026.

Практическое правило: авторитетно ровно одно место. Внешний календарь хорош как витрина для мастера и плох как источник правды — на него нельзя опираться, решая, свободно ли время.

Два клиента на одно время

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

Зазор не виден на тестах. При проверке заявки идут по одной в минуту, и всё выглядит правильно. В понедельник утром или в первый день после праздников их десять в минуту, и схема ломается сразу.

Попытка починить это ожиданием делает хуже. Если ждать, пока запись доедет, человек смотрит пятнадцать-двадцать секунд на тишину, решает, что бот завис, и жмёт ещё раз. Вместо одной попытки получается три.

Путь одного времени

Как время перестаёт быть свободным для всех сразу

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

Проверка

Бот спрашивает у системы записи свободное время и показывает клиенту варианты.

Придержали

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

Важно: у пометки есть срок жизни — полминуты. Иначе сорванная запись блокирует время навсегда.

Запись

Данные уходят в систему записи. Перед созданием параметры проверяются ещё раз — у YCLIENTS для этого отдельный метод.

Подтверждение

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

Страховка: запрет пересекающихся записей на уровне базы, на случай ошибки в коде.

Схема собрана по разборам производственных сбоев в системах бронирования, 2026.

Расписание меняют и без бота

Администратор вписал клиента руками, мастер закрыл себе полдня, кто-то записался по телефону или через виджет на сайте. Бот об этом узнает последним.

Отсюда два требования. Первое: перед созданием записи время перепроверяется, а ответ «уже занято» считается штатным, а не сбоем — в API YCLIENTS под него выделен отдельный код ошибки, как и под «нет свободных сотрудников». Второе: об изменениях бот узнаёт по уведомлению от системы, а не опросом раз в пять минут. Опрос означает, что пять минут клиентам показывают устаревшее расписание.

Перенос, отмена и напоминания

В техническом задании обычно пишут «бот записывает клиента» и на этом останавливаются. Вторая половина работы начинается после записи.

Отмена должна освобождать время немедленно, иначе окно простаивает, хотя формально свободно. Здесь же задаётся правило «не позднее чем за столько-то часов» — это решение бизнеса, и принять его надо до разработки.

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

Напоминания — то, ради чего запись часто и автоматизируют. Поставщики таких решений заявляют снижение неявок на 30–50%; цифра правдоподобная, но свою придётся померить самому: доля неявок до подключения и через месяц после. Проверяемая часть проще: сообщение в мессенджере доходит заметнее, чем SMS, а в системах записи вроде YCLIENTS напоминание настраивается штатным параметром «за сколько часов предупредить».

Сколько стоит

Вилки по нашему прайсу, сентябрь 2026:

бот с кнопками, который ведёт расписание в своей базе — от 15 000 ₽;
связка с системой записи через API, один канал: свободное время, запись, отмена, напоминания — 80 000 ₽, 1–2 недели;
два канала, перенос, повторные визиты, отчётность — 150 000 ₽, 2–4 недели;
сопровождение — 8 000–15 000 ₽/мес в зависимости от числа интеграций;
нетиповые доработки по часам — 3 500 ₽/час.

Отдельная статья расходов — сама система записи. Тариф платится ей, а не подрядчику: у Dikidi есть бесплатный уровень и платный примерно от 990 ₽/мес, YCLIENTS дороже и считается по числу сотрудников.

Что ломается на втором месяце

Часовые пояса. В стране одиннадцать зон. Клиент из другого города видит время по-своему, если внутри оно хранится без привязки. Правило простое: внутри одно общее представление времени, на экране — время точки, где принимают.
Длительность и буфер. Окно в расписании не равно длительности услуги: между визитами нужны уборка, подготовка, дорога мастера. Без буфера день собирается плотно и разваливается к обеду.
Комплексные услуги. Позиция с названием «Комплекс 1» ничего не говорит ни клиенту, ни боту — ни состава, ни времени. Названия придётся привести в порядок до запуска.
Выключенная доступность. У мастера или услуги не стоит галочка «доступен для онлайн-записи», бот их не видит, а администратор уверен, что всё на месте. Типовая причина «бот не показывает свободное время».
Повторное нажатие. Клиент нажал дважды или потерял связь и повторил — без защиты появляются две записи на одного человека.

Когда бот записи не нужен

Поток маленький. Пять-десять записей в день, администратор и так у телефона — бот будет стоить дороже, чем экономит.

Расписания нет вовсе. Если сейчас всё в тетради и в голове, автоматизировать нечего: сначала система записи, через месяц бот к ней.

Запись не финальная. Замер, осмотр, диагностика — там сначала разговор, потом время. Бот здесь собирает заявку, и это уже другой сценарий, с передачей в CRM.

Как это выглядит в работе

Кейс именно по записи мы пока не выкладывали. Ближайший по устройству — бот для автодилера: круглосуточный приём обращения, разбор свободного текста, передача в AmoCRM без дублей, очередь повторов на случай недоступности CRM. Разница в том, что там бот собирает заявку. При записи он занимает ограниченный ресурс, за который конкурируют другие каналы, отсюда и удержание времени, и перепроверка перед подтверждением.

Частые вопросы

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

Можно без системы записи, чтобы бот вёл расписание сам? Можно, и это дешевле на старте. Работает, пока запись идёт только через бота. Как только появляются телефон и стойка администратора, нужен экран, где сотрудник видит день целиком и может поправить — и вы приходите к системе записи, только своими силами.

Работает ли это в MAX? Да, логика остаётся прежней, меняется слой работы с мессенджером. Перенос готового сценария — 15 000–30 000 ₽ по прайсу.

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

Коротко

Расписание должно жить в одном месте, и это место выбирается до разработки. Двойные записи появляются в зазоре между проверкой и созданием записи, лечатся коротким удержанием времени и перепроверкой перед подтверждением. Отмена, перенос и напоминания составляют половину работы, и её обычно забывают в техническом задании. Связка с готовой системой записи в одном канале — 80 000 ₽ и одна-две недели, дальше сопровождение. Если записей пять в день или расписания нет вовсе, начинать надо не с бота.

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