Make (Integromat): автоматизация процессов без кода

Make (бывший Integromat) - визуальный конструктор автоматизаций, где сервисы соединяются между собой мышкой, без кода. Ты собираешь «сценарий»: событие в одном приложении запускает цепочку действий в других. Пришла заявка - робот создал карточку в CRM, отправил уведомление в Telegram и записал строку в таблицу. Из России сервис открывается и работает, аккаунт заводится обычным способом. Узкое место одно - оплата российской картой, и на старте его закрывает бесплатный тариф. Ниже разбираю, как устроен сценарий изнутри, во сколько операций он обходится, где обычно ломается и чем логика Make отличается от n8n.

Что такое Make и зачем он бизнесу?

Make снимает с людей ручной перенос данных между сервисами. Один раз описываешь логику «если случилось X - сделай Y и Z», и дальше робот работает сам, круглосуточно, без опечаток и забытых строк.

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

Ключевое слово здесь - «визуально». Кода писать не нужно. На экране кружки-модули, соединённые линиями, и по этим линиям бегут данные. Новичку так удобнее: логика лежит перед глазами целиком, и держать её в памяти не требуется.

Ещё не решил, какие процессы вообще стоит отдавать роботу? Начни с разбора, где рутина реально мешает: с каких задач начинать автоматизацию рутины. Общая карта того, что в компании поддаётся автоматизации, разложена здесь: автоматизация бизнес-процессов с ИИ.

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

Из чего состоит сценарий в Make?

Сценарий (scenario) - твоя автоматизация целиком. Собирается из нескольких типов деталей, и их стоит знать по именам, потому что именно ими оперирует вся справка сервиса.

• Триггер - первый модуль, событие-старт. «Новое письмо на почте», «новая строка в таблице», «прошла оплата». Триггеры бывают двух видов: опрашивающие (Make сам заглядывает в сервис по расписанию) и мгновенные, работающие по вебхуку - сервис сам стучится в Make в момент события.
• Модули действий - что делать дальше. Создать, обновить, отправить, найти. Каждый модуль отвечает за одно действие в одном сервисе.
• Роутер - развилка. При одном условии данные идут налево, при другом направо. Заявка на сумму больше 100 000 уходит старшему менеджеру, остальное падает в общую очередь.
• Фильтр - привратник на линии между двумя модулями. Пропускает данные дальше только при выполненном условии. Скажем, «пропустить, только если в теме письма есть слово оплата».
• Итератор - разбирает массив на отдельные элементы. Пришёл заказ с пятью товарами внутри - итератор превращает его в пять отдельных проходов, чтобы каждый товар обработался сам по себе.
• Агрегатор - обратная операция: собирает несколько кусков обратно в одну структуру. Пять строк заказа склеиваются в одно письмо клиенту.
• Маппинг - способ переложить данные из одного модуля в другой. Берёшь поле «email» из триггера и вставляешь его в поле «кому» у модуля отправки.

Отдельно упомяну хранилища данных (Data store) - маленькие таблицы внутри самого Make. Они выручают, когда сценарию надо что-то помнить между запусками: список уже обработанных телефонов, счётчик выданных номеров, дату последней синхронизации. Без такой памяти сценарий каждый раз стартует с чистого листа и легко создаёт дубли на записях, которые уже проходили через него вчера.

Готовых интеграций в Make много: Google-сервисы, Telegram, Notion, популярные CRM, платёжные системы, почта, календари. Проверять наличие своего сервиса проще всего прямо в поиске модулей при сборке. Когда готового модуля нет, выручает универсальный HTTP-модуль - он умеет стучаться в любой сервис, у которого есть открытое API. Тут пригодится умение читать документацию чужого API, и ровно на этом месте новички чаще всего застревают.

Ещё в Make есть встроенные функции для работы с текстом, датами и числами: обрезать пробелы, привести телефон к единому формату, посчитать разницу между датами. Они спасают там, где сервис-источник отдаёт данные в неудобном виде.

Как собрать первый сценарий в Make?

Разберу на живом примере: заявка с сайта падает в Telegram и в таблицу.

