Короткий ответ. Бот MAX для поддержки клиентов должен принимать вопрос, сохранять контекст, находить ответ в утверждённой базе, а при неопределённости передавать обращение оператору. MAX предоставляет транспортные методы для сообщений и событий: отправка описана в POST /messages, события — в POST /subscriptions. Бот не должен выдавать наличие API за доказательство качества ответа: качество определяется вашей базой знаний, тестами и правилами эскалации.
Границы поддержки через MAX
До разработки разделите вопросы клиентов на три группы. Первая — типовые справочные вопросы, для которых есть короткий утверждённый ответ. Вторая — запросы, где бот может собрать сведения и передать их сотруднику. Третья — ситуации с риском ошибки, спором, персональными данными или необходимостью решения по конкретному договору. Третью группу сразу направляйте человеку.
Такое разделение предотвращает подмену поддержки генерацией правдоподобного текста. Бот может помочь найти статью, уточнить номер обращения и сообщить статус, но не должен самостоятельно менять условия договора, обещать компенсацию или объявлять результат проверки, которого нет в CRM. Границы сценария фиксируются в инструкциях и тестовых примерах.
Какие данные даёт MAX для истории
Объект Message содержит отправителя, получателя, временную отметку, тело сообщения и контекст связи с другими сообщениями. Объект User описывает идентификатор пользователя, отображаемое имя и признак бота. Эти поля полезны для связи сообщений с обращением, но не заменяют внутреннюю идентификацию клиента.
В истории храните внешний идентификатор пользователя, идентификатор сообщения, время, тип события и итог действия оператора. Сохраняйте только данные, необходимые для поддержки. Если пользователь прислал вложение, отдельно фиксируйте его тип и результат проверки, а не передавайте его содержимое всем сотрудникам по умолчанию.
Контур приёма обращения
Webhook MAX должен быть доступен по HTTPS на порту 443 и иметь доверенный сертификат. При создании подписки можно указать секрет; тогда сервер проверяет заголовок X-Max-Bot-Api-Secret. Сначала проверяется запрос, затем событие получает внутренний идентификатор, после чего обработчик быстро подтверждает приём и передаёт работу очереди.
Не выполняйте поиск по большой базе знаний и вызов CRM внутри короткого сетевого обработчика. Если внешняя система отвечает медленно, MAX может считать доставку неуспешной и повторить событие. Поэтому Webhook должен быть маленьким и идемпотентным: одинаковое событие несколько раз не создаёт несколько обращений.
Как устроить базу знаний
База знаний для поддержки — это не папка со всеми документами, а набор коротких материалов с владельцем, датой проверки и областью применения. У каждой статьи должны быть заголовок, условие применимости, инструкция, исключения и ссылка на исходный внутренний документ. Устаревшие версии помечаются и исключаются из поиска.
Разделяйте публичные ответы и внутренние заметки. В публичном ответе нет токенов, служебных URL и комментариев о другом клиенте. Если несколько документов противоречат друг другу, бот не выбирает один наугад, а задаёт уточняющий вопрос или эскалирует оператору.
| Тип материала | Что можно делать боту | Когда передавать человеку |
|---|---|---|
| Инструкция | Дать короткий ответ со ссылкой | Документ устарел или противоречит другому |
| Статус обращения | Показать подтверждённый статус | Статус отсутствует или спорный |
| Платёжный вопрос | Собрать номер обращения | Нужно принять решение о возврате |
| Жалоба | Зафиксировать тему и контакт | Всегда при риске конфликта |
Сценарий ответа
Начинайте с классификации: вопрос, запрос статуса, техническая проблема, жалоба или неизвестный случай. Затем извлекайте только необходимые признаки. Для вопроса о доставке это может быть номер заказа и регион; для технической проблемы — версия, действие и текст ошибки. Не просите все данные «на всякий случай».
Ответ строится из найденного подтверждённого фрагмента и следующего действия. Если уверенного совпадения нет, фраза должна быть честной: «Не нашёл подтверждённый ответ, передаю вопрос оператору». После этого пользователь должен понимать, что произойдёт дальше: номер обращения, рабочее окно или просьба дождаться сообщения.
Передача оператору
Эскалация должна создавать задачу, а не просто печатать слово «оператор». В задаче нужны идентификатор пользователя MAX, краткая тема, исходный вопрос, найденные материалы и причина передачи. Оператору полезен контекст, но ему не нужен весь технический журнал с секретами и внутренними трассировками.
Сделайте состояния обращения явными: new, collecting, waiting_operator, answered, closed. Только оператор или специализированный сервис меняет состояние, которое означает принятое решение. Бот может сообщить клиенту о переходе в ожидание, но не должен самостоятельно закрывать спорное обращение.
Отправка сообщений и вложений
Метод POST /messages принимает текст и поддерживаемые типы вложений, а также позволяет выбрать адресата. В интеграции проверяйте длину текста, ссылки, MIME-тип и размер файла по правилам вашего сервиса до обращения к MAX. Не предполагайте, что возможность передать вложение означает безопасность файла или корректность его содержания.
Токен передаётся в заголовке Authorization и не должен попадать в клиентский код, логи или тикеты. Для ответа клиенту используйте отдельный шаблон представления. Внутренний комментарий «проверить вручную» не должен случайно уйти пользователю вместе с публичным ответом.
Проверка качества ответов
Соберите контрольный набор вопросов: простые, неоднозначные, устаревшие, конфликтующие и содержащие попытку получить внутренние сведения. Для каждого задайте эталонное действие, а не только эталонную формулировку. Иногда правильный результат — не текстовый ответ, а эскалация.
Отдельно отслеживайте долю обращений без ответа, повторные вопросы, ручные исправления, неверную классификацию и время до передачи оператору. Эти показатели помогают найти слабое место, но не превращаются автоматически в гарантию качества. Выборку нужно регулярно пересматривать после изменения базы знаний и сценариев.
Ошибки и повторы
Webhook MAX может повторно доставить событие, если не получил успешный ответ. Внутренний обработчик должен проверять уникальный ключ события. Исходящая ошибка MAX, недоступность базы знаний и ошибка CRM имеют разные последствия. Временную ошибку можно поставить в ограниченную повторную очередь, а ошибку данных нужно отправить на исправление.
Если бот не смог обновить историю, не сообщайте пользователю, что обращение закрыто. Сначала сохраните неопределённый результат и покажите безопасное сообщение о передаче оператору. Все повторы ограничивайте, чтобы недоступность одного компонента не создала поток одинаковых сообщений.
Безопасность и приватность
Считайте любой пользовательский текст недоверенным. Он может содержать инструкции, которые пытаются изменить правила бота, получить скрытые документы или заставить систему выполнить действие. Источник знаний должен быть отделён от пользовательского ввода, а опасные действия подтверждаться сотрудником.
Доступ к истории обращений ограничьте ролями. В логах маскируйте телефоны, адреса и документы. Установите срок хранения и процедуру удаления. Не отправляйте сотруднику полную персональную историю, если для решения вопроса достаточно номера обращения и одного сообщения.
Учебный пример поддержки
В условном сценарии клиент спрашивает, как изменить адрес доставки. Бот классифицирует вопрос как справочный, находит актуальную инструкцию и отправляет короткую последовательность действий. Клиент добавляет, что заказ уже передан курьеру. Правило сценария меняется: это уже обращение по конкретной операции, поэтому бот запрашивает номер заказа, создаёт задачу оператору и сообщает о передаче. Бот не обещает, что адрес будет изменён.
Этот пример учебный. Он показывает границу между справочным ответом и решением по конкретному заказу, но не описывает реальный процесс, SLA или возможности конкретной CRM.
Чек-лист запуска
- Определены темы, которые бот отвечает сам.
- Для неопределённых и рискованных случаев есть эскалация.
- Webhook работает по HTTPS и проверяет секрет.
- Повторное событие не создаёт новый тикет.
- История содержит внешний идентификатор и время.
- База знаний имеет владельца и дату проверки.
- Публичные ответы отделены от внутренних заметок.
- Токен не попадает в код и логи.
- Тесты включают устаревший документ, конфликт источников и сбой CRM.
- Есть ручной способ остановить исходящие сообщения.
Обучение операторов и обновление знаний
Оператору нужно видеть не только вопрос клиента, но и путь, которым бот пришёл к эскалации. Показывайте найденную статью, причину низкой уверенности, обязательные поля и уже отправленные сообщения. Не показывайте скрытые системные инструкции и секреты. Такая карточка помогает быстрее исправить ответ и понять, нужно ли обновить базу знаний.
После закрытия обращения можно добавить материал в очередь редакторской проверки. Сотрудник формулирует общий вопрос без персональных данных, владелец процесса подтверждает ответ, затем новая версия получает дату и область действия. Не добавляйте в базу единичную реплику клиента как готовое правило: сначала отделите повторяемую задачу от частного обстоятельства.
Проводите регрессионную проверку после существенного изменения. Один и тот же контрольный вопрос должен вести к тому же типу решения, если его условия не изменились. Если документ обновился, проверьте также исключения и эскалацию. История версий позволяет вернуть материал, если новая редакция увеличила количество ручных исправлений.
Работа с недоступностью компонентов
Сценарий поддержки должен иметь безопасное состояние при недоступности базы знаний, CRM или MAX. При сбое базы бот может принять вопрос и передать его оператору, но не должен строить ответ по устаревшему кэшу без соответствующей пометки. При недоступности CRM можно сохранить минимальное обращение в отдельной очереди, если политика хранения это разрешает.
Для клиента важна честная граница: сообщение о приёме не равно решённому вопросу. Формулировка должна различать «сообщение получено», «оператор назначен» и «ответ подтверждён». Внутри системы эти состояния также должны быть разными, иначе мониторинг покажет ложный успех.
Постепенное расширение сценариев
Расширяйте бота по темам, а не по принципу «подключим все документы». Для каждой новой темы определите входные признаки, разрешённый ответ, исключения и действие при нехватке данных. После запуска соберите выборку и проверьте не только тексты, но и маршруты: сколько вопросов попало оператору, сколько вернулось повторно и где возникли ошибки идентификации.
Если тема содержит юридические, финансовые или договорные последствия, оставляйте решение человеку. Бот может объяснить порядок обращения и собрать сведения, но окончательная оценка должна опираться на внутренние правила и полномочия сотрудника, а не на уверенный тон автоматического ответа.
Критерии остановки автоматического ответа
Заранее составьте список условий, при которых бот прекращает самостоятельный диалог. Это может быть явная просьба о сотруднике, повторное непонимание, конфликт двух документов, отсутствие обязательного идентификатора или обнаружение чувствительной темы. Условие должно приводить к конкретному действию: создать обращение, поставить приоритет и показать пользователю нейтральное подтверждение.
Не скрывайте факт передачи. Клиенту достаточно сообщить, что вопрос зарегистрирован и будет продолжен оператором; не называйте непроверенное время ответа и не обещайте решение. Внутри карточки сохраняйте причину эскалации, чтобы сотрудник мог оценить не только последний текст, но и весь путь обращения.
Практический вывод
Бот MAX для поддержки полезен, когда его задача ограничена проверенными ответами и аккуратной передачей сложных случаев оператору. Официальные методы MAX дают транспорт для сообщений и событий, а качество обеспечивают структура базы знаний, явные состояния, дедупликация, тестовый набор и контроль доступа. Начинайте с узкой очереди вопросов, где правильный ответ можно проверить, и расширяйте охват только после анализа ошибок.