Make vs Zapier: ceny a automatizace pro malé firmy v roce 2026

Tisíc nových poptávek měsíčně vychází v modelu níže na 5 000 kreditů v Make a 4 000 úloh v Zapieru. Každou poptávku totiž nejprve hledáte v CRM, potom založíte kontakt, odešlete potvrzení a upozorníte obchodníka. Počítá se každý účtovaný krok.

Pro jednoduché předávání dat bych dal Zapier do užšího výběru, pokud má připravené požadované akce. U větvených postupů a Fakturoidu bych začal s Make: jeho dokumentace uvádí vyhledávání kontaktů i vytvoření faktury a propojení potvrzuje také katalog Fakturoidu. Před zavedením obou služeb bych určil správce, který bude řešit chyby.

Vycházím z dokumentace a ceníků ověřených 15. 10. 2026. Nástroje jsem pro toto srovnání provozně netestoval, takže nemám změřenou dobu sestavení ani chování při výpadku. U každého výpočtu uvádím předpoklady. Vaše zapojení může spotřebovat jiný počet jednotek, třeba kvůli opakování nebo dalšímu vyhledávání.

Make, nebo Zapier? Začněte konkrétním přenosem dat

Vybírejte podle toho, co potřebujete v cílové aplikaci udělat. U fakturace to může být vyhledání odběratele a vystavení faktury. Samotný počet aplikací v katalogu za mě o výběru nerozhoduje. Logo fakturačního programu nestačí. Ověřte oba požadované kroky.

Dokumentace Make pro Fakturoid uvádí moduly Search Contacts a Create an Invoice, tedy vyhledání kontaktů a vytvoření faktury. U Pipedrive potvrzuje tržiště integraci od Zapier, Inc., včetně zakládání obchodů z formulářů. Podle těchto údajů už můžete sestavit návrh přenosu. Ještě však musíte rozhodnout, co dělat s chybějícími údaji nebo s odběratelem, kterého evidence nezná.

Majitele firmy bych se nejprve zeptal: co přesně dnes přepisujete? „Potřebuji automatizaci“ je pro výběr tarifu málo. „Po přijetí poptávky potřebuji založit obchod a přiřadit obchodníka“ už popisuje práci, kterou lze rozdělit na jednotlivé akce a spočítat.

Pokud teprve vybíráte cílovou evidenci, začněte průvodcem výběrem CRM systému. Jestli potřebujete hlavně hlídat úkoly a termíny lidí, pomůže spíše srovnání projektových nástrojů. Před propojením si ujasněte, kde budete evidovat zákazníky a kde práci kolegů. Jinak budete automaticky přenášet i nepořádek, který dnes řešíte ručně.

Jak se liší scénář v Make a Zap v Zapieru?

Make skládá proces z modulů na vizuálním plátně. Zapier označuje automatický postup jako Zap a rozlišuje spouštěč a navazující akce. Spouštěč, anglicky trigger, je například přijetí formuláře. Akce potom zapíše kontakt do CRM. Celému postupu se také říká workflow.

Make Academy popisuje Router, který rozděluje postup do větví, a jednorázové spuštění Run once. Větvení se hodí třeba pro oddělení nového a stávajícího odběratele. Každý může potřebovat jiný postup: u jednoho kontakt vytvoříte, u druhého použijete už uložené údaje.

Zapier Formatter upravuje podobu dat před jejich předáním. Například rozdělí jméno nebo převede datum do formátu cílové aplikace. Podle dokumentace kroky Formatteru nespotřebovávají úlohy. Při počítání ceny je tedy odlište od běžných placených akcí.

U větveného procesu bych dal přednost plátnu Make, protože na něm chci vidět jednotlivé cesty vedle sebe. Je to moje preference při čtení návrhu; rychlost práce jsem neměřil. Rozsáhlé schéma může být stejně nepřehledné jako dlouhý seznam kroků. Při předání kolegovi bych ho nechal vlastními slovy vysvětlit, co se stane s neúplnou objednávkou a kudy projde existující zákazník.