1. Заводишь аккаунт на make.com и создаёшь новый сценарий кнопкой Create a new scenario.
2. Ставишь триггер. Ищешь свой источник заявок - форму, вебхук, Google-таблицу - и выбираешь событие «новая запись». Для вебхука Make выдаст адрес, который надо вставить в настройки формы на сайте.
3. Добавляешь модуль Telegram с действием «отправить сообщение». Подключаешь бота через токен от BotFather, выбираешь чат.
4. Собираешь текст сообщения через маппинг: перетаскиваешь поля из триггера - имя, телефон, комментарий - прямо в тело сообщения.
5. Добавляешь модуль таблицы с действием «создать строку» и раскладываешь те же поля по колонкам.
6. Жмёшь Run once. Make прогонит сценарий на реальных данных один раз и покажет, что вошло и что вышло на каждом шаге.
7. Включаешь расписание - раз в 15 минут, чаще или по вебхуку в реальном времени.

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

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

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

Сколько операций съедает сценарий и как не сжечь тариф?

Make считает деньги в операциях. Одна операция - одно срабатывание одного модуля. Логика простая, но арифметика удивляет новичков на второй неделе.

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

Дальше начинается интересное. Добавь роутер с проверкой, поиск дубля в CRM и уведомление менеджеру - модулей станет шесть, и месячный расход удвоится. Поставь итератор на заказ из пяти позиций - каждая позиция пройдёт свою ветку, и одна заявка обойдётся уже в пятнадцать-двадцать операций вместо трёх.

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

Расход удобно смотреть в двух местах. В карточке сценария есть счётчик операций за период, а в истории прогонов - разбивка по каждому запуску. Когда цифра за сутки выглядит подозрительно большой, открой самый тяжёлый прогон и посчитай, сколько раз сработал каждый модуль внутри цикла. Обычно виноват итератор, который получил массив длиннее ожидаемого: сервис отдал вместо пяти позиций заказа весь каталог целиком.

Что стоит сделать до запуска:

• Посчитать модули в сценарии и умножить на ожидаемое число событий в месяц.
• Заменить опрос вебхуком везде, где сервис-источник это позволяет.
• Поставить фильтр как можно ближе к началу цепочки, чтобы ненужные записи отваливались до того, как потратят операции в тяжёлых модулях.
• Свести три отдельных сценария в один, если они дублируют один и тот же триггер.
• Сверить свой расчёт с актуальной страницей тарифов - лимиты у планов разные и время от времени меняются.

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

Разбор случая: заявки интернет-магазина

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

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

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

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

Ломается эта схема чаще всего в трёх местах. Телефоны приходят в разном формате: где-то с восьмёркой, где-то с плюс семь, где-то с пробелами, поиск дубля их не сопоставляет и плодит вторые карточки. Лечится нормализацией номера функцией замены прямо в маппинге. Затем менеджер переименовывает колонку в таблице, и модуль записи падает молча. Последний классический случай - клиент отправляет форму дважды подряд, после чего в чат прилетают два одинаковых уведомления, а в CRM ложатся две сделки.

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

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

Почему сценарии Make ломаются?

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

Проверять результат просто: запусти Run once, открой историю прогонов и посмотри содержимое каждого шага - что вошло в модуль и что он отдал наружу. Make показывает данные на каждом узле, и для новичка это главное его достоинство: поломку видно глазами, гадать не нужно.

Как настроить обработку ошибок?

Обработчик ошибок в Make вешается на конкретный модуль отдельной веткой. Правой кнопкой по модулю, «Add error handler», и дальше решаешь, что делать при сбое.

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

Полезно знать четыре типа обработки:

• Resume - подставить запасное значение и продолжить цепочку. Годится, когда упавший модуль не критичен.
• Ignore - пропустить сбойный проход и идти дальше. Опасная штука: без параллельного уведомления данные исчезают без следа.
• Break - отложить проход в очередь незавершённых и повторить позже. Спасает, когда чужой сервис лежит временно.
• Rollback - откатить проход целиком, чтобы не осталось половины записей.

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

Отдельно настрой уведомления на уровне аккаунта, чтобы Make писал на почту при остановке сценария. Автоматическое отключение после серии ошибок - штатное поведение, и узнавать о нём лучше сразу.

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

Чем логика Make отличается от n8n?

