Бот для записи клиентов: план без накладок и потерянных слотов

Бот — интерфейс расписания, а не отдельный календарь

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

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

Что описать до сценария сообщений

Составьте контракт записи и исключений, прежде чем рисовать кнопки.

• Опишите услуги, длительность, буфер до и после, совместимые ресурсы, филиалы, часовые пояса и минимальный срок до визита.
• Зафиксируйте источник расписания и операцию бронирования: запрос слотов, временное удержание, подтверждение, перенос и отмену.
• Определите, какие данные нужны для записи, где хранится согласие и как клиент подтверждает номер или учётную запись.
• Перечислите исключения: нет подходящего времени, несколько услуг подряд, опоздание, лист ожидания, предоплата и ручное подтверждение.
• Назначьте владельца очереди передачи оператору и срок ответа вместе с полным контекстом диалога.

Пошаговый запуск бота записи

Сначала автоматизируйте прямой сценарий одной услуги и одного источника расписания.

• Выберите канал и идентифицируйте пользователя так, чтобы повторный визит связывался с профилем без раскрытия чужих записей.
• Сделайте каталог услуг управляемым из источника данных, а не зашитым в реплики бота.
• Показывайте ограниченную подборку актуальных слотов и повторно проверяйте выбранное время перед окончательным подтверждением.
• Используйте временное удержание или атомарную команду создания записи с устойчивым ключом, чтобы параллельные диалоги не заняли один слот.
• Отправляйте подтверждение с услугой, адресом, локальным временем, правилами подготовки и доступными действиями переноса и отмены.
• Настройте напоминания по статусу записи, учитывая согласие, тихие часы, доставку и альтернативный канал при критичном сообщении.
• Проведите пилот на одном филиале или специалисте и сверяйте систему записи, CRM, уведомления, неявки и ручные исправления.

Надёжная модель слота

Каждое действие должно быть повторяемым и иметь однозначный подтверждённый статус.

• Слот содержит ресурс, начало, длительность, часовой пояс, услугу и версию доступности.
• Команда бронирования принимает устойчивый ключ диалога и возвращает идентификатор записи из источника правды.
• Тайм-аут считается неопределённым результатом: бот сначала проверяет запись, а не создаёт её повторно.
• Перенос создаёт связанное изменение или новую бронь с контролируемой отменой старой, исключая временную потерю места.
• Оператор получает историю выбора, данные клиента, статус интеграции и разрешённые действия, а не скриншот переписки.

Почему запись ломается

Красивый диалог не компенсирует слабый контракт расписания.

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

Что измерять после запуска

Воронка должна отделять качество диалога от доступности расписания и надёжности интеграции.

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

Итог

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

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

Контракт команды записи

• Запрос — клиент, услуга, ресурс, локальное время и устойчивый ключ.
• Проверка — актуальность слота, права, ограничения и срок удержания.
• Ответ — идентификатор записи, статус, адрес и допустимые действия.
• Неопределённость — проверка после тайм-аута и безопасная передача оператору.