I bez programování vás čeká mapování: určíte, které pole ze zdroje patří do kterého pole v cíli. Když přenesete fakturační adresu do doručovací, vizuální editor vás sám nezachrání. U prvního propojení bych rozsah zúžil na přenos, kterému správce rozumí a dokáže ho zkontrolovat. Další větev může počkat.

Kolik stojí Make a Zapier v roce 2026?

Vstupní placený tarif Make vychází levněji. Jeho kredity ale počítají jinou spotřebu než úlohy Zapieru, takže samotnou cenu balíčku nelze použít jako cenu stejné práce.

Tabulka zachycuje vybrané balíčky podle interaktivního ceníku Make a ceníku Zapieru, otevřených 15. 10. 2026. Kódy používám dále u modelových výpočtů. Dodavatelé své tarify takto nepojmenovávají.

Všechny placené částky jsou v USD, bez DPH, za měsíc při roční platbě předem. Poslední sloupec ukazuje náklad na celý rok. Ceny nezahrnují cílové aplikace, konektory ani práci správce. Zapier nezahrnutí daně výslovně potvrzuje v nápovědě k daním; Make rozlišuje předplatné a daně v článku 5.1 smluvních podmínek.

Roční režim vstupního Professional potvrzuje i vysvětlení cen od Zapieru. Chcete platit každý měsíc? Přepněte platební režim v ceníku. Částku uvedenou jako měsíční ekvivalent ročního předplatného zaplatíte v rámci ročního závazku, nikoli formou samostatných měsíčních faktur bez závazku.

Ceny ponechávám v původní měně. Náklad v korunách si přepočítejte kurzem své platby; jednorázový kurz banky by do srovnání přidal další proměnnou.

Při nákupu bych si uložil vybraný příděl jednotek a platební režim spolu s výslednou objednávkou. Pod stejným názvem tarifu totiž najdete různé objemy. A pokud na účtu už běží jiná automatizace, část kapacity spotřebuje ona.

Počítejte celý účet. Rozpočet jedné nové automatizace vám nestačí, pokud se o příděl dělí s dalšími procesy.

Proč kredit není totéž co úloha?

Make u běžných aplikací bez AI účtuje jeden kredit za jednu operaci. Zapier u běžné úspěšné akce počítá jednu úlohu a spouštěč neúčtuje. Pravidla popisují Make Credits a nápověda Zapieru k úlohám. Výpočty v článku nepoužívají AI ani vlastní kód, pro které mohou platit jiné sazby.

Operace v Make znamená běh modulu při zpracování nebo kontrole dat. U navazujících modulů záleží na počtu předaných záznamů. Jeden kontakt představuje jeden záznam; deset kontaktů může vyvolat deset samostatných zápisů. Dokumentace operací také vysvětluje, že kontrolní spouštěč účtuje provedenou kontrolu, nikoli každý záznam, který při ní najde.

Polling znamená pravidelné dotazování, zda přibylo něco nového. Modelová kontrola každou čtvrthodinu po celý třicetidenní měsíc udělá:

4 × 24 × 30 = 2 880 kontrol měsíčně.

V Make tak může dotazování spotřebovávat kredity, i když žádná nová data nepřijdou. Zapier podle své nápovědy polling spouštěče neúčtuje. Pro proces s malým počtem událostí tedy způsob spouštění mění poměr mezi užitečnými přenosy a placenými kontrolami.

Webhook funguje opačně: zdrojová aplikace při události pošle zprávu. Make Custom webhook spustí scénář po přijetí požadavku; Zapier nabízí Catch Hook. Odesílání webhooku ovšem musí podporovat i zdrojová služba. Nejdříve ověřte tuto možnost u ní, teprve potom navrhujte okamžitý přenos.

Před nákupem bych spočítal tentýž postup v obou službách. Zahrnul bych také vyhledávání a kontroly naprázdno, pokud je návrh potřebuje. Nakonec bych nechal rezervu na opakování po chybě. Cena deseti tisíc jednotek sama o sobě neříká, kolik poptávek za ni zpracujete.

Jak spočítat stejnou poptávku v obou nástrojích?

