Make (бывший Integromat) закрывает большинство сценариев автоматизации Kommo: создать сделку из формы, отправить уведомление, прокинуть данные в Google Sheets. Кастомная разработка нужна, когда появляются три фактора - высокий объём операций, сложная логика с состоянием и требование к надёжности (ретраи, идемпотентность, двусторонняя синхронизация). Если у вас десятки сценариев и сотни тысяч событий в месяц - вы платите Make больше, чем стоила бы своя интеграция, и при этом не контролируете её поведение при сбоях.
В интеграционных проектах с Kommo мы видим повторяющуюся картину: команда начинает с одного-двух сценариев в Make, всё работает, через год их сорок, а биллинг по операциям превратился в постоянную статью расходов. Параллельно появляется первый сценарий, который Make технически не вытягивает - например, двусторонняя синхронизация сделки с внешней системой без дублей. По данным обзоров pricing Make от Zapier, модель оплаты построена на операциях (с 2025 года - на кредитах), где каждое действие модуля списывает кредит. Эта статья - о том, где проходит граница между «хватает Make» и «нужна разработка», с конкретными цифрами и техническими критериями.
Боль не в том, что Make плохой. Боль в том, что решение «no-code или код» принимают по привычке, а не по расчёту. Head of sales видит, что сценарий работает, и не считает стоимость операций на объёме. Разработчик видит ограничение Make и хочет всё переписать, хотя 80% сценариев Make закрывает идеально. Правильный ответ почти всегда гибридный - и чтобы его найти, нужно понимать, что именно у Make под капотом.
Make (Integromat): визуальная no-code платформа автоматизации, где workflow собирается из сценариев (scenarios), а каждый сценарий - из модулей (modules), выполняющих действия с приложениями. Оплата - по операциям/кредитам, списываемым за каждое срабатывание модуля.
Что Make решает хорошо для Kommo
Make закрывает весь класс линейных, событийных автоматизаций Kommo без единой строки кода. Это его сильная сторона, и для большинства команд её достаточно.
У Make есть готовое приложение Kommo с модулями на основные сущности: создать и обновить сделку, контакт, компанию, добавить задачу, прикрепить примечание. Триггеры ловят события через webhook на стороне Kommo. Для чего это идеально подходит:
- Линейные сценарии вида «событие -> действие». Пришла заявка из Typeform -> создать сделку в Kommo. Сделка перешла на этап -> отправить сообщение в Slack. Один вход, предсказуемый выход.
- Низкий и средний объём. Сотни, максимум первые тысячи срабатываний в месяц. На этом объёме операции стоят копейки.
- Прокидывание данных в простые приёмники. Google Sheets, Notion, рассылка, уведомление. Где не нужна гарантия доставки и сложная обработка ответа.
- Быстрые прототипы. Проверить гипотезу автоматизации за час, без участия разработчика и без релиза.
Если вы только настраиваете процессы в Kommo, начните с Make. Логика настройки воронки в Kommo и базовые автоматизации отлично ложатся на визуальный конструктор. Переходить на код имеет смысл только когда упрётесь в конкретный потолок - а не заранее.
Где Make упирается в потолок
Make перестаёт быть выгодным и надёжным на четырёх типах задач: объём, состояние, надёжность и двусторонняя синхронизация. Разберём каждый.
Operations-биллинг на объёме
Главный скрытый множитель - оплата за каждое действие модуля. Первый модуль сценария списывает один кредит. Каждый последующий модуль списывает кредит за каждый обработанный bundle (пакет данных). Роутеры, фильтры и итераторы тоже тратят операции - даже когда условие не выполнилось.
Это значит: сценарий из 6 модулей при срабатывании на одной сделке - это 6 операций, а не одна. Если у вас 50 000 сделок в месяц и сценарий из 6 шагов, вы платите за 300 000 операций. По данным разбора pricing от Zapier, на таких объёмах подписка Make превращается в тысячи долларов в год. Та же логика, реализованная как свой сервис на webhook Kommo, стоит фиксированно - цена хостинга, а не цена за операцию.
Сложная логика и состояние
Make мыслит сценариями без долговременной памяти. Каждый запуск - изолированное прохождение модулей. Как только логика требует хранить состояние между запусками (накапливать события, ждать N действий, дедуплицировать по истории) - вы начинаете городить костыли: writes в Google Sheets как «база данных», Data Store с ограничениями, цепочки сценариев, дёргающих друг друга. Это работает, пока логику можно нарисовать. Когда у вас условный граф с десятком ветвлений и зависимостью от прошлых данных - визуальный сценарий становится нечитаемым и хрупким.
Обработка ошибок и ретраи
У Make есть error-роуты и директивы (Resume, Rollback, Commit, Break), а также модули задержки для ретраев. Для простого «повторить при 429 или 500» этого хватает. Но, как отмечают в разборах error handling в Make, для production-нагрузки с circuit breaker, dead-letter queue и тонкой настройкой backoff под каждый эндпоинт нужен код. В Make каждый ретрай - это снова операции, а сам error-handling приходится дублировать в каждом сценарии вручную. На сорока сценариях это становится отдельной проблемой обслуживания.
Двусторонняя синхронизация и идемпотентность
Самый частый случай, где Make ломается, - двусторонний sync. Kommo и внешняя система должны отражать изменения друг друга, и нельзя допустить дублей или бесконечного эха (изменение в A триггерит обновление B, которое триггерит обновление A). Make не даёт встроенного механизма идемпотентности.
Идемпотентность: свойство операции давать один и тот же результат при повторном выполнении - повторный вызов «создать сделку» не должен породить второй дубль.
Чтобы сделать sync в Make безопасным, нужно вручную городить external-ID поля, upsert-логику и dedup-проверки перед каждым созданием. Это возможно, но превращает «no-code» в скрытую разработку внутри визуального редактора - без тестов, версионирования и контроля. В своём сервисе идемпотентность решается ключом и проверкой в БД за пару часов работы.
Что значит «нужна кастомная разработка»
Кастомная разработка нужна, когда вы пересекаете хотя бы одну из четырёх границ - и эта граница устойчива, а не разовая. Разовый сложный сценарий можно дотерпеть в Make. Системную нагрузку - нет.
Чек-лист перехода черты:
- Объём. Стабильно выше ~10 000 операций в месяц по одному направлению, и счёт за Make растёт быстрее, чем стоил бы свой сервис на хостинге.
- Состояние. Логика требует хранить и анализировать историю событий, а не реагировать на одно событие за раз.
- Надёжность. Потеря или дубль записи стоит денег - платёж, инвойс, синхронизация остатков. Нужна гарантия доставки, идемпотентность, нормальные ретраи.
- Двусторонность. Данные должны течь в обе стороны без эха и дублей.
- Связность. Сценариев стало так много, что вы не помните, какой что делает, и любое изменение API ломает половину.
Если совпало два и более пункта - считайте TCO своей интеграции. Обычно она окупается за несколько месяцев. Подробнее про подход - на странице кастомных интеграций для Kommo.
Сравнение: Make vs кастомная разработка
Короткий вердикт: Make выигрывает на скорости запуска и низком объёме, кастом - на стоимости при масштабе, контроле и надёжности. Таблица по ключевым осям.
| Критерий | Make (Integromat) | Кастомная разработка |
|---|---|---|
| Стоимость на объёме | Растёт линейно с числом операций | Фиксированная (хостинг), не зависит от объёма |
| Скорость запуска | Часы, без разработчика | Дни-недели, нужен разработчик |
| Контроль над логикой | Ограничен модулями платформы | Полный, любая логика и состояние |
| Гибкость (ретраи, идемпотентность) | Базовая, ручные костыли | Полная, на уровне кода |
| Двусторонний sync | Хрупкий, без гарантий | Надёжный, с дедупликацией |
| Поддержка и отладка | Визуальные логи, но дубли логики | Логи, тесты, версионирование |
| Зависимость от вендора | Высокая (цены, лимиты, изменения) | Низкая, код ваш |
Важно: это не «или - или». Часто оптимально оставить простые сценарии в Make, а критичные по объёму и надёжности - вынести в свой сервис. Гибрид экономит и время, и деньги.
Реальный кейс с цифрами
В типовом проекте команда на Kommo пришла с такой картиной: 38 сценариев в Make, около 280 000 операций в месяц, биллинг около 200 долларов в месяц и растёт. Главная боль - не цена, а один сценарий двусторонней синхронизации сделок с внешней биллинг-системой, который раз в неделю создавал дубли и требовал ручной чистки.
Что сделали. Оставили 31 простой сценарий в Make - они дешёвые и стабильные. Семь тяжёлых сценариев (двусторонний sync, дедупликация, агрегация событий) вынесли в один сервис на webhook Kommo с идемпотентностью по external-ID и нормальными ретраями с exponential backoff. Результат за первый месяц: операции в Make упали примерно на 60%, дубли в синхронизации - до нуля, ручная чистка данных перестала съедать время менеджера. Свой сервис на хостинге обходится в фиксированные ~25 долларов в месяц вместо растущего счёта за операции.
Главный вывод кейса: переписывать всё было не нужно. Достаточно было вынести семь сценариев, которые отвечали за 60% операций и 100% проблем с надёжностью.
Для кого что
Make хватает, если вы команда от 15 человек, у вас десятки тысяч событий в месяц или меньше, сценарии линейные, а цена ошибки в данных невысока. Это большинство команд на старте и в середине пути. Если вы только разбираетесь, что умеет платформа, начните с обзора Kommo CRM и соберите первые автоматизации в Make.
Кастомная разработка нужна, если вы пересекли две и более границы из чек-листа: высокий объём, состояние, требование надёжности, двусторонний sync. Это обычно зрелые команды с выручкой, завязанной на корректность данных в CRM - платежи, инвойсы, синхронизация с ERP. Чаще всего правильное решение - гибрид: Make для простого, свой сервис для критичного. Помочь спроектировать архитектуру и оценить объём работ может команда Exceltic.dev.
Часто задаваемые вопросы
Когда Make дешевле кастомной разработки для Kommo?
Make дешевле, пока объём операций низкий и сценарии простые. Ориентир - до нескольких тысяч операций в месяц. На этом уровне вы платите за подписку десятки долларов, а разработка своего сервиса не окупится. Как только объём стабильно превышает ~10 000 операций в месяц по одному направлению, или сценарий из множества модулей срабатывает на каждой сделке, биллинг по операциям начинает обгонять фиксированную стоимость своего сервиса на хостинге. В этой точке стоит посчитать TCO: цена Make за год против разовой разработки плюс хостинг.
Можно ли сделать надёжную двустороннюю синхронизацию в Make?
Технически да, но это уже не no-code, а скрытая разработка внутри визуального редактора. Make не даёт встроенной идемпотентности и защиты от эха (когда изменение в системе A триггерит обновление B, а оно - обратно A). Чтобы sync был безопасным, нужно вручную добавлять external-ID поля, upsert-логику и dedup-проверки перед каждым созданием записи. Это работает, но без тестов, версионирования и контроля версий - и каждое изменение API одной из систем рискует всё сломать. Надёжный двусторонний sync почти всегда дешевле и стабильнее сделать кодом.
Что такое операции в Make и почему их так много?
Операция (с 2025 года - кредит) списывается за каждое срабатывание модуля. Первый модуль сценария - одна операция. Каждый следующий модуль списывает операцию за каждый обработанный пакет данных (bundle). Роутеры и фильтры тоже тратят операции, даже если условие не сработало. Поэтому сценарий из 6 модулей - это 6 операций на одно срабатывание, а не одна. На объёме в десятки тысяч сделок это превращается в сотни тысяч операций в месяц. Именно неочевидное умножение операций на число модулей делает Make дорогим на масштабе.
Нужно ли переписывать все сценарии Make при переходе на кастом?
Нет, и это частая ошибка. В большинстве проектов 80% сценариев Make закрывает идеально и дёшево - их трогать не нужно. Переписывать стоит только те, что отвечают за основной объём операций или за критичную надёжность: двусторонний sync, дедупликацию, агрегацию с состоянием, обработку платежей. Обычно это 10-20% сценариев, которые дают 60-80% операций и почти все проблемы. Гибридная архитектура - Make для простого, свой сервис для тяжёлого - экономит и бюджет на разработку, и стоимость операций.
Make или своя интеграция через API Kommo - что выбрать для старта?
Для старта почти всегда Make. Он позволяет проверить гипотезу автоматизации за час, без разработчика и без релиза. Вы быстро поймёте, какие сценарии реально нужны и насколько они нагружены. Своя интеграция через API Kommo оправдана, когда вы уже знаете объём и требования к надёжности - то есть после того, как Make показал свои границы на вашем конкретном кейсе. Преждевременная разработка - такая же ошибка, как и упорство с Make на объёме, где он стал дорогим.
Bottom line
- Начинайте с Make. Для линейных сценариев и низкого объёма он быстрее и дешевле любой разработки. Не пишите код заранее.
- Считайте операции на объёме. Сценарий из N модулей стоит N операций за срабатывание. На десятках тысяч сделок биллинг обгоняет стоимость своего сервиса.
- Выносите в код только критичное. Двусторонний sync, идемпотентность, состояние, надёжность платежей - это границы, за которыми Make становится хрупким и дорогим.
- Гибрид - норма, а не компромисс. Make для простого, свой сервис для тяжёлого. Переписывать всё не нужно.
Если вы упёрлись в потолок Make - растущий счёт за операции, дубли в синхронизации или сценарий, который не нарисовать, - опишите задачу команде Exceltic.dev. Разберём архитектуру, посчитаем, что оставить в Make, а что вынести в код, и оценим объём работ.