Работа с клиентами в MAX: жизнь диалога

Короткий ответ: после первого ответа начинается обычная переписка, и инструмент здесь помогает двумя вещами — она видна всей команде и она хранится у вас. Всё, что касается «где сейчас клиент», «когда к нему вернуться» и «кто с ним работает», остаётся вашим процессом: стадий сделки, тегов, уведомлений о просрочке и назначения ответственного за диалог в LTVchat нет. Дальше — про то, что в этой переписке зависит от платформы, а что от вас.

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

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

Первое сообщение: у вас есть адресат

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

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

Вложения: где ограничения реально мешают

Эта часть выглядит технической, но именно она чаще всего ломает скрипт менеджера в середине разговора.

• Тяжёлое вложение проходит. Предел объёма щедрый: четыре гигабайта и для пользовательского файла, и для файлового вложения бот-интерфейса. Смету, каталог или запись встречи отправлять можно.
• Картинка ограничена дважды. Кроме предела в пятьдесят мегабайт есть предел по стороне — 7680 пикселей, и оба действуют одновременно. Скан большого чертежа в исходном разрешении может не пройти по второму критерию, а не по первому.
• Отправка не одномоментна. Вложение сначала загружается и получает токен, и только потом уходит адресату; тяжёлый файл сервер обрабатывает дольше, а спешка возвращает ошибку неготовности. Документация советует выждать паузу, повторять с растущим интервалом и заранее загружать то, что отправляется часто, переиспользуя токен.
• Один файл на сообщение, и без картинки рядом. Сообщение принимает до двенадцати вложений, видео и изображения между собой сочетаются, но файл сочетается только с вложением с кнопками — не с фото и не с видео, и больше одного файла в сообщение не положить.

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

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

Середина диалога: где живёт «где сейчас клиент»

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

Что работает у отделов до десяти человек:

1. Три поля вместо воронки. Клиент, о чём договорились, когда вернуться. Заполняется в момент разговора, а не вечером по памяти.
2. Одно время в день на просмотр. Полчаса в одно и то же время. «Буду поглядывать» не проверяется и потому не случается.
3. Объединение диалогов до важного разговора. Клиент мог написать и с бот-канала, и с личного. Диалоги объединяются явным действием в одну карточку и разъединяются обратно при ошибке. Автоматического распознавания «это тот же человек» нет.
4. Закрепление клиента за человеком — в общем документе. Не в сервисе: он обращения не распределяет и ответственного не назначает.

Когда клиент уходит к другому менеджеру

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

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

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

Проверка качества: выборочно, а не тотально

В журнале действий по каждой записи видно событие и объект, над которым оно произошло, роль совершившего, адрес, идентификатор запроса и время; сами записи привязаны к рабочему пространству. Он показывает, кто трогал данные клиента. На вопрос «хорошо ли поговорили» отвечает только чтение нескольких диалогов в неделю — и лучше именно нескольких: попытка читать всё портит собственные данные, потому что содержательная часть переписки переезжает туда, где её не видно. Где проходит эта граница, разобрано в тексте про контроль переписок.

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

Чек-лист ведения клиента

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

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

Чего в работе с диалогом нет

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

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

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

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

Как устроены роли и доступ, написано на странице безопасности; там же прямо сказано об отсутствии у сервиса сертификаций, аттестаций и внешних аудитов. Правовую сторону работы с клиентскими данными разбирает юрист по вашим бумагам; где проходит граница, показано в тексте про 152-ФЗ.

Дальше

Как весь процесс продаж выстраивается вокруг входящего обращения, с разбором четырёх переходов, на которых теряются сделки, — на странице про MAX для продаж. Расчёт по формуле 300 ₽/канал в месяц + 50 ₽/сотрудник в месяц — на странице тарифов; владельцы подключённых каналов не оплачиваются как сотрудники.