MAX для бизнеса: бот, обращения клиентов и анонсы

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

Здесь — разбор того, как мессенджер MAX подключён к нашей CRM Ось Бизнеса: обращения падают в общую очередь к письмам, чату на сайте и Telegram, ответ уходит обратно в мессенджер, файлы остаются у нас, а в канал улетают анонсы статей. И отдельно — грабли, которых нет в документации: мы их собрали за один вечер.

Что подключается и куда

Три разные вещи, которые часто путают:

• Бот — то, во что пишет клиент. У него токен, вебхук и адрес, по которому его находят.
• Канал — то, что читают. Туда уходят анонсы, бот в нём администратор с правом писать посты.
• CRM — то, где живёт переписка: очередь обращений, история, ответственный, срок ответа.

Мессенджер здесь — только транспорт. Всё, что делает канал каналом — очередь, статусы, сроки, поиск по истории, — живёт в CRM и одинаково для всех источников; как устроена сама очередь, разбирал в статье про обработку обращений в одном окне. Это и есть смысл интеграции: не «мы ещё и в MAX», а «в MAX — то же самое качество ответа, что и везде».

Приём: клиент пишет боту

Сообщения приходят к нам вебхуком — адресом, который мы отдаём мессенджеру. Четыре решения, принятые в этом месте:

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

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

Проверяем повтор. Доставка гарантируется «хотя бы один раз» — то есть одно и то же сообщение вполне может прийти дважды. Без проверки оператор увидит дубль и ответит на него отдельно.

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

⚠️ Отдельно: если файл не скачался, сообщение всё равно сохраняется. Текст важнее вложения, и терять вопрос клиента из-за неудачной картинки — плохой размен.

Основание переписки: галочки нет

Место, которое обычно вспоминают последним, а оно юридическое.

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

Поэтому в диалоге из мессенджера мы явно фиксируем основание «обращение по своей инициативе», а не «согласие получено». Разница не косметическая: назвать это согласием — подмена, которая в споре сработает против нас. И то и другое уходит в неизменяемый журнал: диалог удалить можно, а основание обработки должно пережить удаление.

⚠️ Мелочь, которая портит журнал: ник вида «@ivanov» — это не почта. Если положить его в поле почты, по такому журналу потом ни написать человеку, ни найти его. Ник идёт в имя, почта остаётся пустой, пока клиент её не назовёт.

Ответ: из той же очереди, что и всё остальное

Оператор отвечает в портале, в общей ленте обращений, и не думает, откуда пришёл вопрос. Ответ уходит туда же, откуда пришёл, — это делает сам портал, отправляя сообщение боту.

Два правила из практики:

• Ошибка отправки не роняет ответ. Сообщение уже сохранено в портале; если мессенджер не принял его, оператор увидит ошибку, но текст никуда не денется, и его можно отправить повторно.
• Из журналов вычищается токен. Текст ошибки от сервиса иногда содержит адрес запроса вместе с ключом. Один раз ключ так и уехал в наш журнал ошибок — с тех пор ошибка перед записью чистится.

Анонсы в канал

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

• Карточку ссылки MAX не разворачивает. Поэтому обложка уходит отдельной картинкой, а не «сама подтянется по ссылке», как в Telegram.
• MAX разбирает markdown. Заголовок поста рисуется настоящим заголовком, крупнее текста, — в Telegram такого нет, там потолок жирный шрифт.
• Отметка об отправке у каждого канала своя. Отправили в Telegram, а в MAX ещё нет — видно в списке статей, и повторно в Telegram ничего не улетит.

⚠️ И принцип, который сильнее оформления: если картинка не отправилась, пост уходит без неё. Оформление важно, но ссылка важнее.

Грабли, которых нет в документации

Их собрали за один вечер подключения, и они стоят того, чтобы записать.

База API — не та, что в документации. Адрес, который называет документация, не отвечает вовсе. Соседний отвечает, но не принимает токен. Рабочий — третий. Диагностируется это плохо: похоже на «нам не выдали доступ», а не на «мы стучимся не туда». Проверять надо самым простым методом — «кто я», — и только убедившись, что он отвечает, идти дальше.

Авторизация без привычного слова. Токен передаётся в заголовке как есть, без «Bearer» впереди. Привычка добавить его стоила отдельного часа: сервис отвечает так же, как на неверный ключ.

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

⚠️ Общее правило для нового API: сначала «кто я», потом всё остальное. Три вечера уходят не на логику, а на выяснение, по какому адресу и с каким заголовком с ним вообще разговаривать.

Чем MAX отличается от Telegram в работе

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

С MAX этого участка нет: сервер разговаривает с сервисом напрямую, и в этом смысле канал устроен проще. Про промежуточный узел и его цену — в статье про заявки с сайта в Telegram и MAX.

Что выяснить до подключения

• Куда попадут сообщения — в общую очередь или в телефон сотрудника.
• Кто отвечает и за сколько. Мессенджер создаёт ожидание быстрого ответа; норматив должен быть, иначе он появится сам собой и будет чужим.
• Где хранятся файлы — у вас или ссылкой на мессенджер, которая однажды перестанет открываться.
• На каком основании вы ведёте переписку и записано ли это где-то, кроме памяти.
• Что происходит при повторной доставке сообщения и при незнакомом типе события.
• Кто и чем публикует в канал — руками из телефона или системой, с отметкой, что уже ушло.

Если вы заводите MAX для бизнеса

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

Что обычно входит в такую работу:

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

Хотите такую же связку у себя — расскажите о задаче.