Отвечаем сразу. Связка 1С с MAX всегда состоит из трёх звеньев: событие в учётной системе, прослойка с очередью и ваш собственный бот в мессенджере. Прямого модуля, который ставится в конфигурацию и начинает слать сообщения, по состоянию на сентябрь 2026 года не существует — и это скорее хорошо, потому что именно прослойка делает смену канала дешёвой.
Контекст, в котором принимается решение, стоит проговорить с датой. WhatsApp заблокирован в РФ с февраля 2026 года и не рассматривается как канал для новых внедрений. Telegram работает с ограничениями, и обещать стабильность этого канала на годы вперёд нельзя. MAX — национальный мессенджер с бизнес-профилем на business.max.ru, верификацией через Госуслуги и собственным Bot API, и сегодня это разумный основной канал. Слово «сегодня» здесь не украшение: канал связи в 2026 году — расходуемый ресурс, и архитектуру надо строить исходя из этого.
Про переезд клиентской базы в MAX целиком у нас есть отдельный разбор с планом на 4–6 недель — перевод клиентских коммуникаций на MAX. Здесь речь только про сторону 1С: какое событие отдаёт конфигурация, что с ним происходит дальше и во что это превращает следующее обновление.
Почему уведомления не отправляют прямо из 1С
Технически можно: регламентное задание раз в минуту обходит заказы, формирует текст и делает HTTP-запрос к API мессенджера. Так делают, и на первых неделях это работает. Проблемы начинаются на третьем месяце, и все три относятся не к 1С, а к природе внешнего канала.
- 1Мессенджер бывает недоступен. Запрос не проходит, регламентное задание завершается с ошибкой, а следующий запуск берёт уже новую порцию заказов. Уведомление просто не уходит, и никто об этом не узнаёт — клиент не жалуется на сообщение, которого не было.
- 2Повторные попытки надо где-то хранить. Правильное поведение — положить сообщение в очередь и повторять с нарастающей паузой, пока канал не ответит. Очередь, счётчик попыток и журнал доставки — это отдельный механизм; писать его внутри учётной конфигурации можно, но вы получите самодельную инфраструктуру в базе, где ведётся учёт. Как устроены очереди и повторные попытки, мы разбирали в отдельном материале про очереди и повторные попытки.
- 3Регламентное задание блокирует базу. Сетевой запрос к внешнему сервису с ожиданием ответа внутри фонового задания — самый частый источник жалоб «1С тормозит по вечерам». Внешний контур эту проблему снимает целиком: 1С отдаёт событие и забывает о нём.
Если адрес, формат сообщений и токен бота лежат в модуле конфигурации, то смена канала означает переписывание этого модуля, повторное тестирование и новый регресс. Хуже того, при обновлении конфигурации этот код проверяется каждый раз наравне с остальным. Уровень вмешательства должен быть минимальным: 1С обязана знать только то, что произошло событие, и не знать, куда оно уйдёт. Полную лестницу уровней и цену каждого мы разбирали в статье про доработку 1С или внешнюю интеграцию.
Три звена связки и один контракт
Рабочая схема выглядит одинаково почти во всех проектах и не зависит от того, какой мессенджер выбран сегодня.
- 1Звено 1: 1С отдаёт событие
В расширении заводится подписка на изменение статуса заказа, проведение отгрузки, наступление срока оплаты. Событие уходит наружу одним вызовом и содержит минимум: идентификатор клиента, тип события и несколько полей. Ни текста сообщения, ни имени мессенджера здесь нет.
- 2Звено 2: прослойка с очередью и шаблонами
Снаружи событие превращается в сообщение по шаблону, попадает в очередь и отправляется. Здесь же живут повторные попытки, журнал доставки, ограничение частоты и правило тишины в ночные часы. Это единственное место, где надо править текст уведомления, — и править его может маркетолог, а не программист 1С.
- 3Звено 3: ваш бот в MAX
Бот создаётся под бизнес-профиль на business.max.ru, компания проходит верификацию через Госуслуги. Пошаговый порядок подключения мы описывали в материале про подключение бота в MAX, а границы Bot API — в разборе возможностей и ограничений Bot API MAX.
Контракт между первым и вторым звеном — это и есть та вещь, которую надо зафиксировать документом. Он описывает состав события: какие типы бывают, какие поля обязательны, что считается идентификатором клиента. Пока контракт не меняется, обновления конфигурации связку не задевают, а смена мессенджера сводится к новому адаптеру во втором звене.
Горизонтальная схема из пяти блоков со стрелками: «1С: изменился статус заказа» → «Событие: клиент, тип, поля» → «Очередь и шаблоны» → «Адаптер канала» → «MAX». Над стрелкой между «Очередью» и «Адаптером» подпись «повторные попытки с нарастающей паузой». От «Адаптера» вниз отходят два пунктирных ответвления к запасным блокам «другой мессенджер» и «SMS» с общей подписью «замена адаптера — 8 часов». Под блоком «Событие» подпись «контракт данных: 1С не знает имени канала». Под блоком «MAX» подпись «бот бизнес-профиля, верификация через Госуслуги». Вертикальная стрелка сверху «обновление конфигурации» упирается в первый блок и не доходит до остальных. Чертёжный стиль, подписи по-русски.
Событие есть, а адресата нет: подписка и согласие
Самое частое разочарование первого месяца — техническое ограничение, о котором не думают на этапе сметы. Бот не может написать первым тому, кто не начинал с ним диалог. Это не особенность MAX, а общее правило мессенджеров, и оно ломает наивную схему «выгрузим всех клиентов из 1С и разошлём». Событие в учётной системе есть, а отправить его некому.
Отсюда две работы, которые надо заложить в проект наравне с разработкой.
- Признак подписки в карточке контрагента. В 1С заводится реквизит: подписан на уведомления, дата подписки, идентификатор в канале. Без него менеджер не знает, дойдёт ли уведомление, а вы не можете посчитать охват. Реквизит делается расширением и обновление конфигурации не трогает.
- Набор подписчиков — отдельная работа на месяцы. Ссылка на бота ставится в письмо о заказе, в SMS о доставке, QR-код — в чек и в накладную. Реалистичный охват через два-три месяца — от трети до половины активной базы, и он зависит от того, насколько заметно вы предлагаете подписку, а не от техники.
- Согласие до первой отправки. Уведомления о статусе заказа — это обработка персональных данных, и текст согласия должен покрывать канал. Что именно писать в согласии, мы разбирали в материале о согласии на обработку данных; отдельный пункт — возможность отписаться одной командой боту.
Отчёт «отправлено 900 уведомлений» ничего не говорит, если заказов было 1 200. Правильная метрика — доля событий, которые дошли до клиента хоть в каком-то канале: MAX, если подписан, иначе SMS или письмо. Именно эта доля определяет, снимутся звонки «где мой заказ» или нет, и именно её надо ставить в приёмку проекта.
Пять сценариев, которые окупаются
Считаем на модельной компании: оптово-розничная торговля, 1 200 заказов в месяц, конфигурация 1С:УТ 11. Полная стоимость часа оператора поддержки — 700 ₽, менеджера — 900 ₽. Ниже — сценарии, у которых есть измеримый эффект, а не только приятное впечатление.
| Сценарий | Событие в 1С | Что снимает | Модельный эффект |
|---|---|---|---|
| Статус заказа изменился | Смена статуса заказа покупателя | 22 % заказов дают звонок «где мой заказ»: 264 звонка по 4 минуты, 17,6 часа — 12 320 ₽, уведомление снимает 70 % | 8 624 ₽/мес |
| Заказ готов к выдаче или отгружен | Проведение реализации или сборки | 120 уточняющих звонков по 3 минуты, 6 часов | 4 200 ₽/мес |
| Наступил срок оплаты | Контроль взаиморасчётов по договору | 40 напоминаний вручную по 6 минут, 4 часа менеджера | 3 600 ₽/мес |
| Напоминание о дате доставки или визите | Плановая дата в заказе | Неявки и несостоявшиеся доставки | Считается по цене неявки в вашей отрасли |
| Документы готовы к подписанию | Появление документа на подпись | 60 комплектов, 8 минут напоминаний на каждый, 8 часов менеджера | 7 200 ₽/мес |
Четыре измеримых сценария дают 23 624 ₽/мес. Пятый — напоминания о доставке и визитах — считается отдельно и в некоторых отраслях перевешивает все остальные вместе взятые, но подставлять сюда чужую цену неявки нечестно. Отсюда две цифры окупаемости: контур, сделанный в лоб внутри 1С за 140 000 ₽, возвращается за 5,9 месяца; контур с прослойкой, очередью и адаптером за 224 000 ₽ и 3 500 ₽/мес хостинга — за 11,1 месяца.
Столбчатая диаграмма из пяти столбцов, ось Y — рубли в месяц от 0 до 10 000. Столбцы: «Статус заказа — 8 624 ₽», «Готов к выдаче — 4 200 ₽», «Срок оплаты — 3 600 ₽», «Документы на подпись — 7 200 ₽», пятый столбец нарисован пунктиром без высоты и подписан «Напоминание о доставке — считается по цене неявки». Справа итоговая выноска «23 624 ₽/мес по четырём измеримым». Под осью подпись «1 200 заказов в месяц, ставки 700 ₽/час оператор и 900 ₽/час менеджер». Чертёжный стиль, подписи по-русски.
Абстракция канала: во что обходится смена мессенджера
Теперь главное — что произойдёт, когда канал придётся менять. За последние два года многие компании прошли этот путь дважды: сначала уход с WhatsApp, потом частичный отказ от Telegram. Считаем оба пути на 24 месяца, при одинаковой конфигурации 1С:УТ 11 и ставке инженера 3 500 ₽/час. Сопровождение релизов конфигурации в обоих путях одинаково — 6 релизов по 3 часа, 63 000 ₽, — поэтому из сравнения оно исключено.
Вывод честный и не такой однозначный, как обычно пишут. Если вы уверены, что канал за два года не сменится, дешевле сделать в лоб: экономия 84 000 ₽ и вдвое быстрая окупаемость. Если сменится дважды — пути равны. Если трижды — выигрывает архитектура с адаптером. Наш опыт и статус каналов на сентябрь 2026 года говорят, что закладывать ноль смен нельзя; аргументы и сценарии на этот счёт мы собрали в материале про блокировки мессенджеров и архитектуру.
И отдельно, вне денег: очередь с повторными попытками нужна в обоих путях. Без неё уведомления теряются молча, а потерянное уведомление о готовности заказа стоит того самого звонка, ради снятия которого всё затевалось. Это не статья экономии, это условие работоспособности.
Двухосевой график. Ось X — число смен канала за 24 месяца, значения 0, 1, 2, 3. Ось Y — рубли от 0 до 500 000. Сплошная линия «Путь А: отправка из 1С напрямую» из точки 140 000 ₽ растёт с шагом 112 000 ₽: 140 000, 252 000, 364 000, 476 000. Штриховая линия «Путь Б: прослойка и адаптер» из точки 308 000 ₽ растёт с шагом 28 000 ₽: 308 000, 336 000, 364 000, 392 000. Точка пересечения при двух сменах выделена кружком и подписана «364 000 ₽ — пути равны». Справа вертикальная выноска между линиями при трёх сменах с подписью «84 000 ₽». Чертёжный стиль, подписи по-русски.
Когда уведомления из 1С не нужны
Четыре ситуации, в которых проект не окупится или окажется преждевременным.
- Меньше 150 заказов в месяц. Модельный эффект пропорционален потоку: при 150 заказах четыре сценария дают около 2 950 ₽/мес, и даже самый дешёвый контур будет возвращаться четвёртый год. На таком объёме дешевле шаблон сообщения и полторы минуты менеджера.
- Статусы в 1С не соответствуют реальности. Если заказ переводят в «отгружен» на следующий день после фактической отгрузки, уведомления начнут врать быстрее и в большем количестве. Сначала регламент смены статусов и ответственный за него, потом рассылка.
- Клиенты — юридические лица с одним контактным лицом на договор. Уведомления в личный мессенджер снабженца работают хуже, чем письмо на общий ящик закупок. Здесь эффективнее личный кабинет или ЭДО, а не бот.
- Общение уже ведётся в CRM. Тогда уведомления должны уходить оттуда, а из 1С в CRM попадает событие. Тот же принцип, что и с телефонией, — мы разбирали его в материале про 1С и телефонию: каналы живут рядом с общением, а не рядом с учётом.
И последняя проверка перед стартом. Спросите, кто будет менять текст уведомления через полгода. Если ответ — «программист 1С по заявке», текст лежит не там: шаблоны обязаны редактироваться в прослойке без релиза конфигурации. Это мелочь на стадии проекта и главный источник раздражения на стадии эксплуатации.
Конфигурация должна знать, что произошло, и не должна знать, в каком мессенджере об этом расскажут.