Model formulář → kontrola duplicity → nový kontakt → potvrzovací e-mail → interní zpráva vychází za uvedených předpokladů na pět kreditů v Make a čtyři úlohy v Zapieru. Počítám podle pravidel účtování. Spotřebu jsem neodečítal z testovacího účtu.

Předpokládám webhook s jedinou novou poptávkou. Vyhledávání proběhne úspěšně, ale žádný kontakt nenajde; postup potom založí nový kontakt a odešle dvě samostatné zprávy. Každý krok běží jednou, bez opakování.

Zapier má pro vyhledávání zvláštní pravidlo: při nastavení pokračovat i bez nalezeného výsledku spotřebuje krok úlohu. Uvádí to nápověda k měření spotřeby. Právě toto nastavení používám v modelu.

Jako cílové CRM lze prověřit Pipedrive: Make dokumentuje vyhledávání a tvorbu osob a tržiště Pipedrive potvrzuje propojení se Zapierem. Před spuštěním ověřte nastavení vyhledávání na vzorku vlastních dat. Stejně projděte větev pro kontakt, který už v CRM existuje.

Co se stane v takovém případě? Můžete přeskočit založení kontaktu, nebo místo něj aktualizovat údaje. Každá cesta spotřebuje jiný počet jednotek. V rozpočtu bych chtěl vidět, jaký podíl poptávek přichází od nových lidí a jaký od těch stávajících. Rozhodněte také, zda opakovaná poptávka vyvolá další potvrzení a upozornění obchodníkovi.

Při přejímce bych postupoval takto:

1. Pošlete nový kontakt se všemi povinnými poli a porovnejte zápis v CRM s formulářem.
2. Odešlete tentýž kontakt znovu. Zkontrolujte, zda vznikl další záznam a zda to odpovídá zadání.
3. Vynechte povinné pole. Zjistěte, kde proces skončí a kdo dostane upozornění.
4. Zapište spotřebu každé varianty i čas, který zabralo nalezení chyby. Stopky spusťte také při opravě, nejen při sestavování postupu.

Teprve po těchto zkouškách bych porovnával čas potřebný k zavedení. Rychle sestavený přenos, který nezvládne opakovanou poptávku, zatím není připravený pro provoz.

Kolik stojí objednávky, poptávky a kontakty měsíčně?

U všech modelů v tabulce vychází Make na nižší cenu samotného předplatného. Srovnání platí pro popsané kroky a úspěšné jednotlivé přenosy. Nezahrnuje další práci správce ani náklady cílových aplikací.

Ceny k 15. 10. 2026 a platební režim najdete v předchozí cenové tabulce. Zde přiřazuji vypočtenou spotřebu ke kódu balíčku, aby bylo vidět, do jakého přídělu se každý model vejde.

Objednávka do fakturace

Model přijme objednávku webhookem, vyhledá odběratele a vytvoří fakturu. Odběratel už existuje a fakturu vytvoří jediný požadavek se všemi položkami.

Vyhledávání v Zapieru počítám jako samostatnou účtovanou akci s povoleným pokračováním při nenalezení výsledku. V tomto modelu však odběratele vždy najde. Celkem tak počítám tři kredity v Make a dvě úlohy v Zapieru.

Model končí vytvořením faktury. Nepřidávám vytvoření kontaktu ani odeslání PDF. Nezahrnuji ani zápis čísla faktury zpět do e-shopu; ten by vyžadoval další krok.

Dokumentace konektoru Fakturoid v Make uvádí obě potřebné akce a integraci potvrzuje také Fakturoid. Hotový konektor Fakturoidu pro Zapier se v podkladech doložit nepodařilo. Jeho sloupec proto počítá s vlastním napojením přes API.

API je rozhraní, přes které si aplikace předávají příkazy a data. Zapier takové požadavky podporuje, ale jejich přípravu musíte ocenit zvlášť. V tabulce tedy srovnávám spotřebu popsaného přenosu, nikoli stejně snadno dostupné konektory.

Poptávka do CRM

