Zapier ці Make: просты запуск сутыкаецца з аплатай за кожную аперацыю

Для кароткай аўтаматызацыі, якую будзе наладжваць нетэхнічная каманда, Zapier звычайна дае прасцейшы старт; для працэсу з некалькімі маршрутамі і частымі зменамі логікі больш прыдатным можа быць Make. Агляд The Digital Project Manager звязвае Zapier з хуткім разгортваннем у камандах рознай падрыхтоўкі, а Make — з гнуткім візуальным рэдактарам для складаных сцэнарыяў. Гэта арыенцір для выбару, а не гарантыя аднолькавага часу наладжвання ў кожнай камандзе.

Другое адрозненне — у адзінцы выкарыстання. Правілы Zapier лічаць задачай паспяховае дзеянне, але выключаюць трыгеры, Filter, Paths і Formatter; правілы Make адносяць да расходу крэдытаў выкананне большасці модуляў, уключаючы атрыманне даных праз webhook, пошук і пераўтварэнне. Такім чынам, аднолькавы вынік можа расходаваць розную колькасць задач і крэдытаў. Гэта яшчэ не параўнанне сум у рахунку: памер і кошт пакетаў трэба ўлічваць асобна.

За што налічваюць выкарыстанне

У Zapier спачатку спрацоўвае трыгер, а потым выконваюцца дзеянні. Калі ўмова Filter спыняе запуск або Paths не выбірае пэўную галіну, дзеянні за імі не адбываюцца. Formatter можа змяніць фармат поля без дадатковай задачы. Аднак пошук мае асобнае правіла: калі ён наладжаны так, каб працэс працягваўся і пры адсутнасці запісу, пошукавы крок расходуе задачу; пры супрацьлеглай наладзе — не расходуе. Таму лік задач для працэсу з пошукам залежыць нават ад рэжыму гэтага кроку.

У Make звычайнае выкананне модуля расходуе крэдыт, у тым ліку калі модуль чытае ўваходныя даныя, стварае запіс або пераўтварае поле. Router сам па сабе крэдыту не расходуе; пералічаныя платформай модулі апрацоўкі памылак таксама з'яўляюцца выключэннем. Для асобных магчымасцей, у прыватнасці з AI Provider, расход можа адрознівацца ад аднаго крэдыту за дзеянне. Таму лік намаляваных модуляў не заўсёды роўны ліку крэдытаў, як і лік крокаў Zap не заўсёды роўны ліку задач.

Розніца становіцца прыкметнай пры паўтарэнні працэсу. Дадатковы аплатны модуль у сцэнарыі Make расходуе крэдыты пры сваім выкананні, а бясплатны для ўліку Formatter у Zapier не змяняе колькасці задач. Модулі пасля кроку, які вяртае некалькі асобных запісаў, могуць запускацца для кожнага з іх. Ацэнка расходу таму патрабуе ведаць не толькі схему, але і колькасць запісаў, што фактычна праходзяць праз кожную галіну.

Кароткі ланцужок: заяўка, CRM і Slack

Возьмем умоўны сцэнарый: адна заяўка прыходзіць праз webhook, пасля чаго сістэма стварае кантакт у CRM і адпраўляе паведамленне ў Slack. Лічым, што кожны крок выконваецца паспяхова, а дадатковы пошук кантакту не патрэбны. У Zapier прыём заяўкі служыць трыгерам і не расходуе задачу; стварэнне кантакту і паведамленне даюць дзве задачы. У Make адпаведныя тры модулі — прыём, стварэнне кантакту і адпраўка — даюць тры крэдыты, калі кожны расходуе адзін.

Калі ўмоўна паступіць тысяча такіх заявак і кожная запусціць асобнае выкананне, атрымаецца 2000 задач у Zapier супраць 3000 крэдытаў у Make. Гэтыя велічыні нельга дзяліць адна на адну, каб атрымаць розніцу ў кошце: крэдыт і задача належаць розным тарыфным сістэмам. Але разлік паказвае, чаму нават у кароткім працэсе расход залежыць ад таго, якія менавіта крокі платформа ўключае ва ўлік.

Для малой каманды тут важны і час запуску. Калі патрэбныя дзеянні CRM і Slack ужо гатовыя, лінейная паслядоўнасць у Zapier можа запатрабаваць менш працы з маршрутамі і перадачай даных. Калі ж у форме ёсць палі, якія трэба ачышчаць, або перад стварэннем кантакту патрэбна праверка дубляў, простая схема становіцца даўжэйшай. Тады час наладжвання трэба ацэньваць разам з новымі крокамі.

Разгалінаваны працэс: адна заяўка, адзін маршрут

Другі ўмоўны сцэнарый пачынаецца з webhook. Сістэма шукае кантакт у CRM, абнаўляе знойдзены запіс, прыводзіць тэкставае поле да патрэбнага фармату і выбірае адну з дзвюх галін; у абранай галіне стварае задачу ў знешнім сэрвісе і адпраўляе апавяшчэнне. Для разліку кантакт існуе, працуе толькі адна галіна, кожнае дзеянне завяршаецца паспяхова і на кожным кроку апрацоўваецца адзін запіс.

