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