Оба сервиса решают одну задачу - соединяют приложения без кода. Цепочку они при этом строят по-разному, и разница чувствуется с первого часа работы.

Параметр	Make	n8n
Тип	Облако, чужой сервер	Облако или свой сервер (self-hosted)
Логика потока	Данные текут по одной линии, пакет за пакетом	Данные идут таблицей, узлы обрабатывают массив целиком
Порог входа	Ниже, всё максимально наглядно	Чуть выше, ближе к мышлению разработчика
Гибкость и код	Есть, но облачный сервис ограничивает	Полный контроль, свой код, свои модули
Оплата из РФ	Проблема с российской картой	Self-hosted бесплатен, платить не нужно
Тарификация	По числу операций	По числу запусков сценария либо бесплатно на своём сервере

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

Тарификация подталкивает к тому же выбору. Make берёт деньги за каждое срабатывание модуля, поэтому длинные цепочки с итераторами дорожают нелинейно. У n8n на своём сервере расход упирается только в мощность железа.

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

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

Работает ли Make из России и как оплатить?

Сайт make.com открывается, регистрация проходит, сценарии выполняются. Узкое место - оплата платных тарифов российской картой: она обычно не проходит.

Что делают на практике:

• Начинают на бесплатном тарифе. Собрать первые сценарии, обкатать их на реальных заявках и понять, твой это инструмент или нет, на нём вполне реально.
• Платят картой иностранного банка, если такая есть.
• Переезжают на self-hosted n8n, когда упираются в лимиты и не хотят завязываться на зарубежную оплату. n8n ставится на свой сервер и подписки не требует.

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

Правила доступа и оплаты меняются без предупреждения. Критичные для бизнеса процессы стоит держать там, где ты контролируешь и сервер, и оплату, а на облачном конструкторе оставлять то, потерю чего переживёшь за один вечер. Такая же логика работает с любым зарубежным инструментом - подробнее про варианты доступа писал на примере Claude из России.

Куда внутри сценария встроить ИИ?

Make умеет дёргать нейросети как обычный модуль, и именно тут конструктор перестаёт быть просто перекладывателем данных.

Понятные места для встройки:

• Разбор входящего текста. Клиент написал в свободной форме - модель вытаскивает оттуда имя, город, бюджет и срок и отдаёт готовыми полями для CRM.
• Классификация обращений. Модель размечает заявку как «жалоба», «вопрос по оплате» или «новый заказ», а роутер разводит их по разным веткам и ответственным.
• Черновик ответа. Модель пишет вариант письма, а человек его правит и отправляет. Автоотправка без проверки на этом этапе - плохая идея.
• Сжатие переписки. Длинная ветка в почте превращается в три строки для карточки сделки.

Ответы модели становятся предметными, когда у неё под рукой есть контекст твоего бизнеса: прайс, регламент, частые вопросы. Как это собрать и подключить, разобрано в статье база знаний для нейросети. Про выбор самой модели под задачу есть отдельное сравнение: Claude или ChatGPT.

Дальше связка «Make плюс модель» начинает походить на сотрудника, который сам разбирает почту и готовит ответы. Что это за конструкция и чем она отличается от обычного бота, объясняю здесь: цифровой сотрудник. Если задача ближе к диалогу с клиентом, смотри в сторону чат-бота: чат-бот для бизнеса.

Четыре возражения, которые слышу чаще всего

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

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

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

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

Иногда правильный ответ - отдать сборку тому, кто делает такое каждый день. Аргументы за оба варианта я взвесил в статье ИИ-агенты под ключ или собрать самому.

Где в автоматизации всё равно нужен человек?

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

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

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

С чего начать на этой неделе?

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

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

Разборы готовых сценариев Make и n8n, промпты и шаблоны ролей для цифровых сотрудников выкладываем в закрытом канале ИИмперии - там связки, которые можно поставить себе в работу.

Какой процесс ты сегодня сделал руками уже третий раз? Вот с него и начни.

Источники

• Make Help Center - официальная база знаний Make: сценарии, модули, обработка ошибок, счётчик операций.
• Make Pricing - актуальные тарифы и лимиты операций по планам.
• n8n Documentation - документация n8n, включая установку self-hosted и логику работы узлов с массивами.