В чем разница и как выбирать сервис no-code/low-code интеграций

Всем привет! Я Лаптев Алексей, основатель и главный разработчик сервиса no-code интеграций apimonster.

Zapier и Integromat мировые лидеры, но из РФ их сложно оплатить.

Они реализуют работу с популярными методами API других сервисов, предоставляя простой интерфейс настройки передачи параметров в эти API.

Например вот api AmoCRM с которым работают все сервисы.

Никаких ноу-хау нет, одни и те же действия везде реализованы одинаково.

Ценность сервисов в том, что задача уже реализована, стабильно работает и есть поддержка. Никуда не убежит и не заболеет, в отличие от фрилансера или программиста в штате.

В табличках сравнения тарифов могут быть десятки функций, но важны 4.

1. Наличие нужных сервисов

Тут обычно проблем нет, везде популярные сервисы реализованы.

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

2. Количество транзакций на тарифе

Транзакция — это главная метрика, от которой зависит стоимость сервиса.

1 транзакция — это по сути 1 запрос в api, например:

Чем больше транзакций, тем больше вы потребляете ресурсов сервиса и тем больший счет он вам выставляет.

Чтобы прикинуть сколько вам нужно транзакций — умножьте количество заявок в месяц на 3-4. Например если у вас 100 заявок в месяц, то у вас будет 300-400 транзакций в месяц — создать сделки, отправить конверсии и уведомления.

Также не путайте транзакции и вебхуки.

Вебхук — это информация которая прилетела в сервис.

Транзакция — это информация которая вылетела.

На вебхуки жестких ограничений нет.

3. Логгирование входящих и исходящих вебхуков

Это очень важная штука, чтобы понимать какие поля в связки подставить и что вообще происходит.

4. Настройка под ключ и поддержка

Не смотря на всю простоту no-code, часто бывает что клиенты вообще не технари и не понимают казалось бы самых простых вещей и соотвественно самостоятельно решить свою проблему не смогут.

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

Мы реализовали 500 или 100500 сервисов!

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

На самом деле в no-code сервисах отлично работает закон Паретто — 80% задач решаются в рамках 20% сервисов, а то и вообще 95%/5%.

Поэтому основная работа идет со всякими амо/битриксами/метриками/телегой и число таких популярных сервисов меньше 50.

Факт наличия какого-то редкого сервиса или их большого количества никак не влияет на то как будет создана сделка в AmoCRM на заявку с Тильды.

Скорее много сервисов даже плохо — так как команда сильно распыляется поддерживая их.

У нас 100500 вариантов сценариев настройки!

Ну это тоже прямой маркетинговый трюк. Просто перемножили количество сервисов на количество действий.

На самом деле надо просто смотреть, может ли сервис решить именно вашу задачу. А у вас там будет ну 5-10 типовых сценариев.

Количество подключений/связок

Тоже маркетинговое ограничение, которое отмирает.

Обычно фактическое число подключений и связок разумно соответствует тарифу и технической надобности их ограничивать — нет.

Теперь зная что ключевая метрика — количество транзакций, можно и сравнить сервисы.

Еще раз напомню, что количество транзакций для рядового малого/среднего бизнеса можно считать по формуле: количество заявок в месяц * 3-4.

100 заявок/мес — 400 транзакций

1000 заявок/мес — 4000 транзакций

Поэтому большинству клиентов хватит 10000-30000 транзакций в месяц, если не делать там непонятно что.

Выводы

Но кроме цены, важна поддержка.

На примере ApiMonster.

Работает стабильно

Бывают ошибки в редких кейсах, но все это быстро правится. В целом uptime 99.99%.

Мониторинг работы и качество кода на высоком уровне, в отличие от разовых разработок.

Чем меньше клиенту нужен сервис, тем большую нагрузку он создает

Что-то накрутить в CRM чтобы прилетало 100500 вебхуков в день — это святое, при этом тариф выбирается минимальный. Пришлось даже вводить ограничение на входящие вебхуки.

Чем меньше данных, тем сложнее ТЗ

Это классика.

Если какого-то функционала нет — высока вероятность его быстро получить

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

Но если сервис очень редкий и задача буквально одноразовая — будет или отказ или предложено другое решение, тк делать задачу под одного клиента и постоянно ее поддерживать — не выгодно.