Интеграционная платформа — программа, которая соединяет между собой чужие сервисы без разработки. Правило описывается одной фразой: «когда в форме появилась заявка, создай сделку в CRM и напиши менеджеру в мессенджер». Такой сценарий собирается за час мышкой. Ниже — из чего состоит сценарий, три класса решений с границами применимости и что ломается через месяц после запуска.
Зачем нужен отдельный сервис интеграции сервисов
Рабочих программ у компании обычно пять-семь: сайт с формой, почта, мессенджер, CRM, учётная программа, таблицы, хранилище файлов. Каждая своё дело делает, а между ними ходит человек: скопировал из формы, вставил в CRM, продублировал в чат, отметил в таблице. Платформа заменяет этого человека правилом. Ключевое слово — «чужие»: она ничего не хранит и ничем не управляет, а ставится поверх сложившегося набора программ, ничего в нём не меняя.
Отсюда главное ограничение: платформа не чинит процесс. Если данные в двух системах ведутся по разным правилам, обмен честно перенесёт расхождение из одной в другую — только быстрее человека.
Из чего состоит любой сценарий
Как бы ни назывались кнопки в конкретной платформе, набор частей один и тот же. Разобрать удобно на живом примере: заявка с сайта попадает в CRM, а менеджер получает сообщение.
Событие-триггер. То, с чего сценарий начинается. Два вида: внешнее событие — форма отправила данные, в папке появился файл, в таблице добавилась строка; и расписание — каждый час, каждое утро в девять. В примере триггер внешний: сайт отправляет заявку сразу после нажатия кнопки.
Шаги. Действия в чужих сервисах: найти контакт, создать сделку, отправить сообщение, записать строку. Идут по очереди, каждый получает данные предыдущего; в примере их три.
Условия. Развилки: «если контакт нашёлся — обновить, иначе создать». Часть коварная: каждая новая ветка удваивает число путей, которые придётся проверять при любой правке.
Преобразование данных. Самая недооценённая часть и обычно самая трудоёмкая. Телефон в форме введён как «8 (912) 345-67-89», а CRM ждёт «+79123456789»; дата в одном сервисе «05.09.2026», в другом «2026-09-05»; названия услуг на сайте не совпадают с номенклатурой в учёте. Интеграция — это по большей части приведение полей к общему виду, а не соединение проводов.
Обработка ошибок. Что происходит, когда шаг не сработал: CRM недоступна, мессенджер вернул отказ, поле не заполнено. Вариантов три — повторить попытку через минуту, уйти по запасной ветке, остановиться и сообщить человеку. Пропускают этот пункт чаще прочих, из-за него сценарии и умирают тихо.
Три класса решений и когда какой
Облачная платформа с готовыми коннекторами
Сервис, где сценарии собираются в браузере, а подключения к популярным программам уже написаны. Коннектор — готовый блок, умеющий разговаривать с конкретным сервисом: знает его адреса, поля и способ авторизации. Albato, Make, Zapier — названия из этого класса, и вопрос «Albato что это» обычно означает «что за облачная платформа связывает сервисы». Платят за операции; первый сценарий запускается в тот же день, свой сервер не нужен.
Границы. Данные проходят через чужую инфраструктуру — для персональных данных и коммерческой тайны это решается отдельно и не всегда решается. Набор коннекторов конечен: нет нужной программы в списке — остаётся универсальный блок запросов, и преимущество «без разработки» частично теряется. Цена растёт линейно объёму: копейки на тысяче операций становятся заметной строкой на полумиллионе.
Платформа на своём сервере
Тот же принцип, но программа развёрнута в своём контуре: на арендованном сервере или внутри сети компании. Данные не уходят наружу, платится не за операции, а за железо и за человека, который его обслуживает. Оправдано, когда подписка обгоняет стоимость сервера либо когда данные наружу выпускать нельзя. Тот же расчёт работает и шире: в проекте с распознаванием и синтезом речи контур из Whisper, Qwen3-TTS и pgvector развёрнут локально, без обращений к облачным моделям, на одной настольной машине.
Границы. Появляется своя инфраструктура: обновления, копии, мониторинг, дежурство при сбое. Сервер, о котором забыли, — это сценарии, которые встали ночью и никого не разбудили.
Своя интеграция кодом
Отдельная программа под конкретный обмен. Оправдана в трёх случаях: обмен нестандартный и коннектора к нему не существует; объём такой, что накладные расходы платформы на каждой операции становятся ощутимыми; логика сложнее, чем читаемая схема из блоков.
Границы обратные. Дороже в разработке, требует программиста при каждом изменении и порождает зависимость: «никто кроме них не разберётся в этом клубке кода» — жалоба про этот класс. Отсюда частый компромисс: тяжёлый обмен пишется кодом, остальное живёт на платформе.
Что считать на входе
От числа операций в месяц зависит и счёт за облако, и ответ на вопрос, пора ли переезжать на свой сервер. Считают до подписки.
Операция — один шаг сценария, отработавший на одной записи: сценарий из четырёх шагов на одной заявке даёт четыре операции, не одну.
Сценарии по событию: число событий в месяц × число шагов. Форма даёт 300 заявок в месяц, в сценарии четыре шага — 1 200 операций.
Сценарии по расписанию: число запусков в месяц × число шагов × среднее число обрабатываемых записей. Здесь прячется главная ошибка счёта: обход таблицы каждые пять минут — это 8 640 запусков в месяц, и если на каждом перебирается сотня строк, счёт идёт на сотни тысяч операций. Тот же обход раз в сутки — 30 запусков.
Отсюда два приёма, снижающие счёт в разы: разредить расписание там, где задержка ничего не стоит (договоры и отчёты терпят обход раз в сутки), и отсеивать ненужные записи первым шагом, а не в конце сценария. Считают по пиковому месяцу, а не по среднему.
Про n8n
Отдельный случай — платформа, работающая в обоих режимах: и как облачный сервис, и на своём сервере, из-за чего переезд между классами перестаёт быть переписыванием. Это рабочий инструмент данной практики: на нём собраны сценарии из кейсов — утренний обход таблиц с договорами, счётчик дней резидентства, приём заявок в мессенджер, конвейер из пяти сервисов, делающий короткий ролик из одной фотографии. Разбор — в статье n8n: что это и что на нём автоматизируют.
Что ломается
Сервис поменял API — сценарий встал. Чужая программа обновилась, поле переименовали, метод убрали: сценарий, работавший год, встаёт без единой правки со стороны заказчика. Помогает журнал запусков — список срабатываний со временем, данными и результатом. По нему видно, что именно сломалось и когда.
Заявка создалась дважды. Сеть моргнула, ответ об успешной записи не дошёл, платформа повторила отправку — в CRM две одинаковые сделки. Лечится ключом идемпотентности: собственным идентификатором записи, по которому принимающая сторона проверяет, не создавала ли уже такую. Вопрос к исполнителю прямой: что будет при повторной отправке одного заказа.
Ошибка проглотилась молча. Самый дорогой дефект. Сценарий падает, платформа пишет это в журнал, журнал никто не открывает — и неделю спустя выясняется, что заявки не доезжают. Лечится не дисциплиной, а уведомлением об ошибке: отдельным сценарием, который при сбое пишет ответственному в мессенджер. Полчаса настройки, окупается с первого случая.
Сценарий знает пароли ко всем системам. Доступы к CRM, почте, учёту и хранилищу лежат в одном месте, и часто это права администратора — так быстрее настраивать. Лечится разграничением: под каждую интеграцию заводится отдельная учётная запись с правами ровно на нужные действия. И учётные записи платформы оформляются на компанию, а не на исполнителя.
Когда платформа не нужна
Две системы и одна связка между ними. Если задача исчерпывается парой «сайт — CRM» или «магазин — учёт», сначала стоит проверить готовую интеграцию от самого вендора: она обычно входит в тариф, поддерживается разработчиком и не добавляет третьего участника, который тоже может упасть. Платформа окупается на трёх и более сервисах или на нестандартной логике. Разбор случая — в статье Интеграция сайта с 1С и CRM.
Разовый перенос данных. Переезд справочника, загрузка каталога, миграция контактов — это выгрузка в файл и загрузка обратно. Постоянный сценарий ради одной операции дороже, чем сделать её руками.
И общее: связка поверх неописанного процесса просто ускоряет беспорядок — Что автоматизировать первым.
Вопросы и ответы
Сколько времени занимает первый сценарий? Связка из трёх-четырёх шагов между популярными сервисами — час-два вместе с проверкой. Дольше всего уходит не на сборку, а на доступы: получить ключи ко всем системам и согласовать, кто их выдаёт. Сценарий с условиями и преобразованием полей — дни.
Нужен ли программист? Для типовых связок — нет, сборка идёт мышкой. Программист нужен там, где преобразование данных сложнее переименования поля, где вместо готового коннектора идёт универсальный блок запросов и где сценарий приходится делить на части.
Что делать, если нужного коннектора нет? Проверить, есть ли у сервиса открытый интерфейс для обмена данными. Есть — подключиться универсальным блоком запросов: дольше готового коннектора, но работает. Нет вовсе — интеграция невозможна ни на какой платформе, и вопрос переходит к замене самого сервиса.
Как оценить, пора ли переезжать на свой сервер? Сравнить три числа: годовую подписку при текущем объёме операций, стоимость сервера с обслуживанием за тот же год и стоимость переноса сценариев. Подписка обгоняет сумму двух других — расчёт в пользу переезда. Довод, который в деньгах не считается: запрет выпускать данные наружу.
Коротко
Платформа окупается там, где сервисов больше двух. До выбора инструмента считаются операции в месяц, до запуска настраиваются журнал и уведомление об ошибке, а доступы выдаются отдельные под каждый сценарий.
Разбор связок под конкретный набор сервисов — через контакты.