Простая настройка СМС-оповещений прямо в Make.com | Автор: Марина Погодина
Make.com интеграция СМС звучит суховато, но в жизни за этим обычно стоят очень конкретные истории: менеджер забыл позвонить клиенту, курьер не доехал, а служба поддержки узнает об этом через три дня из злого отзыва. В России, где уведомления по СМС до сих пор отлично работают даже там, где мессенджеры тормозят, make.com смс рассылки становятся вполне приземленным способом навести порядок в коммуникациях. В этом разборе я пройду все пять шагов настройки make.com смс — от выбора SMS-провайдера до сценариев с ИИ, которые экономят рабочие часы и не лезут за границы 152-ФЗ. Текст в первую очередь для российских специалистов по автоматизации, продуктов, маркетологов и внутренних айтишников, которым надо сделать, чтобы «само работало», а не «допилите потом».
Чуть контекста. Ко мне недавно пришел Илья, руководитель сервисной службы сети пунктов выдачи заказов. У него было все: CRM, колл-центр, отчеты в BI и постоянные жалобы «мне никто не написал, что заказ приехал». СМС отправлялись через старый шлюз, ручными выгрузками, раз в день, если оператор не забыл нажать кнопку. Мы с ним сели, открыли make.com, и я сказала: «Смотри, мы сейчас соберем тебе автоматическую цепочку уведомлений в пять шагов, и не придется никому вспоминать про рассылку вручную». Дальше я покажу, как мы это сделали, какие грабли обошли и как не залететь на Роскомнадзор по пути.
Когда пытаешься объяснить, зачем вообще связывать make.com и СМС, проще всего вспомнить рабочий день: ты ставишь себе напоминание «дописать ТЗ» и надеждно о нем забываешь, если оно только в таск-трекере. А вот если прилетает СМС «через 2 часа дедлайн по клиенту», шанс что-то сделать резко растет. В бизнес-процессах то же самое: уведомление в телефоне по старинному СМС-каналу часто надежнее модного бота в мессенджере, особенно в регионах. И в России это все еще канал, который люди открывают почти автоматически.
У Ильи была системная боль: заказы приезжали в пункт выдачи, клиенту уходило письмо (которое он не читал), а СМС могла прийти через сутки, потому что ее ставили в пакетную рассылку. За это время часть клиентов успевала написать гнев в поддержку или вообще уйти к конкурентам. Внутри компании все были уверены, что «ну мы же отправляем уведомления», просто никто не смотрел на реальное время отправки. Такие штуки очень любят всплывать на внутреннем аудите, и чем позже их находишь, тем дороже стоит исправление.
Я предложила очень прагматичный подход: сделать make.com смс рассылки как прослойку между CRM и выбранным SMS-сервисом, чтобы триггеры были событийными, а не «когда кто-то вспомнит». Это критично, потому что событийная модель всегда ближе к реальному клиентскому опыту. Мы договорились, что начнем с минимального набора: СМС при поступлении заказа в ПВЗ, напоминание через два дня и уведомление о скором возврате товара на склад. Три простых события, которые уже закрывают значимую часть негатива и экономят звонки колл-центра.
Уточню юридическую рамку. В российской реальности любая SMS-рассылка мгновенно упирается в 152-ФЗ, соглаcия и давление регулятора. Автоматизировать можно много чего, но без основания и реестра согласий это выглядит не как забота о клиенте, а как риск получить штраф. Я всегда исхожу из консервативной модели: все персональные данные храним у российского оператора связи или локального провайдера SMS, make.com используем только как оркестратора процессов без лишнего контента ПД. Это означает, что в самом сценарии можно хранить только технический идентификатор и шаблон, а «телефон+текст» подставлять уже на стороне SMS-сервиса или через безопасный API.
История Ильи на этом этапе пока выглядит скучно: он принес схему процессов, я открыла блокнот, мы разложили события по шагам. Но именно здесь закладывается то, будет ли потом автоматизация работать годами или развалится через первую же маркетинговую кампанию.
Как выбрать SMS-сервис в России под интеграцию с Make.com и не нарушить 152-ФЗ
Перед тем как нажимать «Create a new scenario» в make.com, приходится сделать менее романтичную вещь — выбрать, через кого вообще отправлять СМС в России. От этого зависят и деньги, и стабильность, и то, как смотреть в глаза службе безопасности. На рынке хватает провайдеров: от крупных операторских платформ до нишевых сервисов для маркетинга. Я всегда начинаю не с цены, а с трех вопросов: где физически лежат данные, есть ли публичная информация по 152-ФЗ/локализации и насколько вменяем их API. Потому что красивый сайт без нормальной документации потом оборачивается ночными танцами с ретраями и тайм-аутами.
В истории с Ильей мы смотрели на провайдеров, у которых есть дата-центры в РФ, заключенный договор с описанием обработки ПД и понятный API с авторизацией по ключу. Это критично, потому что API — это ваш рабочий инструмент, а не маркетинговая картинка. Мы сразу отмели варианты, где нужно лезть в личный кабинет, чтобы «вручную выгрузить отчеты», потому что смысл интеграции теряется. Еще один фильтр — поддержка именованных отправителей (альфа-имен), чтобы SМS приходили не с серого номера, а от бренда, и адекватная политика по шаблонам (без жесткой модерации каждого запятой).
Чтобы это не звучало абстрактно, мне удобно разложить критерии выбора по чек-листу. Здесь работает простое перечисление, которое я обычно кидаю клиенту после первого созвона, когда мы обсуждаем make.com интеграция смс и варианты провайдеров.
- Правило: хостинг и обработка ПД — на территории РФ, с понятными юридическими документами.
- Критерий: наличие полноценного API с документацией, примерами запросов и ограничениями по скорости.
- Фактор: поддержка альфа-имен и гибкой настройки подписи отправителя без недельных согласований.
- Требование: доступ к логам и статусам доставки через API, а не только в личном кабинете.
- Деталь: разумные цены на транзакционные СМС, отдельные от агрессивных рекламных рассылок.
На практике отличить «нормального» провайдера от спорного можно по мелочам: есть ли у них раздел для разработчиков, как быстро отвечают на вопросы про лимиты API, и насколько честно прописаны статусы доставки (хотя сама я видела, как в документации одно, а в жизни другое). Для интеграции с make.com нам нужно прежде всего стабильное и предсказуемое поведение: если сервис в час пик начинает возвращать ошибки 500 без объяснений, это прямая дорога к дыркам в клиентском пути. В идеале у провайдера должен быть sandbox или тестовые номера, чтобы вы могли отладить сценарий без рассылки на живых клиентов.
Еще одна российская специфика — разделение транзакционных и маркетинговых сообщений. Для уведомлений о заказах, кодах подтверждения и других служебных СМС лояльность операторов выше, но если вы через тот же канал вдруг решите «а давайте шлем рекламку ночью», можно быстро уехать в блок. Поэтому я всегда рекомендую закладывать в архитектуру два типа шаблонов на стороне SMS-сервиса и четко маркировать трафик. Это экономит нервы, когда маркетинг захочет добавить «акцию до полуночи» в транзакционный поток (нет, подожди, так делать как раз не стоит).
Илья, к слову, сначала хотел «самый дешевый вариант, мы же немного шлем». Мы открыли калькулятор, умножили количество заказов на количество уведомлений и прибавили штрафы за нарушения 152-ФЗ, если вдруг что-то пойдет не так. После этого разговор о «дешевле на 5 копеек» закончился, и мы выбрали провайдера с нормальным договором, российскими серверами и понятной техподдержкой. Это означает, что на следующих шагах мы смогли спокойно заниматься автоматизацией, а не спорить с юристами, кому что можно передавать.
Как подготовить учетную запись SMS-сервиса к связке с Make.com
Когда провайдер выбран, начинается скучная, но необходимая рутина: регистрация, проверка отправителя, настройка шаблонов. Без этого make.com просто не к чему будет подключаться. Я обычно сажусь с чашкой (уже остывшего) кофе, открываю два окна браузера — личный кабинет SMS-сервиса и документацию по их API — и иду по шагам. Суть в том, чтобы один раз аккуратно настроить базу, а потом не трогать ее годами, только добавляя новые сценарии.
В личном кабинете почти всегда потребуется зарегистрировать альфа-имя отправителя, прикрепить юридические документы, описать тематику рассылок и пройти модерацию. Это занимает от пары часов до пары дней, и на этот период полезно сразу заложить задержку в проекте, а не пытаться «успеть к завтрашней акции». Дальше нам нужен API-ключ или токен доступа, который будет использовать make.com. Я всегда прошу клиентов оформить отдельный ключ под интеграцию, чтобы можно было отслеживать трафик именно из автоматизации и при необходимости его быстро отключить, не ломая ручные процессы.
Еще одна деталь — настройка шаблонов сообщений. Многие российские SMS-сервисы вводят понятие «шаблон», который нужно создать и согласовать заранее, а в запросе к API вы просто передаете параметры для подстановки. Это удобно с точки зрения безопасности: мы не гоняем по внешним системам «сырые» тексты о заказах, а только коды и ссылки. Но есть и минус: любая правка текста может потребовать новой модерации (звучит странно, но работает в плюс для комплаенса). Поэтому я рекомендую сразу продумать универсальные формулировки без лишних эмоций и маркетинговых крючков.
Чтобы эта подготовка не превратилась в хаос, полезно структурировать ключевые настройки. Я для себя держу краткий набор, что именно надо зафиксировать до начала работ в make.com, и отправляю его клиенту в переписке, чтобы потом никто не искал «где у нас хранится токен».
Я заметила, что чем аккуратнее вы оформите отправителя, токены и шаблоны на стороне SMS-сервиса, тем меньше придется чинить «внезапные сбои» уже на бою, когда сценарий в make.com крутит сотни сообщений в день.
Илья сперва относился к этому как к бюрократии: «давайте сначала соберем сценарий, а потом разберемся с шаблонами». Мы почти так и сделали, но уже на этапе теста уткнулись в то, что один и тот же текст должен по-разному трактоваться для разных регионов и каналов. Пришлось вернуться назад и внести дополнительные параметры в шаблоны: время работы пункта выдачи, локальные контактные номера. Получается, что лучше один раз спокойно оформить структуру сообщений, чем потом править инфраструктуру под каждую мелочь.
Как спланировать сценарий SMS-уведомлений в Make.com до первой строки настроек
Технически можно открыть make.com, накидать модули «HTTP request» и «Sleep» и считать, что автоматизация сделана. Но если не спланировать логику заранее, сценарий быстро превращается в паутину, где никто не понимает, зачем вообще уходят те или иные СМС. Я начинаю с текстового описания: какие события в исходной системе существуют, какие СМС нужны, кто их получает и при каких условиях сообщение не должно отправляться. Это похоже на легкий внутренний аудит процесса, только без страшных отчетов.
У Ильи схема родилась за одно рабочее утро. У нас было три основных события в CRM: «заказ поступил в ПВЗ», «заказ не забран 2 дня», «заказ скоро будет возвращен». Для каждого события мы описали: кто является получателем, какие поля нам нужны (телефон, ФИО, номер заказа, адрес ПВЗ), какие исключения (например, клиент запретил СМС или выбрал только email), и какие ограничения по времени отправки (ночью не писать). Я отдельно подчеркнула, что правило тишины ночью должно быть зашито в сценарий, а не «оставлено на совесть оператора».
Полезно представить себе одну конкретную линию жизни клиента. Вот заказ пришел, человек получил первое уведомление, потом забыл, потом получил напоминание, потом все-таки дошел. Здесь нет никакой магии, но есть куча нюансов: как часто напоминать, будет ли третий пинг, что делать, если клиент уже забрал заказ, а уведомление по пути «застряло». Поэтому до входа в интерфейс make.com я прошу клиента словом и на листке описать минимальный сценарий: что точно нужно, а что оставим на потом. Это критично, потому что без такого каркаса легко впасть в соблазн «а давайте еще отправим скидку другу клиента».
Чтобы не запутаться, удобно записать будущие шаги сценария в виде упрощенного списка. Я часто держу такую схему рядом, пока настраиваю make.com смс рассылки, потому что по-другому рука сама тянется добавить лишний модуль «на всякий случай».
- Получить событие из CRM или другой системы с минимальным набором полей.
- Проверить согласия клиента на СМС и ограничение по времени отправки.
- Сформировать тело сообщения на основе шаблона и данных.
- Отправить запрос в SMS-сервис и получить статус доставки.
- Залогировать результат в отдельной таблице или CRM для последующего анализа.
Похожая схема спасла и наш проект с Ильей. Когда к нам подключился маркетинг и сказал «а давайте еще одно напоминание за день до окончания хранения», мы просто добавили новый триггер в CRM и еще один блок проверки в сценарии. Не пришлось ломать текущую архитектуру. Это означает, что правильное предварительное планирование — это не только про структуру, но и про будущую масштабируемость. Если сценарий в make.com изначально собран как монолит без вариантов ветвления, любое новое требование превращается в хирургическую операцию.
Помнишь тот остывший кофе в начале — именно на этом этапе он и стремительно превращается в ледяной, потому что планирование почти никогда не выглядит «креативной задачей». Однако без него красивая картинка в make.com через месяц превращается в то, что боятся открывать по утрам.
Что учесть по 152-ФЗ и согласиям до запуска SMS-сценария
Юридическая часть редко вызывает восторг, но игнорировать ее при SMS-рассылках в России — дорогое удовольствие. Я всегда проверяю три базовых слоя: откуда берутся номера телефонов, как и где зафиксировано согласие на СМС, и есть ли у клиента возможность отписаться. Тут лучше быть занудой, чем потом спорить с регулятором. Условно, если вы не можете одним абзацем объяснить, на каком основании шлете человеку СМС и как он может отозвать согласие, сценарий лучше не запускать.
С Ильей у нас ситуация была чуть проще: все номера и согласия хранились в CRM, которая уже проходила проверку безопасности. Нам нужно было лишь убедиться, что в исходном событии есть флаг «согласен на СМС», а не только общая «согласен на обработку данных». Это разные вещи, и Роскомнадзор в этом смысле довольно прямолинеен. Я заметила, что многие компании в регионе до сих пор считают, что одна галочка «согласен на обработку» автоматически покрывает все каналы, но это не так (забудь, что я только что сказала про «проще»: по факту мы трижды проговаривали формулировки согласий с юристами клиента).
Практический подход такой: мы не выносим содержание ПД в make.com, а используем идентификаторы и технические поля. Телефон клиента берется из CRM или другого внутреннего хранилища по безопасному API, а make.com оркестрирует только логику: «кому, когда, при каком событии отправить». При желании можно даже сделать так, чтобы содержимое СМС формировалось на стороне российского бэкенда, а make.com лишь дергал отдельный endpoint «отправь сообщение с таким ID». Это немного сложнее в настройке, зато сильно успокаивает службу безопасности.
Есть еще вопрос отписки. В транзакционных СМС (типа «заказ прибыл») отсылка к отписке обычно не обязательна, но если на тот же канал поползет маркетинг, без понятной механики «стоп, хватит» начнутся жалобы. Здесь работает простой принцип: если вы шлете человеку хоть что-то, что он может счесть рекламой, у него должен быть способ это прекратить. Для SMS-канала это может быть короткая команда в ответ или ссылка на страницу настроек уведомлений в личном кабинете, если она реально работает, а не просто «для галочки».
Чтобы не утонуть во всех этих правилах, я для себя держу одно рабочее ограничение: если сценарий сложно объяснить регулятору, его надо упростить. Это означает, что никакой спорной сегментации по «похожим на тех, кто покупал» без отдельного согласия, никакой передачи содержимого заказов в открытом виде через третьи страны. Да, make.com сам по себе не российский сервис, и это отдельный риск, но если вы выносите в него только техническую логику и не передаете избыточные ПД, этот риск можно управляемо снижать.
В случае с Ильей мы зафиксировали в проектной документации: какие данные уходят в make.com, какие остаются только в CRM, какие хранятся у SMS-провайдера в РФ. Это звучит слегка занудно, но когда через полгода к проекту пришла новая служба безопасности, нам не пришлось в спешке вспоминать «а что мы туда вообще отдаем».
Как собрать базовый сценарий SMS-рассылки в Make.com в 5 шагов
Переход к интерфейсу make.com всегда радует глаз: круглые модули, стрелочки, все красиво. Но за этой красотой легко спрятать логические дыры. Поэтому базовый сценарий я строю по проверенной структуре: триггер, подготовка данных, проверка ограничений, отправка СМС, логирование результата. В простом варианте это один сценарий, но если трафик большой, можно разделить на несколько — для разных типов уведомлений. На первых порах достаточно одного, чтобы понять, как ведет себя связка с SMS-сервисом.
У Ильи мы начали с триггера из CRM: при изменении статуса заказа на «прибыл в ПВЗ» отправлялось вебхуком событие в make.com. Первый модуль сценария — «Custom webhook» или «HTTP» с приемом данных. Я попросила разработчика CRM передавать минимум: идентификатор заказа, телефон, флаг согласия, время прибытия и часовой пояс клиента. Дальше шел модуль преобразования данных: привести телефон к единому формату, вычистить пробелы, проверить, что номер вообще похож на реальный. В этом смысле нормализация данных до отправки экономит массу нервов, потому что SMS-сервис обычно честно спишет деньги за попытку отправить на битый номер.
После подготовки данных мы добавили ветку с проверкой условий: есть ли согласие, не попадает ли текущее время в «ночное окно тишины», не было ли уже отправлено аналогичное уведомление по этому заказу. Make.com это решает комбинацией «Router» и фильтров. Например, если флаг согласия равен false, мы не шлем СМС, а просто логируем событие «уведомление не отправлено по причине отсутствия согласия». Это важный момент для внутренней прозрачности: вы потом сможете показать, что система не нарушала 152-ФЗ, а осознанно фильтровала сообщения.
Дальше в ход идет модуль HTTP-запроса к API SMS-сервиса. На практике это один аккуратно настроенный запрос, где вы подставляете токен, номер телефона, идентификатор шаблона и параметры для подстановки. Я обычно делаю отдельный модуль «Compose SMS payload», который формирует тело запроса, чтобы в самом HTTP-модуле не было каши из формул. После отправки мы анализируем ответ: статус «accepted», «delivered», «failed» и сопутствующие коды. Если сервис поддерживает callback-и по доставке, можно сделать отдельный webhook-сценарий для обработки финальных статусов.
Чтобы эти пять шагов не потерялись в деталях, удобно еще раз в сжатом виде проговорить логику. Здесь небольшое текстовое «сверху вниз» описание помогает увидеть, ничего ли мы не забыли, например, ретраи на случай временной ошибки провайдера.
На практике я заметила, что стабильная make.com интеграция смс строится по структуре: входное событие, очистка и проверка данных, фильтры по согласиям и времени, вызов SMS-API, обработка ответа и сохранение результатов в логи.
В проекте Ильи мы на этом не остановились: добавили небольшую задержку перед напоминанием, связали сценарий с таблицей исключений (когда клиент уже забрал заказ) и встроили в CRM панель мониторинга по статусам отправки. Но базовый каркас остался тем же. Получается, что make.com смс рассылки не про «магию визуальных блоков», а про последовательную логику, где каждый шаг можно объяснить бизнесу и службе безопасности без лишних терминов.
Как протестировать SMS-сценарий и не испортить отношения с клиентами
Самая нелепая ситуация — когда вы радостно включаете сценарий, а первая тысяча клиентов получает тестовый текст «ТЕСТ СМС 123». Чтобы такого не было, я всегда планирую отдельный этап тестирования на технических номерах и внутренних сотрудниках. Это не про недоверие к себе, а про уважение к людям, которые вообще не подозревают, что вы в этот момент играете в интеграции. Тест в make.com удобно строить через клоны сценариев и отдельные входные webhooks, не трогая боевые данные.
С Ильей мы сделали так: в SMS-сервисе нам выделили несколько тестовых номеров, на которые не тарифицировались сообщения. В make.com мы создали копию сценария и заменили реальные номера на тестовые через маппинг. Первые прогоны делали вручную, отправляя событие через встроенный «Run once». Потом настроили небольшую «песочницу» из 10 реальных заказов сотрудников компании, которые заранее знали, что им придут уведомления. Это критично, потому что живые данные всегда ведут себя не так, как искусственные.
Во время тестов мы ловили неожиданные вещи: нестандартные форматы телефонов, странные часовые пояса, задержки со стороны SMS-провайдера. Один раз выяснилось, что CRM отправляет одно и то же событие дважды при редактировании заказа, и если бы мы не поймали это на тесте, клиенты получали бы по две одинаковые СМС. Пришлось добавить дополнительное условие на стороне make.com: не отправлять сообщение, если похожая запись за последние несколько минут уже была залогирована.
Полезно заранее расписать, что именно вы проверяете на тестовом этапе. Я иногда даже черчу себе небольшой список на бумаге, чтобы не упустить мелкие, но важные моменты: корректность текста, подстановки имени, ссылки, статусы доставки. Это звучит чуть педантично, но один пропущенный плейсхолдер вида {order_id} в тексте уже портит ощущение «нас здесь уважают».
Я поняла, что хороший тест SMS-сценария — это не только про факт доставки, но и про ощущение сообщения глазами клиента: читаемо ли, понятен ли следующий шаг, не выглядит ли оно как спам.
После нескольких раундов теста мы с Ильей согласовали точку старта: сначала включили сценарий только на один регион и один тип ПВЗ. В течение недели внимательно смотрели на логи ошибок и обращения в поддержку. Лишь потом масштабировали на всю сеть. Да, это медленнее, чем нажать одну кнопку «включить всем», зато более экологично: вы не экспериментируете на всей клиентской базе сразу.
Как добавить ИИ и персонализацию к SMS через Make.com без лишнего хайпа
Словосочетание «ИИ и СМС» звучит как повод нарисовать красивую презентацию, но в реальной жизни все намного приземленнее: нам нужно немного упростить жизнь пользователю и сэкономить время сотрудников. Make.com позволяет вставлять ИИ-модули в цепочку отправки, но я предпочитаю использовать их дозированно — для генерации вариативного текста, анализа ответов клиентов и приоритизации обращений. В российском контексте и с учетом 152-ФЗ это особенно чувствительно: нельзя просто так гонять персональные данные через внешние модели без четкого понимания, что вы делаете.
В кейсе Ильи мы решили не использовать ИИ для исходных уведомлений о заказах — транзакционные тексты должны быть максимально предсказуемыми. Зато подключили его на следующем шаге: когда клиент отвечал на СМС с вопросом или жалобой, сообщение попадало в отдельный сценарий make.com, где ИИ помогал классифицировать тональность и тему. В итоге оператор видел в своей панели не просто «новое смс», а «вероятная жалоба по срокам доставки» или «уточнение адреса», и мог быстрее реагировать. Это улучшило скорость обработки обращений, не превращая все в шоу с «умным ассистентом».
Помнишь про кофе из начала? Тут он как раз был выпит уже горячим, потому что играться с ИИ внутри make.com мне всегда чуть веселее, чем рисовать очередную ветку маршрутизатора. Но чтобы не улететь в эксперименты, мы четко зафиксировали: никакого анализа содержимого заказа, никакой избыточной интерпретации данных, минимум контекста в запросах. Это критично, потому что каждый лишний факт в промпте — это дополнительные риски по ПД.
На практике ИИ-модуль в make.com можно использовать в трех зонах. Во-первых, генерация текстов напоминаний в мягком тоне, с учетом времени суток и типа точки выдачи. Во-вторых, анализ ответных сообщений от клиентов для маршрутизации: жалобы, вопросы, благодарности. В-третьих, подготовка агрегированных отчетов для руководства о том, как часто клиенты не доходят до ПВЗ, что их больше всего раздражает в доставке. Последний кейс я люблю особенно: из потока коротких СМС вы вытаскиваете кристаллизованные инсайты для операционки.
Здесь работает следующее: ИИ в связке с make.com не заменяет живых людей, а выступает фильтром и помощником, который снимает рутину с глаз и рук, оставляя человеку ответственность и финальное решение.
С Ильей мы запускали ИИ-модуль осторожно, сначала на выборке из нескольких сотен сообщений. Модель ошибалась, иногда причисляла нейтральные вопросы к «жалобам», но в среднем попадала достаточно, чтобы операторы сказали: «нам стало проще». После этого мы начали потихоньку донастраивать промпт, добавляя локальные слова и жаргон клиентов сети. Получается, что такая персонализация не в том, чтобы «каждому свое СМС по гороскопу», а в том, чтобы отвечать быстрее и точнее, когда человек пишет «где мой заказ, уже бесит».
Как не перестараться с персонализацией SMS при автоматизации
Есть тонкая грань между полезной персонализацией и ощущением «за мной следят». Когда мы добавляем динамический контент в СМС через make.com, важно помнить, что телефон — очень личное пространство. На практике я придерживаюсь строгого минимализма: имя, номер заказа, краткий статус, ссылка на подробности. Все остальное оставляю для email и личного кабинета. Если вы начнете вставлять в СМС слишком много деталей, люди начнут нервничать (нет, подожди, иногда нервничают даже от обращения по имени, особенно если в базе оно записано криво).
Технически make.com позволяет делать чудеса: подставлять ближайший пункт выдачи, прогнозировать время загруженности, подогревать промокодами. Но я всегда задаю один вопрос: если бы я получила такое сообщение сама, меня бы это порадовало или насторожило? Например, «Марина, твой заказ 123 уже ждет на Пушкина, 5, до 20:00» — окей, а вот «Марина, мы видим, что ты живешь рядом с Пушкина, 5, поэтому принесли сюда» уже выглядит навязчиво. Это означает, что чем меньше вы подчеркиваете свою «осведомленность», тем спокойнее клиент.
В make.com персонализация обычно реализуется через маппинг полей из исходной системы в шаблон сообщения. Я стараюсь держать эту часть сценария максимально прозрачной: один блок подготовки текста, где понятно, какие именно данные куда подставляются. Это облегчает и аудит, и дальнейшие изменения. Если маркетинг просит «давайте добавим поле X», сразу видно, что это за поле и насколько оно безопасно для вывода в СМС.
Чтобы удержать эту грань, я мысленно провожу для каждого нового элемента персонализации небольшой «стресс-тест». Это не полноценная методика, но набор вопросов, которые я прокручиваю у себя в голове каждый раз, когда в тексте появляется новая переменная.
Я поняла, что лучший фильтр для персонализации в СМС — это вопрос «выглядело бы это естественно, если бы вы сами получили такое сообщение в 7 утра, сонная и без кофе». Если ответ «скорее да», значит, можно пробовать.
В кейсе Ильи мы ограничились мягкой персонализацией: имя, номер заказа, дата окончания срока хранения, ссылка на карту точки выдачи. Ни слова о том, откуда мы знаем адрес клиента или историю его заказов. Маркетинг пытался добавить «а давайте скажем, что ты у нас уже третий раз», но на этом месте мы дружно вспомнили про 152-ФЗ и общее ощущение прозрачности. Получается, что грамотная персонализация — это не про «максимум переменных», а про аккуратную дозировку, где каждая деталь работает на удобство, а не на демонстрацию всеведения.
Какие подводные камни есть у SMS-рассылок через Make.com в российских условиях
После первых успехов почти всегда наступает фаза «ну все, теперь можно масштабировать». Именно здесь вылезают те самые мелкие баги, о которых никто не думал. В связке make.com и SMS-сервисов типовые проблемы три: неожиданные лимиты и задержки у провайдера, рост нагрузки на сценарий и изменение исходных систем (CRM, ERP), которые вдруг начинают слать события иначе. В России к этому добавляются сезонные всплески (черная пятница, Новый год), когда операторы связи откровенно задыхаются.
С Ильей мы прочувствовали это на собственной шкуре: в первый же большой распродажный день часть СМС ушла с задержкой в несколько часов. Формально сценарий в make.com отработал идеально, но SMS-сервис начал ставить сообщения в очередь. Клиенты приходили уже без уведомлений, и колл-центр снова ловил волну недовольства. После этого я всегда повторяю: автоматизация не отменяет физические ограничения каналов. Make.com не может отправить сообщения быстрее, чем это делает ваш провайдер, он только аккуратно их подает.
Чтобы минимизировать такие эффекты, полезно заранее обсудить с SMS-сервисом лимиты по скорости отправки, приоритет транзакционных сообщений и поведение при перегрузках. Иногда имеет смысл разделить потоки: критические уведомления — по одному каналу, менее критичные — по другому. Еще один частый камень — разное трактование статусов доставки. То, что в API выглядит как «accepted», не всегда означает «дошло до телефона». Поэтому в мониторинге нужно смотреть не только на технические коды, но и на фактическую реакцию клиентов.
Помнишь ту ситуацию с остывшим кофе и распечатанной схемой процесса в начале? Возвращаясь к ней, именно в момент первых задержек СМС у меня на столе снова оказалась та же схема, только дополненная стрелочками «задержка здесь» и «узкое место там». Пришлось признать, что мы слегка переоценили устойчивость инфраструктуры провайдера и недооценили пики трафика. Это означает, что к любому красивому сценарию в make.com нужно сразу прикручивать не менее красивую систему наблюдения.
Я вижу еще один типичный подводный камень — изменения в исходной системе, которые никто не согласовал с командой автоматизации. Например, разработчики CRM решили «оптимизировать» схему статусов заказов или переименовали поле «phone» в «mobile». С точки зрения их задач все логично, но сценарий в make.com в этот момент начинает тихо падать или отправлять СМС не тем людям. Чтобы этого не случилось, я всегда настаиваю на минимальном регламенте изменений: если трогаете события, которые идут в интеграцию, сообщите заранее.
На практике я заметила, что самая уязвимая часть связки make.com смс рассылки — не настройки сценария, а коммуникация между командами: CRM, маркетингом, ИТ и безопасностью.
С Ильей нам повезло: он оказался тем редким руководителем, который был готов собрать всех в один чат и договориться, что любые изменения статусов или полей сначала проговариваются. Да, иногда это замедляло выкатывание «классных фич», но сильно сокращало количество ночных авралов. Получается, что подводные камни чаще лежат не в коде, а в привычках людей: кто-то добавил новый тип уведомления без учета лимитов, кто-то запустил параллельную рассылку через другой канал, и инфраструктура ушла в красную зону.
Как настроить мониторинг и логи для SMS-сценария в Make.com
Без нормального мониторинга любая автоматизация превращается в черный ящик: что-то где-то крутится, иногда падает, иногда встает само. В случае с SMS это особенно чувствительно, потому что последствия видны не сразу. Я всегда делаю два уровня наблюдения: технический (ошибки сценариев, ответы SMS-провайдера) и бизнесовый (сколько СМС ушло, сколько дошло, как изменились ключевые метрики). В make.com есть базовые логи, но для серьезной эксплуатации их нужно дополнять внешним хранилищем.
С Ильей мы завели отдельную таблицу в базе данных, куда сценарий записывал каждое событие: идентификатор заказа, тип уведомления, статус отправки, код ответа сервиса, время. Поверх этого аналитик построил простой дашборд: количество СМС по дням, доля ошибок, среднее время от события в CRM до отправки сообщения. Это позволило не только ловить сбои, но и видеть, как автоматизация реально влияет на поведение клиентов. Например, мы увидели, что после ввода напоминаний на второй день хранения доля незабранных заказов упала примерно на 6-7%.
Технический мониторинг в make.com я настраиваю через уведомления о падениях сценариев и подозрительных всплесках ошибок. Это не самый изящный механизм, но он работает: если сценарий три раза подряд получил ошибку от SMS-сервиса, можно отправить алерт в Telegram-группу ответственных. На этом уровне лучше не экономить: пусть лишний раз придет сообщение о временной проблеме, чем сутки никто не заметит, что СМС не доходят. Да, иногда это приводит к «шуму» в чатах, но это тот случай, когда лучше чуть больше сигналов, чем одно большое удивление.
Я заметила, что хороший мониторинг SMS-сценариев — это не только про «упало-упало», но и про ранние звоночки: увеличилось время доставки, выросла доля недоступных номеров, изменилась структура ошибок.
С точки зрения 152-ФЗ и внутреннего аудита, логи еще и выполняют роль доказательной базы: вы можете показать, что система не только старалась отправлять уведомления, но и честно фиксировала провалы. Это спасает от ситуации, когда все кивают друг на друга: «это CRM виновата», «нет, это провайдер», «нет, это make.com». В идеале структура логов должна позволять восстановить историю по конкретному клиенту и заказу за несколько минут, а не по кускам собирать скриншоты из разных систем.
Как измерить эффект от SMS-интеграции и где здесь место людям
В какой-то момент любая автоматизация упирается в очень простой вопрос: а стало ли лучше? Для make.com смс рассылки ответ надо искать не только в логах отправки, но и в бизнес-метриках: скорость забора заказов, нагрузка на колл-центр, количество жалоб. Я люблю, когда удается посчитать эффект в часах и рублях, а не только в «ощущениях». В истории с Ильей мы договорились еще на старте: замеряем базовую линию, запускаем автоматизацию, через месяц и три месяца сравниваем.
По цифрам получилось так. До запуска автоматических СМС через make.com среднее время между поступлением заказа в ПВЗ и его забором было около 3,4 дня. После запуска трех уведомлений (прибыл, напоминание на второй день, предупреждение перед возвратом) показатель снизился до 2,9 дня. Доля заказов, ушедших обратно на склад по истечении срока хранения, сократилась примерно на 8%. Колл-центр отметил снижение повторных обращений «где мой заказ» на 15-20% в пиковые дни. Да, эти цифры не звучат как космический прорыв, но в пересчете на логистические расходы это очень прилично.
Помнишь тот первый рабочий день, когда мы с Ильей рисовали схему на листке, а кофе остывал? Возвращаясь к тому моменту, приятно было через три месяца смотреть на сравнительный отчет: те самые стрелочки «здесь клиент не знает, что заказ приехал» стали значительно короче. Это означает, что make.com интеграция смс перестала быть «очередным ИТ-проектом» и превратилась в рабочий инструмент, который реально изменил поведение людей. И да, часть операторов колл-центра честно признались, что им стало скучнее, потому что однотипных звонков по заказам стало меньше 🙂
При этом я всегда осторожна с фразой «мы заменили людей». На практике хорошая автоматизация снимает рутину, но оставляет (и даже усиливает) зону, где без человека никак: сложные случаи, конфликтные ситуации, нестандартные запросы. СМС-сценарий на make.com в этом смысле просто выравнивает фон: до людей доходит меньше банальных вопросов, и они могут глубже разбираться в том, что действительно требует внимания. В кейсе Ильи это выразилось в том, что операторы стали больше времени уделять сложным ситуациям с логистикой и качеством обслуживания на ПВЗ.
Я поняла, что правильный вопрос не «сколько людей мы сократили», а «сколько часов ручной, повторяющейся работы мы вернули людям, чтобы они занялись более умными задачами».
Если смотреть шире, SMS-интеграция через make.com — это лишь один кирпичик в общей архитектуре коммуникаций. Рядом живут уведомления в мессенджерах, email, пуши. Но SMS в России по-прежнему держит свою нишу: там, где нужен максимально надежный и быстрый канал, который не требует установки приложений. В связке с ИИ, грамотной логикой и уважением к 152-ФЗ получается вполне зрелый инструмент, а не игрушка для «поэкспериментировать». И здесь уже вопрос не только технологий, но и культуры: как команда смотрит на данные, на автоматизацию, на клиента.
История Ильи закончилась довольно спокойно и даже чуть буднично. Через полгода после запуска сценария мы просто встретились, чтобы обновить несколько шаблонов и добавить еще один тип уведомлений для B2B-клиентов. Никто уже не говорил о «проекте», это стало частью операционки. И это, если честно, лучший комплимент для любой автоматизации: когда про нее перестают вспоминать до тех пор, пока она не нужна в контексте новых задач.
Куда двигаться дальше, если базовая интеграция уже работает
Если ты дочитал до этого места, скорее всего, базовые СМС-сценарии через make.com для тебя уже не звучат как космическая технология. Вопрос смещается: что делать дальше, как развивать эту историю, не превратив все в монстра из сотни сценариев. Я бы наметила три траектории роста. Первая — углубление аналитики: анализ пути клиента, A/B-тесты разных текстов, связывание данных по каналам. Вторая — расширение набора событий: подключение статусов по возвратам, оплатам, сервисным заявкам. Третья — интеграция с другими инструментами автоматизации, тем же n8n, если он используется внутри контура компании.
На практике этот путь у всех разный. Кто-то начинает стягивать все уведомления в единый оркестратор и строит над этим красивую панель для маркетинга. Кто-то, наоборот, усиливает роль внутренних разработчиков и переносит часть логики с make.com во внутренние микросервисы, оставляя платформу скорее как «клей». Правильного ответа нет, есть модель зрелости компании и ее ощущение риска. Мне самой близок гибридный подход, когда все, что затрагивает глубинные ПД, остается под российскими системами, а make.com используется как удобный визуальный слой, который можно быстро править и показывать бизнесу.
Если хочется копнуть глубже в такие архитектуры, я иногда разбираю похожие кейсы у себя в Telegram-канале про автоматизацию и AI-процессы, где можно посмотреть живые схемы, а не только текстовые описания. Там как раз много про связки make.com, n8n, ИИ-агентов и российскую специфику 152-ФЗ, без лишнего хайпа и маркетинга. А если интереснее посмотреть на то, чем я занимаюсь как консультант по AI governance и автоматизации, изредка обновляю сайт с проектами и разбором кейсов, тоже без витринной мишуры. Это все продолжение той же линии: как сделать так, чтобы контент и процессы работали сами, а люди возвращали себе время.
Иногда мне самой хочется дописать еще одну фразу про «умное будущее, где все процессы автоматизированы…», но я останавливаю себя. Потому что даже самый красивый сценарий в make.com ничего не стоит, если внутри компании нет привычки задавать три простых вопроса: для кого мы это делаем, что человек увидит в итоге и как мы это объясним проверяющему. Если на эти три вопроса есть честные ответы, техническая часть — вопрос техники и аккуратного планирования. Если нет — никакая интеграция, даже идеальная на бумаге, не спасет.
Что ещё важно знать
Вопрос: Как начать интеграцию SMS с Make.com, если у меня еще нет CRM?
Ответ: В таком случае можно использовать простую таблицу или базу данных как источник событий, а не полноценную CRM. Make.com умеет работать с Google Sheets, Airtable и многими БД, и вы можете запускать СМС по изменению записей там. Главное — сразу продумать, откуда берутся согласия клиентов на сообщения и как вы будете хранить телефоны с учетом требований 152-ФЗ в России.
Вопрос: Можно ли использовать Make.com для массовых рекламных SMS-рассылок по России?
Ответ: Технически можно, если SMS-провайдер поддерживает нужные объемы, но риски при этом сильно выше, чем у транзакционных уведомлений. Для рекламных рассылок вам нужны отдельные согласия, точный учет отписок и более тщательный контроль текста и частоты сообщений. Я бы разделяла транзакционный и маркетинговый трафик и не запускала большую рекламу только через make.com без нормально настроенной маркетинговой платформы.
Вопрос: Что делать, если SMS-провайдер иногда тормозит или падает?
Ответ: В таких ситуациях лучше заложить в сценарий Make.com несколько уровней защиты: ретраи с задержкой, запись неотправленных сообщений в очередь и уведомления ответственным при массовых ошибках. Если провайдер регулярно не выдерживает нагрузку, стоит обсудить с ним гарантированные лимиты или рассмотреть резервного поставщика. В любом случае логирование статусов отправки помогает докопаться, где именно начинаются проблемы.
Вопрос: Как быть с персональными данными, если Make.com размещен за пределами России?
Ответ: Я бы выносила в Make.com только технические данные и минимально необходимые поля, избегая передачи «сырых» персональных данных без необходимости. Основные ПД хранятся в российских системах, а Make.com управляет логикой и обращается к ним по защищенному API. В спорных случаях стоит проконсультироваться с юристами по 152-ФЗ и описать архитектуру потоков данных на одной схеме, чтобы всем было понятно, где что находится.
Вопрос: Можно ли полностью передать генерацию текста SMS на ИИ внутри Make.com?
Ответ: Я бы не делала так для транзакционных сообщений, потому что они должны быть стабильными, предсказуемыми и юридически выверенными. ИИ удобен для вариативных подсказок, анализа ответов клиентов и вспомогательных текстов, но критичные уведомления лучше писать руками и согласовывать с юристами и безопасностью. Для тестов можно использовать ИИ на небольших сегментах, но держать под контролем и содержимое, и поведение системы.
Вопрос: Что делать, если в компании уже используют n8n, а не только Make.com?
Ответ: В этом случае можно разделить роли инструментов: часть интеграций и логики, которая критична по безопасности и должна крутиться внутри контура, отдать n8n, а Make.com использовать для более гибких внешних сценариев. Они спокойно сосуществуют, общаясь через API, и вы можете выбрать для каждого процесса тот инструмент, который лучше вписывается в инфраструктуру. Главное — не дублировать одну и ту же логику в двух местах, чтобы потом не искать, где что сломалось.