Бот поддержки в MAX: как принимать обращения и передавать разговор оператору

MAATRIX · 17 октября 2026 · 8 мин чтения

Клиент пишет: «Заказ пришёл не полностью». Бот предлагает выбрать тему, затем снова выбрать тему, затем благодарит за обращение. Через несколько минут клиент уже не столько расстроен заказом, сколько заинтересован в встрече с человеком, который придумал это меню.

Хорошая поддержка начинается с обратного решения: автоматизация должна уменьшать путь до помощи. Бот собирает необходимый контекст, сообщает номер обращения и передаёт разговор сотруднику. Если ответ действительно можно дать автоматически, он делает это. Если нельзя — не изображает занятого оператора.

Спроектируем такую поддержку для MAX на примере небольшого сервиса. Это учебная схема: названия статусов, реплики и правила можно адаптировать к магазину, мастерской, онлайн-школе или технической поддержке.

Уберите лишние вопросы из первого экрана

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

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

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

Рабочие часы указывайте с часовым поясом. Формулировка «ответим завтра» в пятницу вечером может оказаться неожиданно смелой. Лучше назвать ближайшее рабочее окно и предложить оставить описание сейчас.

У обращения должен появиться дом

Чат — канал разговора, а обращение — отдельная запись в системе. Храните внутренний номер, идентификатор клиента в MAX, категорию, статус, ответственного, время создания и время последнего содержательного ответа. Сообщения связывайте с обращением через отдельный журнал.

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

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

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

Простая машина состояний помогает больше сложного меню

Для начала достаточно нескольких статусов. Главное — определить, кто и при каких условиях их меняет.

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

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

Передача человеку — это смена режима разговора

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

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

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

Внутреннюю заметку отделите от ответа клиенту визуально и технически. Поле «для коллег» не должно случайно отправляться в MAX тем же действием, что публичная реплика. Такой небольшой элемент интерфейса иногда предотвращает гораздо больше неприятностей, чем сложная нейросеть.

Как отправлять ответы и не терять их по дороге

Исходящее сообщение сначала сохраняйте в собственной очереди отправки со статусом. Обработчик вызывает метод отправки сообщений MAX, проверяет результат и сохраняет полученный идентификатор. Оператор должен видеть различие между подготовленным текстом, успешной отправкой и ошибкой.

Не обозначайте ответ как прочитанный, если у вас нет соответствующего подтверждения платформы. Успешный вызов API подтверждает определённый этап доставки, но не внимание человека к экрану.

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

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

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

Кнопки не должны делать больше, чем обещают

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

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

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

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

Что делать ночью и во время перегрузки

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

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

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

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

Приёмка на десяти учебных обращениях

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

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

Отдельно попросите человека, не участвовавшего в разработке, найти оператора и уточнить статус. Если он заблудился, упростите маршрут. Пользователь не обязан понимать вашу машину состояний, хотя сервер обязан соблюдать её очень строго.

Где разместить такую поддержку

Для пилота с небольшим числом операторов и PostgreSQL можно рассмотреть MAATRIX Uab Start: 2 vCPU, 4 ГБ памяти и 80 ГБ диска. При хранении множества вложений диск считают отдельно; для более заметной нагрузки стоит испытать Heka Standard с 4 vCPU и 8 ГБ.

На VPS размещаются обработчик MAX, база, очередь и кабинет сотрудников. Это самостоятельная разработка и установка, а не готовая встроенная функция любого тарифа. Резервные копии нужно хранить независимо от рабочего узла и проверять восстановлением.

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