Používám postup z předchozí sekce: zkontrolovat duplicitu, založit nový kontakt a odeslat dvě zprávy. Každá poptávka přichází od nového člověka, takže založení kontaktu proběhne pokaždé.

Obchodní příležitost ani úkol pro obchodníka model nevytváří. Pokud je potřebujete, přidejte příslušné akce do návrhu a přepočítejte spotřebu. Samotný zápis kontaktu tyto požadavky nepokrývá.

Formulář do e-mailingu

Model přijme webhook a jednou zapíše odběratele do Mailchimpu. Spotřebuje dva kredity v Make a jednu úlohu v Zapieru. Make správu odběratelů uvádí v dokumentaci; Zapier dokumentuje akci Add/Update Subscriber.

Případné potvrzení odběru řeší e-mailingový nástroj. Do spotřeby automatizace zde nezapočítávám odeslání celé kampaně.

Každý řádek předpokládá prázdný účet bez dalších automatizací. I nejmenší formulářový model v Zapieru potřebuje Professional kvůli webhooku, přestože se počtem úloh vejde do přídělu Free.

Make Free podle ceníku připouští nejvýše dva aktivní scénáře. Všechny modely z tabulky na něm tedy současně nespustíte. A formulářový model s 5 000 událostmi v Make vyčerpá celý příděl M10. Nezbude nic na opakování ani na další přenos. Takto těsný rozpočet bych pro ostrý provoz nevolil.

U tisíce nových poptávek měsíčně činí roční náklad předplatného 108 USD u Make a 1 068 USD u Zapieru (bez DPH, při roční platbě předem, podle ceníků k 15. 10. 2026). Rozdíl je 960 USD za rok. Pro celkový rozpočet ještě připočtěte správu: pokud jedno zapojení vyžaduje více placené práce, část této úspory spotřebuje.

Tarify fakturace ani e-mailingu zde neporovnávám. Pro jejich výběr slouží přehled fakturačních programů a srovnání e-mailingových nástrojů. Předplatné automatizační služby je další položka vedle nich.

Co propojíte se Shoptetem, WooCommerce, Upgates a Shopify?

WooCommerce a Shopify mají dokumentovaná propojení. U Shoptetu ověřujte konkrétní doplněk; pro Upgates mám v podkladech doloženou cestu přes API a webhooky.

U každého propojení si napište, co přesně přenáší. Z podpory objednávek nelze dovodit obousměrnou synchronizaci. Faktury nebo skladové zásoby mohou vyžadovat jiné akce a samostatný návrh.

U Shoptetu vycházím z popisu doplňku Kontaktní formuláře. Ten dokládá přenos odpovědí formuláře. Přenos objednávek z něj neodvozuji.

Pro běžnou fakturaci existuje také přímý externí doplněk Fakturoid by Kulhánek. Podle Fakturoidu vytváří faktury a přenáší registrované zákazníky i informace o zaplacení. Platí se samostatně. Jestli potřebujete pouze tuto práci, nejprve bych prověřil právě přímé napojení. Získáte další možnost, kterou můžete porovnat s cenou a správou vlastního postupu.

U WooCommerce Make popisuje klíče REST API, tedy údaje potřebné pro přístup k rozhraní obchodu. Dokumentace pluginové integrace Zapieru rozlišuje Order created a Order paid. První událost zahrnuje i nezaplacené objednávky. Při návrhu fakturace proto určete, zda má postup začít vytvořením objednávky, nebo až jejím zaplacením.

Upgates uvádí REST API v2 a správu webhooků pouze přes API. To bych bez technického správce nesliboval jako snadné naklikání. Přesné náklady doplňků a přístupu k rozhraní se v podkladech nepodařilo ověřit pro obě služby. Do uvedených modelů je proto nezahrnuji; před objednáním si na ně vyžádejte cenu pro svůj účet a požadovaný přenos.

Shopify podporuje dokumentace Make a katalog Zapieru. Před spuštěním přesto sepište směr každého přenosu. Chcete měnit skladové údaje v e-shopu podle skladového systému, nebo naopak? Určete, který systém má poslední slovo. Jinak při synchronizaci můžete aktuální údaje přepsat starší kopií.

