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