It looks like you’re from {country}
Automation
Zapier lets apps talk to each other without code: a form fill becomes a CRM contact, a new order triggers an invoice. For that kind of simple one-way flow it is often enough.
It stops being enough when money, tax, refunds or duplicate customer records matter. Then you need a clear setup: which automations stay, which move to a proper link, and how you notice when one has stopped working.
Zapier connects your tools with “if this happens, then do that”: a new webshop order, a deal that moves in HubSpot, a payment in Stripe. That is quick to set up and often perfect for marketing and day-to-day office work.
The limits are predictable. Complex rules (“paid, not refunded, and this tax code”) get messy. Errors often land as an email nobody reads. At higher volumes it gets expensive. And without one clear “owner” for the customer record, several automations can create the same contact three times.
Tools like Make do a similar job with more branching; Zapier wins on how many apps it supports. We do not push one over the other. The real question is: does this flow belong in a no-code tool, or in a maintained link with logging and alerts when something fails?
Zapier did not “fail”. The business grew past a tool that was never meant to be the whole backbone.
After a plugin update the automation fails, turns itself off, and the error mail disappears in a shared inbox. Orders still come into the shop; they just stop reaching your books. Finance finds thirty orders without invoices.
What you see instead
Important flows get monitoring and alerts. Fragile steps move to a proper link that retries and reports when something fails — not only a silent email.
Marketing, sales and the shop each added their own automation. None agreed on which email field wins. Within months, merging duplicates is weekly work and “new customers” means three different numbers.
What you see instead
One system owns the contact. Automations write to it or read from it — they do not invent parallel copies. We document what belongs where and remove overlaps.
Creating an invoice when Stripe says “paid” is easy. A refund weeks later needs a credit note, fee correction and maybe a CRM update — steps that rarely stay correct as stacked automations.
What you see instead
The full payment path — paid, failed, refunded, disputed — lives in one clear layer, whether that is custom work or a small, well-bounded set of automations with explicit rules.
Usage fees add up when every order fires several automations. That is not a reason to ban Zapier — it is a reason to know when to stop stacking more.
The bigger cost is time: merging duplicate contacts, fixing month-end gaps, and not trusting dashboards because nobody knows if the data is complete.
We often start by mapping what you already have in Zapier — half the work is removing automations that fight each other, not adding new ones.
A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.
The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.
WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.
WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.
When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.
These are the flows clients most often ask us to either fix in Zapier or move out of it.
Form and shop leads into CRM (both ways)
New contact, source tag, initial deal or lifecycle stage — with deduplication on email or external ID so the fifth form submission does not create the fifth record.
Paid orders into accounting (into the tool)
Customer, invoice lines, tax and payment status into QuickBooks or another ledger — usually the first Zap clients build and the first one we move to code when refunds appear.
Notifications and tasks in Slack or email (out of the tool)
High-value order alerts, failed payment warnings, support handoffs — flows that belong in Zapier because speed matters more than ledger accuracy.
Stripe and payment provider events (both ways)
Webhooks normalised before they hit business logic — so the same payment.succeeded event updates the shop, CRM and books without three Zaps interpreting the payload differently.
Keep the notification Zaps. Question the money Zaps. Replace anything that has to be correct at month end with something that logs failures the same day.
The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.
Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.
A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.
Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.
Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.
This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.
A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.
Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.
APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.
Auditing and fixing an existing Zapier setup is a real project — often smaller than rebuilding everything in code, and often the right first step before anyone commits to custom API work.
A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.
What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.
Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.
Zapier when the flow is simple, volume is moderate, and failure is annoying rather than expensive — a lead alert, a Slack message, a tag on a contact.
Custom work when money moves, tax must be right, duplicates break reporting, or you need to know the same day that something failed. We tell you which side your flow is on before quoting either.
Because the subscription buys connectors, not design. Five Zaps built by five people over two years is a common starting point — and the work is deciding which to keep, how they share IDs, and what happens when one breaks.
Good integration work often reduces Zapier spend by replacing the expensive task-heavy Zaps with one maintained code path. The fee is for the architecture, not for clicking together steps you could have clicked yourself.
Yes — that is a frequent entry point. We export what exists, map triggers to business outcomes, and flag Zaps that overlap or lack error handling.
We do not automatically rewrite everything in code. Sometimes the fix is three documentation pages and an alert on task failures; sometimes it is retiring half the Zaps and building one payment handler. The audit decides.
Make offers more branching and often better pricing at volume; Zapier offers more apps and more people on your team who have heard of it. For many clients the answer is "use whichever you already pay for until it breaks."
When we recommend switching, it is usually because the visual scenario in Make expresses a flow Zapier cannot without hacks — not because one logo is universally better.
Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.