Je Make česky a co říkají uživatelé?

Make Academy uvádí češtinu a angličtinu. Zapier podle vlastní nápovědy nabízí aplikaci i centrum nápovědy pouze anglicky. Zdrojem jsou lekce Make Academy a jazyková nápověda Zapieru.

České rozhraní Make samo o sobě nepotvrzuje českou podporu. Nepočítal bych ani s tím, že přeloží každou chybu, kterou vrátí připojená aplikace. Při předání kolegům proto ověřte také to, zda rozumějí hlášení při neúspěšném přenosu.

Na Capterře měl Make při kontrole 15. 10. 2026 hodnocení 4,8/5 ze 409 recenzí. Zapier měl 4,7/5 z 3 082 recenzí. Obě otevřené stránky uváděly aktualizaci 29. 9. 2026. Podle rozdílu desetiny bodu bych nevybíral: vzorky mají různou velikost a uživatelé hodnotí různá zapojení.

V otevřených recenzích Make uživatelé chválí nabídku integrací a vizuální sestavování postupů. Současně popisují náročnější hledání správných modulů a opravy chyb. Matyas Z. v recenzi ze 4. 8. 2026 zmiňuje pracné nastavování a složité chyby; Marvin A. připomíná čas potřebný k pochopení a správě postupů. Popisují vlastní zkušenosti. Já jsem tyto problémy při provozním testu neměřil.

U Zapieru se opakuje pochvala předávání dat bez vlastního programování, ale také výhrady k rostoucí ceně a ladění složitějších postupů. Daphnie C. v recenzi z 10. 8. 2026 zmiňuje obě stránky. Její zkušenost bych použil při přípravě zkoušek a rozpočtu. Spolehlivost vašeho zapojení musí ukázat přejímka.

Český správce může kolegům pomoci s jazykem u obou služeb. Předem bych se domluvil, zda jeho cena zahrnuje vysvětlení postupu a dokumentaci. Zvlášť bych vyjasnil, kdo zaplatí opravu po změně připojené aplikace. Přeložené tlačítko pomůže s orientací; důvod, proč se faktura nevytvořila, musí správce umět dohledat.

Co se stane při chybě a jak předat správu?

Make umí ukládat nedokončené běhy. Zapier nabízí opakování neúspěšných kroků. U obou si předem ověřte nastavení, protože výchozí chování nemusí odpovídat tomu, co od přenosu očekáváte.

Make výslovně uvádí, že ukládání nedokončených běhů je ve výchozím stavu vypnuté. Zapier Autoreplay je dostupné od Professional a zkouší neúspěšný krok opakovat až pětkrát. E-mail o chybě při něm odchází až po posledním neúspěšném pokusu. Pokud čekáte upozornění hned při prvním selhání, zahrňte to do zadání a ověřte při zkoušce.

Při přejímce bych chtěl vidět vyvolanou chybu i její opravu. Jedna správně přenesená poptávka ukáže jen úspěšnou cestu. U nedostupného CRM ověřte, kde zůstanou data a jak přenos následně dokončíte. U vypršelého přístupu určete, kdo ho obnoví. Make pro obnovu připojení dokumentuje volbu Reauthorize.

Před opakováním zkontrolujte výsledek v cílové aplikaci. Pokud se faktura vytvořila a selhala až interní zpráva, další fakturu nechcete. Do zadání bych proto přidal dohledání dokladu podle původního čísla objednávky a kontrolu, že tentýž obchodní případ nepřibyl podruhé. Provedení musí odpovídat tomu, co cílový systém skutečně umí vyhledat.

Při předání projděte také přístupy. Make upozorňuje, že připojení vytvořená v týmu mohou používat a spravovat členové daného týmu. Zapier u vlastního API napojení rozlišuje uložení přihlašovacích údajů v připojení a přímo v kroku webhooku. U požadavků s přihlášením bych si nechal ukázat, kdo tyto údaje dokáže přečíst a kdo je může změnit.

