Make és Zapier: az üres polling 43 200 kreditet is vihet

Ritka események és gyakori ellenőrzés mellett a Zapier lehet kedvezőbb választás; sok végrehajtott lépésnél a Make. A különbséget nem a csomagok indulóára, hanem az dönti el, hogy ugyanaz a folyamat hány ellenőrzést és hány tényleges műveletet végez. A Make ütemezési útmutatójának triggerelszámolása alapján egy percenként futó lekérdezés 30 nap alatt 43 200 kreditet használhat el akkor is, ha nem talál új adatot.

Ugyanennél a ritkán új adatot találó folyamatnál a Zapier ellenőrzései nem növelik a feladatszámot: a Zapier feladatelszámolása a sikeresen lefutott műveleti lépéseket számolja, az indító lépést és az üres pollingot nem. Ezért a két platformhoz külön kell kiszámítani a havi terhelést, majd megnézni, melyik csomag és alkalmazáskapcsolat tudja megvalósítani a szükséges folyamatot.

Mi fogyaszt kreditet, és mi számít feladatnak?

A Make-ben a modulok által végzett műveletek fogyasztanak kreditet. A Make csomagoldalán az ingyenes keret havi 1000 kredit, a 10 000 kredites Core csomag feltüntetett ára havi 12 dollár havi fizetéssel; a fizetős csomagban a percenkénti ütemezés is elérhető. A legtöbb szokásos modulművelet egy kredit, de egyes fejlett funkciók többet használhatnak. A router önmagában nem fogyaszt kreditet, az ágain ténylegesen végrehajtott modulok viszont igen.

A Zapier csomagoldala havi 100 feladatot ad ingyen, legfeljebb egy indítóból és egy műveletből álló Zaphez; a több lépéses folyamatokat kínáló Professional indulóára havi 19,99 dollár éves fizetés mellett. Az ingyenes csomag pollingja 15 percenként, a Professionalé leggyakrabban kétpercenként, a Teamé percenként futhat. A két feltüntetett fizetős indulóár eltérő fizetési időszakhoz tartozik, a Professional tényleges díját pedig a választott feladatkeret is meghatározza. Magyar vállalkozásnál a dollárban megadott díj forintértéke és az adózási kezelés további tényező.

A számolásnál az adott automatizálás tényleges lépései számítanak. A Zapierben a sikeres műveletek feladatok, de a feltételek és útvonalak nem azok; a Make-ben a trigger feldolgozása mellett a végrehajtott műveleti modulokat is figyelembe kell venni. A következő példák egyszerű, egykredites Make-modulokat és ugyanannyi érdemi műveletet feltételeznek mindkét oldalon. Keresés, ismétlés, hibakezelés vagy MI-funkció hozzáadásakor a fogyasztást az új lépések szerint kell módosítani.

Három feltételes kisvállalati folyamat

Az összevetés minden esetben 30 napos hónappal, hibamentes futással és eseményenként egy feldolgozott adatelemmel számol. Ezek feltételes folyamatok, nem mért ügyféladatok. A költség mellett azt is megmutatják, hogy az adott fogyasztás belefér-e az ingyenes keretbe, vagy fizetős csomag szükséges hozzá.

Űrlapból CRM-rekord

Egy szolgáltató feltételesen havi 60 kapcsolatfelvételt kap, és mindegyikből egy CRM-rekordot hoz létre. Ha az űrlapszolgáltatás azonnali eseményt küld, a Make-ben 60 triggerfeldolgozás és 60 rekordlétrehozás összesen 120 kredit. A Zapierben a 60 sikeres rekordlétrehozás 60 feladat, mert az indító esemény nem feladat. Mindkét érték az ingyenes keret alatt marad, ha a választott űrlap és CRM a szükséges kapcsolattal az adott csomagban elérhető.

Ebben a rövid folyamatban a csomagdíj egyik oldalon sem dönt. Nagyobb jelentősége van annak, hogy a két alkalmazás között kész, megfelelő indító és rekordlétrehozó művelet áll-e rendelkezésre. Az integrációk teljes katalógusa helyett az adott űrlap és CRM konkrét lehetőségeit érdemes összevetni: egy hiányzó eseményindító megváltoztathatja az egész számítást.

Rendelésfigyelés sok üres ellenőrzéssel

Egy másik feltételes folyamat 15 percenként keres új webáruházi rendelést, de a hónapban csak 20-at talál; minden rendelésnél egy művelet fut le. Ez 30 nap alatt 2880 ellenőrzést jelent. A Make becsült terhelése 2880 triggerellenőrzés és 20 művelet, összesen 2900 kredit, így az ingyenes keret nem elég, a 10 000 kredites Core keret viszont igen. A Zapier ugyanennél a 20 sikeres műveletnél 20 feladatot használna, ami az ingyenes kereten belül marad, ha a szükséges alkalmazás és művelet ott használható.

Ha ugyanezt a Make-folyamatot percenként ütemezik, az ellenőrzések száma 43 200-ra, a becsült teljes fogyasztás 43 220 kreditre emelkedik. Ehhez már a Core alapkerete sem elég. Ez a gyorsabb Make-beállítás nem vethető össze azonos gyakoriságú ingyenes Zapier-beállítással: a Zapier ingyenes csomagja 15 perces pollingot kínál. A példa azt mutatja meg, hogy kevés rendelés mellett a lekérdezés gyakorisága önálló költségtényezővé válhat.

Többágú rendelésfeldolgozás

Végül egy feltételes webáruház havi 300 rendelést kap azonnali indítóval. Közülük 180 rendelés három, további 120 rendelés hat műveleti lépésen halad át. Az elágazás után ténylegesen lefutó lépések száma 180 × 3 + 120 × 6 = 1260. A Zapier becsült fogyasztása 1260 feladat; a Make-ben ehhez hozzáadódik a 300 triggerfeldolgozás, így az eredmény 1560 kredit.

A Make fogyasztása ebben a példában belefér a Core alapkeretébe. A Zapierhez több lépéses folyamatot támogató fizetős csomag és az 1260 feladatra elegendő keret kell; a Professional indulóára önmagában ezért nem a példa teljes árajánlata. A Make itt kedvezőbbnek adódhat, de a pontos különbség a kiválasztott Zapier-feladatszinttől és a fizetési időszaktól függ. Ha valamelyik ág keresést vagy további műveletet végez, az adott ág fogyasztását külön hozzá kell adni.

Mikor fordít a számításon a webhook?

A sűrű ellenőrzés költsége akkor változik meg érdemben, ha az alkalmazás új adat érkezésekor maga tud eseményt küldeni. A Make modulleírása megkülönbözteti az ütemezett polling triggert az azonnali, webhookra épülő indítót: utóbbinál a külső szolgáltatás jelzi az új adatot. Így a rendszeres üres ellenőrzések elmaradhatnak, miközben a beérkező rendelés feldolgozása és a további modulok továbbra is kreditet fogyasztanak.

A webhook elérhetősége az adott alkalmazástól és annak konkrét triggerétől függ. A ritka rendelések példájában egy használható azonnali indító a Make oldalán a sok üres ellenőrzés helyett a tényleges eseményekhez kötné a terhelést. Ha ilyen indító nincs, a polling gyakoriságát a vállalkozás megengedhető késleltetéséhez kell mérni: a rövidebb várakozás több Make-ellenőrzést jelent. Hosszú, többágú folyamatnál viszont elsősorban a valóban lefutó műveleti lépések és a hozzájuk szükséges fizetős keret döntik el a választást.

Olvassa el ezt is: