Make vs Zapier 2026: gilus palyginimas Lietuvos verslui

Abu įrankiai turi nemokamą planą, o mokami planai skaičiuojami pagal atliktų veiksmų kiekį, tik skirtingai. Zapier skaičiuoja užduotis (tasks): kiekvienas sėkmingai atliktas veiksmas yra viena užduotis, o paleidiklis (trigger) ir filtrai paprastai neskaičiuojami. Make skaičiuoja kreditus (anksčiau jie vadinosi operacijomis): kreditą sunaudoja kiekvieno modulio paleidimas, įskaitant ir paleidiklį, kuris tikrina naujus duomenis.

Praktikoje tai reiškia štai ką. Paprastas dviejų žingsnių srautas abiejuose kainuoja panašiai. Kai scenarijus ilgėja, atsiranda sąlygos, ciklai per sąrašų eilutes ir duomenų apdorojimas, Make dažniausiai išeina pigiau, nes jo planuose už tą pačią kainą gaunate gerokai daugiau vienetų. Tačiau Make kreditai gali tirpti netikėtai: jei scenarijus kas 15 minučių tikrina naujus įrašus, kreditai naudojami net tada, kai naujų įrašų nėra.

Mano patarimas – prieš renkantis suskaičiuoti realų tūrį: kiek kartų per mėnesį srautas pasileidžia ir kiek žingsnių kiekviename. Tada palyginkite su dabartinėmis abiejų įrankių kainomis jų svetainėse, nes planai ir įkainiai keičiasi kelis kartus per metus. Žemiau esančioje lentelėje pateiktos kainos – orientacinės.

Zapier vis dar paprasčiausias startas. Srautas statomas kaip sąrašas iš viršaus į apačią: „kai įvyksta tai, padaryk tai“. Jei esate vadovas ar administratorė, kuri nori pati sujungti formą su lentele, Zapier dažniausiai pavyks per pirmą vakarą.

Make redaktorius vizualus: moduliai dėliojami ant drobės ir jungiami linijomis, šakos (routeriai) matomos iš karto. Tai labai patogu, kai logika sudėtingesnė, bet pradžioje reikia suprasti kelias sąvokas: kaip duomenys keliauja tarp modulių, kas yra iteratorius ir agregatorius, kaip veikia klaidų valdymas. Paprastai po kelių bandymų tai tampa aišku, bet pirmas scenarijus užtrunka ilgiau nei Zapier.

Abiejuose galima įterpti kodo: Zapier turi „Code by Zapier“ (JavaScript ir Python), Make – HTTP modulį bet kokiam API ir funkcijas duomenims apdoroti. Jei komandoje nėra nė vieno, kuris nori gilintis, svarbiau ne įrankis, o tai, kas scenarijus prižiūrės, kai kažkas sustos.

Čia skirtumas mažesnis, nei atrodo iš integracijų skaičiaus. Zapier turi didesnę paruoštų programėlių biblioteką, Make – mažesnę, bet abiejose dažniausiai nerasite paruoštų jungčių lietuviškoms sistemoms, tokioms kaip Rivilė, B1, Montonio ar SAF-T ataskaitų įrankiai. Tokiais atvejais jungiamasi tiesiogiai per sistemos API arba webhook.

Būtent čia Make dažnai patogesnis: HTTP modulis yra visuose planuose, o užklausą ir atsakymą lengva sudėlioti vizualiai. Zapier tam turi „Webhooks by Zapier“ ir API užklausų veiksmus, tačiau jie prieinami tik mokamuose planuose. Abiem atvejais reikės perskaityti lietuviškos sistemos API dokumentaciją, todėl tai darbas, kurį klientai dažniausiai patiki man.

Dar vienas aspektas – duomenų vieta. Make leidžia pasirinkti ES duomenų centrą kuriant paskyrą, o Zapier infrastruktūra daugiausia JAV. Jei per srautus keliauja klientų asmens duomenys, pasitikrinkite abiejų įrankių duomenų tvarkymo sutartis ir įrašykite tai į savo BDAR dokumentaciją.

Paimkime iliustracinį atvejį: maža el. parduotuvė Vilniuje, apie 300 užsakymų per mėnesį. Norima, kad kiekvienas užsakymas atsirastų Google Sheets lentelėje, klientas gautų asmeninį laišką, o sąskaita būtų sukurta buhalterinėje programoje. Be to, kartą per dieną vadovas nori gauti suvestinę į el. paštą.

Zapier tai būtų kelių žingsnių srautas: kiekvienas užsakymas – keli veiksmai, vadinasi, per mėnesį – apie tūkstantis ar daugiau užduočių. Kadangi buhalterinė programa neturi paruoštos jungties, reikės webhook arba API žingsnio, t. y. mokamo plano. Make tas pats scenarijus sunaudotų panašų ar šiek tiek didesnį kreditų kiekį, bet jo planuose kreditų vienetų už tą pačią kainą daugiau, todėl mėnesio sąskaita paprastai būtų mažesnė.

Mano rekomendacija tokiam atvejui – Make, nebent komanda jau aktyviai naudoja Zapier ir turi ten dešimtis veikiančių srautų. Jei planuojate, kad užsakymų skaičius augs keleriopai arba norite, kad duomenys liktų jūsų serveryje, verta pažiūrėti ir į n8n.

Svarbu ir tai, kas nutinka, kai mėnesio limitas baigiasi. Abu įrankiai turi savo taisykles: kai kuriuose planuose galima papildomai įsigyti vienetų, kituose srautai sustoja iki kito mėnesio. Jei parduotuvės sezonas netolygus, pavyzdžiui, prieš Kalėdas užsakymų gerokai daugiau, prieš renkantis planą pasitikrinčiau, kas nutiks piko mėnesį.

Automatinio perkėlimo tarp šių įrankių nėra, scenarijai statomi iš naujo. Todėl pirmiausia surašau visus veikiančius srautus: kas juos paleidžia, kokius duomenis perduoda, kur baigiasi. Dažnai paaiškėja, kad dalies srautų niekas nebenaudoja, o keli kitus galima sujungti į vieną.

Tada naujus scenarijus paleidžiu lygiagrečiai su senais ir kelias dienas lyginu rezultatus. Tik įsitikinęs, kad duomenys sutampa, išjungiu senuosius. Svarbu nepamiršti paskyrų prisijungimų: kiekvieną programėlę naujame įrankyje reikės prijungti iš naujo.

Mažai sistemai, turinčiai kelis srautus, perėjimas paprastai užtrunka kelias dienas. Jei srautų dešimtys, verta pereiti etapais, pradedant nuo tų, kurie kainuoja daugiausia užduočių ar kreditų.