Разработчик показывает бота в своём телефоне. Выбирает услугу, вводит номер, подтверждает заявку. В рабочем чате появляется сообщение. Демонстрация занимает минуту, и кажется, что всё готово. Но клиент может ошибиться в номере, вернуться к вчерашней кнопке или написать вопрос посреди заполнения. Эти действия тоже входят в обычную жизнь бота.
На приёмке полезно повторить путь самостоятельно и сверить результат с тем, что получит сотрудник. Подготовьте отдельные тестовые данные и предупредите команду. Учебная заявка не должна закончиться звонком реальному человеку или отправкой товара. Порядок удаления тестов согласуйте заранее.
Ниже семь сценариев для бота, который принимает обращения на услуги. Каждый заканчивается проверяемым результатом. Их можно включить в задание ещё до разработки: тогда заказчик и исполнитель будут одинаково понимать, что считается работающей функцией. Общие вопросы выбора исполнителя разобраны в статье о заказе Telegram-бота у студии.
1. Новый пользователь начинает с опубликованной ссылки
Возьмите аккаунт, который раньше не общался с тестовым ботом. Откройте именно ту ссылку, которую планируете разместить на сайте или в рекламе. Проверьте имя, описание и первый ответ. Человек должен понять, какую задачу здесь можно решить и с какого действия начать.
Особенно внимательно проверьте ссылку с параметром запуска. Через неё можно передавать боту дополнительные сведения, например признак конкретного предложения. Механизм описан в документации Telegram о deep linking. Заказчику достаточно проверить получившийся сценарий: ссылка на одну услугу должна открывать согласованное начало диалога, без случайного перехода в другую ветку.
Затем зайдите по обычной ссылке без параметра. Она тоже может попасть к человеку при пересылке контакта бота. В этом случае требуется понятное общее начало. Если бот показывает ошибку из-за отсутствия рекламного параметра, добавьте такой вход в замечания.
При повторном запуске проверьте, что происходит с незавершённой заявкой. Бот может предложить продолжить её или начать заново по согласованному правилу. Подтверждение удаления черновика защищает пользователя от случайной потери уже введённого текста. Запишите выбранное поведение в протокол и повторите его после исправлений.
2. Человек ошибается в поле и меняет ответ
Дойдите до ввода телефона или другого обязательного сведения. Отправьте текст неподходящего формата, затем исправьте его. Сообщение об ошибке должно объяснить, какое значение требуется. Ответ «Некорректно» оставляет пользователя без инструкции, особенно если допустимы только некоторые варианты записи номера.
Проверьте и обычное копирование. Номер из записной книжки может содержать пробелы или скобки. Название компании бывает длиннее строки, которую использовали в демонстрации. Дайте разработчику примеры допустимых значений из вашей работы и согласуйте, как бот обрабатывает их.
После исправления вернитесь к предыдущему шагу и измените услугу. Сверьте зависимые вопросы. Если для выезда нужен адрес, а для удалённой консультации достаточно времени связи, бот должен применить соответствующий сценарий. Старые ответы не должны незаметно попадать в новую заявку, когда их смысл уже изменился.
Попробуйте отправить фотографию или голосовое сообщение вместо ожидаемого текста. Бот может объяснить, какой тип ответа поддерживает этот шаг, либо принять вложение, если это предусмотрено. Главное, чтобы человек получил понятный ответ и мог продолжить. Достаточно согласовать несколько распространённых действий; угадывать все мысли пользователя здесь не требуется.
3. Пользователь нажимает старую кнопку
Завершите заявку, прокрутите переписку вверх и нажмите кнопку из предыдущего шага. В чате остаются старые сообщения, поэтому такое действие вполне естественно. На приёмке проверьте, относится ли кнопка к уже закрытому обращению и что бот сообщает в ответ.
Например, пользователь видит вчерашнее «Подтвердить запись». К этому моменту выбранный час могли уже занять. Повторное нажатие должно привести к проверке актуальной доступности и понятному продолжению. Старое сообщение не даёт оснований повторно обещать услугу на уже занятый час.
Кнопки под сообщениями Telegram могут запускать разные действия. Их возможности описаны в разделе о клавиатурах ботов. На уровне бизнеса запишите требование к результату: какую заявку изменяет действие, когда оно устаревает и как пользователь переходит к текущему состоянию.
Повторите нажатие несколько раз подряд. Проверьте число созданных обращений в рабочей системе. Одна осмысленная операция пользователя должна иметь согласованный результат даже при повторном запросе. Если каждая попытка создаёт новую карточку, задача пока требует доработки. Примеры подобных проблем собраны в статье об ошибках разработки Telegram-ботов.
4. Заявка доходит до сотрудника с нужными сведениями
Сделайте тестовое обращение с заметной пометкой и попросите сотрудника найти его обычным способом. Проверка заканчивается там, где начинается работа команды. Сообщение в техническом чате разработчика ещё не подтверждает получение заявки вашим менеджером.
Сверьте услугу, контакты и комментарий. Если бот собирает филиал, время или вложение, проверьте и их. Сотрудник должен иметь возможность открыть переданный файл с той учётной записью, которой пользуется каждый день. Ссылка, доступная только разработчику, не решает рабочую задачу.
Проверьте, можно ли связать сообщение с записью в системе клиентов. Постоянный номер обращения помогает найти его после переадресации или переписки с коллегой. Данные о том, кто взял заявку в работу, должны быть доступны следующему сотруднику по согласованному порядку.
Затем измените состояние заявки. Менеджер может подтвердить запись, запросить уточнение или отклонить неподходящий запрос. Посмотрите, что видит клиент и какую историю сохраняет система. Если автоматические уведомления входят в задачу, сверяйте каждое с фактическим решением сотрудника.
При сложном обмене подключите к проверке человека, который отвечает за систему клиентов. Он подтвердит правильность полей и распределения заявок. Feature IT разрабатывает Telegram-ботов с передачей обращений в рабочие сервисы. Для постановки такой задачи полезен образец карточки, которую менеджер должен получить в конце диалога.
5. Клиенту требуется помощь человека
В середине сценария напишите вопрос, которого нет среди кнопок. Например, уточните возможность нестандартной услуги. Затем проверьте предусмотренный способ связи с сотрудником. Кнопка помощи должна вести к работающему каналу и объяснять, когда ждать ответ.
Согласуйте, какие сведения сотрудник получает вместе с обращением за помощью. Ему пригодится последний шаг диалога, выбранная услуга и уже сохранённые данные. Если клиенту приходится снова пересказывать всё с самого начала, передача требует улучшения. Лишние персональные сведения в общий рабочий чат отправлять тоже не нужно.
Проверьте работу вне расписания. Вечером клиент должен увидеть действующие часы ответа или другой предусмотренный способ обращения. Обещание «менеджер уже подключается» подходит только при реальной передаче. Настройку графика стоит испытать на тестовом времени вместе с разработчиком.
После ответа сотрудника вернитесь к автоматическому сценарию. Уточните, должен ли бот продолжать вопросы, ждать завершения разговора или предложить новое действие. Одновременные ответы человека и программы могут противоречить друг другу и запутать клиента. Это правило связано с рабочим процессом команды, поэтому его согласует ответственный за обслуживание.
Дополнительные варианты распределения работы рассмотрены в материале о задачах Telegram-бота для бизнеса. На приёмке выбирайте те, которые входят в согласованный проект. Новую идею можно записать отдельно и оценить после завершения обязательных сценариев.
6. Внешний сервис временно недоступен
Попросите разработчика воспроизвести в тестовой среде отказ сервиса, куда бот передаёт обращения. Это может быть система клиентов, расписание или обработчик уведомлений. Условия опыта должны исключать вмешательство в реальные заказы. Заказчику достаточно наблюдать поведение и сверять результат.
Отправьте тестовую заявку во время отказа. Проверьте, что бот сообщает человеку и где сохраняются данные. Если обращение принято с последующей отправкой, команда должна иметь возможность найти его в очереди. Если завершить действие сейчас нельзя, пользователь получает ясное объяснение и доступный следующий шаг.
После восстановления сервиса убедитесь, что сохранённая заявка дошла по назначению. Затем повторите проверку числа записей. Повторная отправка может потребоваться из-за задержки ответа, поэтому защита от лишних карточек проверяется и здесь. У разработчика должны остаться сведения о попытках передачи для разбора ошибки.
Отдельно испытайте перезапуск самого приложения бота в середине заполнения. Пользователь после этого может продолжить разговор из сохранённого состояния или получить предложение начать заново. Выбор зависит от проекта, но потеря данных должна быть понятна человеку. Молчаливый переход к первому вопросу легко принять за неисправность.
7. Заказчик проверяет доступы и рабочую версию
Перед приглашением клиентов уточните, кто управляет ботом, сервером и подключёнными сервисами. Доступы должны соответствовать согласованной схеме владения. Секреты передают принятым защищённым способом; в общий протокол достаточно записать систему и ответственного. Публиковать токен бота в переписке приёмки не требуется.
Проверьте роли на двух согласованных тестовых аккаунтах: сотрудника и обычного клиента. Административные действия должны быть доступны только сотруднику. Скрытой кнопки для этого недостаточно, права проверяются в обработчике действия на сервере. Попросите разработчика показать результат попытки без нужных полномочий и убедитесь, что рабочие данные остались прежними. Клиентские аккаунты для такого испытания используйте только с разрешения их владельцев; проще заранее завести отдельные тестовые.
Попросите сотрудника выполнить обычную операцию управления. Например, поменять график, скрыть услугу или обновить контакт. Проверьте результат в клиентском диалоге. Если изменение требует участия разработчика, зафиксируйте порядок обращения и ожидаемый срок реакции в условиях сопровождения.
Пройдите один полный заказ в рабочей версии с согласованной тестовой пометкой. Тестовая среда могла использовать другой чат менеджера или другую базу. Сверьте адреса получателей и подключённые ресурсы без раскрытия секретов. Затем удалите либо пометьте учебные записи по принятому правилу.
У результата каждого испытания оставьте короткий протокол. В нём нужны дата, проверяемая версия, шаги и наблюдение. Для замечания приложите номер обращения или запись экрана. Общая фраза «бот зависает» уступает точному описанию: «после изменения услуги кнопка подтверждения сохранила прежнюю цену».
| Ситуация |
Что сохранить для повторной проверки |
| Ошибка при вводе |
Введённое тестовое значение и ответ бота |
| Старая кнопка |
Сообщение с кнопкой и состояние обращения |
| Потеря передачи |
Номер заявки и время отправки |
| Помощь менеджера |
Момент передачи и результат у сотрудника |
| Сбой внешнего сервиса |
Условия опыта и сведения после восстановления |
Перед последним прогоном соберите все исправленные замечания в один список. Повторите затронутые сценарии и убедитесь, что соседние шаги сохранили своё поведение. Исправление телефона, например, может повлиять на возврат к предыдущему полю. История успешной демонстрации до правки этого уже не подтверждает.
Обсудите с Feature IT разработку и приёмку Telegram-бота, начав с того, какое обращение должен получить сотрудник. К этому результату можно привязать вопросы бота, обработку ошибок и проверку рабочей версии ещё до первого экрана.
Читайте также