У Zapier для пошуку выбіраем наладу «працягваць, калі нічога не знойдзена». Тады пошук расходуе адну задачу нават у разгляданым выпадку, калі кантакт ёсць; абнаўленне і два дзеянні ў абранай галіне дадаюць яшчэ тры. Разам — чатыры задачы на заяўку. Webhook-трыгер, Formatter і Paths задач не дадаюць. Калі для пошуку выбраць наладу без працягу пры адсутнасці кантакту, разлік для знойдзенага запісу змяняецца да трох задач. Таму рэжым пошуку трэба ўлічваць у прагнозе расходу.

У Make пры дапушчэнні аднаго крэдыту за кожны звычайны модуль атрымліваецца шэсць крэдытаў: за прыём, пошук, абнаўленне, пераўтварэнне і два дзеянні ў выбранай галіне. Router не павялічвае гэтую суму. Пры ўмоўнай тысячы заявак, якія ідуць па такім самым шляху, гэта 6000 крэдытаў супраць 4000 задач Zapier з абранай наладай пошуку. Параўнанне паказвае структуру выкарыстання, але пакуль нічога не кажа пра тое, якая платформа выставіць меншы рахунак.

На расход уплывае і колькасць даных унутры аднаго запуску. Калі пошук або іншы модуль Make вяртае некалькі запісаў, наступныя модулі могуць выканацца для кожнага, і першапачатковыя шэсць крэдытаў ужо не апішуць увесь запуск. Калі Zapier накіруе некалькі запісаў у асобныя паспяховыя дзеянні, вырасце і лік задач. Візуальная карта Make дапамагае ўбачыць маршруты і пераўтварэнні, але расход вызначаюць рэальныя праходы запісаў праз модулі.

Калі шырэйшы каталог мае значэнне

Колькасць лагатыпаў у каталогу мала дапамагае без патрэбнай функцыі ў канкрэтнай інтэграцыі. Параўнанне Make называе больш за 7900 гатовых шаблонаў сцэнарыяў і прызнае шырэйшы каталог прыкладанняў Zapier, адначасова падкрэсліваючы магчымасці ўласнага візуальнага разгалінавання. Шаблон можа паскорыць зборку, але сам па сабе не сведчыць, што інтэграцыя ўмее знайсці кантакт па патрэбным полі або абнавіць менавіта той аб'ект CRM, які выкарыстоўвае бізнес.

Калі абедзве платформы падтрымліваюць патрэбныя дзеянні, дадатковыя прыкладанні Zapier не ўплываюць на гэты канкрэтны выбар. Калі дзеянне ёсць толькі ў адным каталогу, гэта можа пераважыць розніцу ў зручнасці рэдактара і ў стартавым кошце тарыфу. Асобна трэба адрозніваць гатовую інтэграцыю ад злучэння праз API: апошняе можа працаваць, але патрабуе наладжвання запытаў, аўтарызацыі і далейшай падтрымкі. Для фрылансера гэта яго ўласны час, для аперацыйнай каманды — нагрузка на таго, хто будзе падтрымліваць працэс.

Рашэнне па тарыфе і часу наладжвання

Тарыфы Zapier паказваюць бясплатны план са 100 задачамі за месяц і двухкрокавымі Zap, а Professional — ад $19,99 на месяц з шматкрокавымі працэсамі і webhook; пачатковая цана залежыць ад спосабу аплаты. Для абодвух умоўных сцэнарыяў з некалькімі дзеяннямі бясплатны двухкрокавы Zap не падыдзе. Калі ўключыць аплату звыш пакета задач, дадатковыя задачы маюць вышэйшую стаўку; калі адключыць яе, працэсы спыняюцца пасля вычарпання ліміту.

У Make трэба выбраць пакет крэдытаў, які пакрывае разлічаныя запускі і магчымыя дадатковыя галіны. Параўнанне пачатковай цаны платных планаў без гэтага аб'ёму збівае з панталыку: аднолькавая колькасць заявак не азначае аднолькавай колькасці аплатных адзінак. У рашэнне ўваходзяць таксама час наладжвання і падтрымка маршрутаў, асабліва калі CRM, форма або правілы размеркавання часта змяняюцца.

• Кароткі ланцужок, патрэбныя гатовыя інтэграцыі і мала часу на асваенне — аргументы пачаць з Zapier.
• Шмат галін і пераўтварэнняў, патрэба бачыць рух кожнага запісу і чалавек, які будзе падтрымліваць схему, — аргументы на карысць Make.
• Калі ключавое дзеянне даступнае толькі ў адной платформе, спачатку вырашае гэтая магчымасць; тарыф трэба лічыць ужо для працоўнай схемы.

Чытайце таксама:

• Supabase ці Firebase: прадказальны рахунак сутыкаецца з аплатай за чытанні
• n8n, Make ці Zapier: няправільны тарыф даражэе з кожным крокам
• RPA ці ШІ-агент: гнуткасць прайграе на стабільных аперацыях