Разделите заявку и подтверждённую запись
В первом варианте посетитель выбирает желаемую услугу и время, после чего администратор связывается с ним для согласования. Во втором система сама проверяет доступность и сохраняет подтверждённую запись. Это разные по сложности сценарии. Не показывайте сообщение «Вы записаны», если сотрудник ещё должен проверить расписание.
Выберите один вариант для начала и опишите его в приветствии. Если требуется ручное подтверждение, объясните дальнейший шаг. Если запись подтверждается автоматически, проверьте, что сотрудник сразу видит занятую позицию в рабочем расписании. Клиенту не должно приходиться уточнять, состоялась ли запись на самом деле.
Определите единый источник расписания
Запишите, где хранится актуальное свободное время: в действующей системе записи, CRM или отдельном календаре. Важно, чтобы изменения через администратора и через бота попадали в согласованный процесс. Два независимых расписания, которые сверяют по памяти, создают риск конфликтов.
Для каждой услуги укажите длительность, возможных исполнителей и необходимые перерывы. Решите, что происходит при опоздании, изменении графика или отсутствии сотрудника. Эти правила задаёт бизнес; разработчик должен получить их до реализации. Отдельно согласуйте, какой часовой пояс видит клиент, если это может быть неоднозначно.
Спроектируйте выбор и окончательное подтверждение
Сначала предложите услугу, затем необходимые параметры и доступное время. Перед сохранением покажите итог: услуга, сотрудник при необходимости, дата, время и место. Дайте возможность вернуться и исправить выбор. Не просите сведения, которые не используются для записи или связи.
Предусмотрите одновременный выбор последнего свободного времени двумя людьми. При окончательном подтверждении доступность нужно проверить повторно и сохранить запись так, чтобы конфликт не возник незаметно. Если время уже занято, клиент должен получить понятное объяснение и возможность выбрать другой вариант. Конкретное техническое решение согласуйте с разработчиком расписания.
Сделайте перенос и отмену частью сценария
Опишите, как клиент находит свою запись и запрашивает изменение. Уточните, какие действия доступны самостоятельно, а какие требуют администратора. После отмены или переноса информация должна одинаково обновляться для клиента, сотрудника и источника расписания. Старое уведомление не должно оставаться единственным ориентиром.
Для переноса проверьте порядок операций: нельзя потерять старую запись, если новое время сохранить не удалось. Согласуйте правило на такой случай. Если у бизнеса есть ограничения на отмену, сообщайте их до подтверждения записи и используйте только реально действующие условия, которые команда сможет объяснить клиенту.
Проверьте уведомления и рабочий день администратора
Сотруднику нужны сведения, по которым он может подготовиться к визиту и связаться с человеком при изменениях. Определите, где он видит новые записи, отмены и неудачные попытки передачи данных. Уведомление должно помогать действию: открыть запись, проверить контакт или обработать исключение.
Если предусмотрены напоминания, проверьте их на своих аккаунтах. После переноса не должно уходить сообщение со старым временем. Отправка напоминания и подтверждённый визит — разные события, поэтому учитывайте их отдельно. Предусмотрите понятный рабочий путь, если сообщение не удалось доставить.
Испытайте пограничные ситуации до запуска
Проверьте запись в последнее свободное время с двух тестовых аккаунтов, повторное нажатие подтверждения, отмену и перенос. Затем измените расписание со стороны администратора и убедитесь, что бот использует обновлённые данные. Испытайте недоступность связанной системы: посетитель не должен получать ложное подтверждение.
Условный пример: из 30 тестовых попыток 20 должны завершиться записью, пять — сообщением о занятом времени и пять — корректной отменой. Все 30 сравниваются с заранее записанным ожиданием. Это план проверки, не прогноз клиентского поведения. Любую двойную бронь разбирайте отдельно, даже если остальные проверки прошли.
Оцените пилот по завершённым действиям
После запуска считайте начатые сценарии, подтверждённые записи, отмены и фактические визиты по вашим правилам учёта. Изучайте шаги, на которых люди останавливаются. Если свободного времени нет, это не обязательно проблема интерфейса; если клиент не понимает, записан ли он, нужно исправить подтверждение.
В Дело Прёт можно обсудить бота для записи и подключение к текущему расписанию. Напишите через форму или мессенджер ниже, какие услуги вы оказываете, где ведёте календарь и кто сейчас подтверждает визиты. Эти сведения помогут определить подходящий сценарий и объём интеграции.