VK-бот: ТЗ на сценарии, передачу оператору и интеграцию с CRM

Как подготовить требования к VK-боту

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

Этот материал посвящён структуре задания для бота сообщества. Примеры учебные; доступность конкретных методов и прав проверяют на выбранной версии API и настройках сообщества перед реализацией. В конце статьи можно скачать бриф с полями для сценариев, событий и приёмочных проверок.

Зафиксируйте границы первой версии

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

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

Укажите владельца сообщества, администратора интеграции и редактора ответов. Если бот зависит от личного доступа одного сотрудника, его отсутствие может остановить обслуживание. В задании нужен порядок поддержки и восстановления разрешённых доступов через штатные механизмы платформы.

Опишите диалог как состояния

Для каждого состояния задайте ожидаемый ввод, проверку, ответ и следующий шаг. Пользователь может написать текст вместо нажатия кнопки, прислать вложение или вернуться через несколько дней. Решите, сохраняется ли незавершённая заявка, когда она устаревает и как человек начинает заново.

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

В текстах используйте понятные ожидания: что сохранено, что ещё требуется и кто ответит дальше. Не называйте заявку принятой, пока целевая система её не подтвердила. Состояния «получено сообщение», «создано обращение» и «назначен оператор» могут происходить в разное время.

Согласуйте передачу человеку

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

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

Не обещайте мгновенный ответ, если команда его не обеспечивает. В брифе фиксируются реальное рабочее окно и порядок уведомления о задержке. Отсутствие свободного оператора должно быть видимым состоянием, а не бесконечным сообщением «соединяем».

Установите контракт событий и отправки

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

Официальная схема VK API публикует описания методов и объектов. Её полезно использовать для сверки полей, но версия схемы не заменяет проверки возможностей конкретного сообщества. В ТЗ зафиксируйте версию API, требуемые разрешения, подписки на события и проверенный способ доставки. Числовые лимиты не копируют из старой статьи без актуальной проверки.

Результат отправки сообщения и бизнес-операция проверяются раздельно. Если заявка создана, а подтверждение в диалог не доставлено, нельзя создавать новую заявку при каждом повторе. Нужна сверка по ключу операции и восстановление коммуникации с уже существующим результатом.

Интеграция с CRM и вложения

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

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

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

Тексты, права и наблюдение

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

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

Как принять готового бота

Проверьте новый и повторный диалог, текст вместо кнопки, вложение, длинную паузу, запрос оператора, недоступность CRM и повтор события. Для каждой ситуации нужны исходные данные и ожидаемое состояние обеих систем. Удобно использовать тестовое сообщество и отдельные записи CRM, чтобы не отправлять учебные обращения реальным клиентам.

Учебный сценарий: пользователь дважды отправляет один запрос, затем просит человека. В CRM остаётся одна заявка; оператор получает контекст; бот прекращает самостоятельные ответы до возврата управления. После восстановления сети пользователь видит номер уже принятого обращения, а не второй номер.

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