Как «прожорливый» Make.com едва не съел нашу автоматизацию в amoCRM | Кейс Addaptiva
Контекст. Связка была простая: сайт → Make ловит заявку → запускает Salesbot в amoCRM. На тестах — ок.
Что пошло не так.
— Полезный запуск тратил 7–10 операций.
— Make реагировал на любые события в amoCRM (заметки, правки полей, задачи) и запускал сценарий «вхолостую» — по 1 операции за каждый такой вызов.
— Итог: бесплатные 1000 операций сгорали за пару дней. На платных тарифах неиспользованные операции всё равно сгорают — платить за фильтрацию «шума» бессмысленно.
Решение. Убрали Make из критичного участка и поставили свой обработчик на Python на нашем сервере:
— принимаем только нужные веб-события (новая заявка / изменение статуса лида);
— предфильтры по сущности и полям + дебаунс 60 с;
— идемпотентность (одно событие — одна обработка);
— очередь и ретраи, логирование в файл.
Salesbot запускается через API amoCRM.
Результат.
— Затраты: ~300 ₽/мес на сервер вместо абонплаты за операции.
— Стабильность: ноль «холостых» запусков, защита от зацикливаний.
— Контроль: метрики и логи у нас, без ограничений внешней платформы.
Вывод (обновлённый).
No-/low-code (включая n8n) отлично работает там, где есть чистые вебхуки, внятная фильтрация и нужна скорость запуска. В нашем кейсе «шум» из amoCRM + биллинг Make делали процесс дорогостоящим, поэтому критичный участок вынесли в Python — конкретно для этих условий так стабильнее и дешевле. При других вводных мы бы спокойно оставили no-code или собрали это в n8n.