Provozní předání bych uzavřel dvěma výstupy: stručným popisem přenosu a ukázkou obnovení po chybě. V popisu určete vlastníka i jeho zástupce, příjemce upozornění a místo, kde dohledáte číslo původní objednávky. Zástupce si potom obnovu projde sám. Tím zjistíte, zda se podle předané dokumentace dokáže obejít bez autora zapojení.

Do předávacího protokolu bych zapsal počáteční a konečný stav zkoušky. Uveďte číslo přijaté objednávky a číslo vytvořeného dokladu. Připište, kdo ověřil jeho obsah. Při reklamaci budete mít konkrétní záznamy, které lze porovnat, včetně výsledku v cílové aplikaci.

Zelená značka nestačí. Úspěšný běh sám nepotvrzuje, že faktura obsahuje správné obchodní údaje.

Osobní údaje řešte podle polí, která přenášíte, a lidí, kteří k nim mají přístup. Do interního upozornění bych neposílal celou zákaznickou kartu, pokud obchodníkovi stačí odkaz na záznam. Právní soulad konkrétního zapojení zde neposuzuji. Účel přenosu a oprávnění příjemce musí firma vyřešit i při použití hotového konektoru.

Kdy se automatizace vyplatí a kdy bych ji odložil?

Automatizaci bych schválil, pokud úspora práce pokryje její zavedení a provoz a firma zvládne přenos obnovit po chybě. Do nákladů počítejte předplatné i pravidelnou správu.

Make pro obnovu nabízí uložené nedokončené běhy, Zapier má Autoreplay. Jejich nastavení a kontrolu bych svěřil konkrétnímu člověku. V rozpočtu potřebujete čas na tuto práci stejně jako peníze na tarif.

Návratnost si můžete přepočítat bez odhadu tržní ceny implementace. Pro následující příklad předpokládám tisíc přenosů měsíčně, každý dnes zabere minutu. Interní cenu práce volím 300 Kč za hodinu a na správu vyhrazuji dvě hodiny měsíčně. Jde o modelové předpoklady, nikoli o zjištěné sazby dodavatelů nebo výsledek vlastního měření.

1. Spočítejte čas ruční práce: 1 000 × 1 minuta ÷ 60 = přibližně 16,67 hodiny měsíčně.
2. Přepočítejte ho zvolenou cenou práce: 1 000 ÷ 60 × 300 = 5 000 Kč měsíčně.
3. Odečtěte správu: 2 × 300 = 600 Kč měsíčně. Zbývá 4 400 Kč měsíčně před cenou softwaru a zavedení.
4. Odečtěte skutečné předplatné převedené kurzem své platby a další doplňky. U dvanáctiměsíčního horizontu připočtěte také jednu dvanáctinu ceny realizace za měsíc.

To už lze přepočítat.

Když ruční přenos zabere jen desetinu předpokládaného času, tedy šest sekund, jeho měsíční hodnota v témže modelu klesne na 500 Kč. Dvě hodiny správy stojí 600 Kč. Výsledek je minus 100 Kč ještě před předplatným a zavedením. U takového přenosu bych nejprve hledal, zda má automatizace další přínos, který firma dokáže doložit.

Odložil bych také proces, jehož pravidla každý týden měníte. Nejdříve sjednoťte vstupy a určete požadovaný výsledek. Jinak budete platit za úpravy postupu dříve, než si ověříte jeho běžný provoz.

Před výběrem bych si nechal doložit potřebné akce konektoru a spotřebu celého postupu. Se správcem bych pak prošel cenu jeho práce i rozsah předání. Pokud vás omezuje jiný požadavek, navazuje přehled alternativ k Zapieru. Podrobnosti o n8n najdete v tomto navazujícím výběru; zde zůstávám u Make a Zapieru.

Před roční platbou si nechte projít vlastní objednávku i její opakované odeslání. Uložte si spotřebu a postup opravy. Napište mi, který přenos řešíte a na jaké výjimce se zadrhl. Podle konkrétního problému se dá vhodnost nástroje posoudit lépe než podle počtu log v katalogu.