If your helpdesk bill keeps climbing, you have three real options: stay on it, switch to a cheaper one, or build customer service automation into your own stack so there's no seat fee to grow into. Each option has a real cost, not just a sticker price. This article works through all three so you can find your own number, not take ours.
We build automation for small and medium sales and marketing teams, mostly in quoting, follow up, reporting, and order and status handling. Support is one workflow out of a dozen we build, not the business. If you're a two or three person support team on a few hundred tickets a month, the honest answer might be to finish this article and keep paying for your helpdesk. The arithmetic below will tell you either way.
What actually breaks when you migrate helpdesks
"Just switch to a cheaper one" is usually the first instinct once a bill gets annoying. Nobody mentions what the switch itself costs.
Macros and canned replies do not transfer between tools. A support lead ends up rebuilding twenty to fifty saved replies by hand, one at a time, in the new tool's editor. Automations, auto tagging, SLA triggers, and routing rules are specific to the tool you're leaving. They get reconfigured from scratch, not imported. Reporting history and dashboards rarely survive the move in a usable form, so a year of trend data is effectively gone. Ticket threading and attachments sometimes import as flat text, which breaks the audit trail on old cases.
Budget two to six weeks of a support lead's time to do this properly. That is real cost, incurred before the new tool has saved a euro. Anyone comparing sticker prices without counting this is comparing the wrong number.
Freshdesk, Zendesk, Gorgias, Help Scout: the billing is the same shape
These are the four names people actually search for once a helpdesk bill starts to hurt. The billing structure is identical across all of them: you pay per agent seat, every month, whatever share of those tickets a routing rule or a macro could have closed without a human touching them.
Gorgias adds usage tiers on top of seats, so cost climbs with order volume as well as headcount. That's two variables working against you instead of one, seats and volume both pushing the bill up at the same time.
Help Scout is the exception worth naming directly. It's cheaper per seat and simpler than the others, and for a small team that mostly needs a shared inbox and nothing more elaborate, it's the right tool. Not every helpdesk here is the wrong answer, and Help Scout at low complexity is often the correct one.
The honest line across all four: switching vendors moves the cost, it doesn't remove it. You'll pay less per seat, or you won't, but you're still paying per seat.
What per-seat and per-resolution pricing cost as you grow
A per-seat helpdesk looks affordable on the pricing page. A typical mid tier plan runs the equivalent of EUR 55 to 85 per agent per month. Add a second agent as volume grows and a third a few months later, and the base cost alone has roughly tripled before any usage tier kicks in.
Some newer tools skip seats and charge per resolved ticket instead, the way Intercom Fin does for tickets its AI closes without a human. That looks cleaner, but the mechanism is the same: cost scales with volume, just measured in tickets instead of agents. At low volume it can beat a seat plan. At four times the ticket count, the bill has scaled roughly four times over, with no ceiling either way.
Worked example, to show the shape of it: a plan starting at EUR 140 a month with one agent, a second agent added at month eight, a third at month sixteen, and one usage tier increase at month twelve, compounds to a running total of roughly EUR 6,000 over 24 months. That's an illustration built from those assumptions, not a quote for your account. Your own numbers will differ.
What a build actually costs, and what owned means
A build works differently. You pay a fixed price once, agreed before work starts, and ticket volume moving from 1,200 to 4,000 a month doesn't change the invoice.
We build it inside your own accounts: your n8n, your Claude account, your Airtable, your Google Workspace, your CRM. A typical customer service automation covers order status lookups pulled straight from your order system, auto drafted responses for the questions that repeat every week, and a handoff to a human for anything that needs judgment, including most of what shows up in returns and refunds.
Owned means something concrete here, not a slogan. You hold the admin logins. The workflow is documented step by step as it's built. If you walk away from us the day after handover, the automation keeps running, because it was never rented from us in the first place.
A worked example, built from the same assumptions as above: a fixed build priced between EUR 8,000 and EUR 14,000, depending on scope, looks more expensive on day one than a EUR 140 a month plan. Run that same cost curve out to month 30 or 36 and it passes the build cost, then keeps climbing every month after with no ceiling. That crossover month is what your own numbers will tell you, not this example.
The crossover: where renting stops winning
Here's the arithmetic to find your own line, not our verdict on where it sits.
Take your current monthly cost across every seat and every add on, and your ticket volume's growth rate over the last two quarters. Seat cost grows in steps, one jump each time you add an agent or cross a usage tier. A build's cost is fixed the day it's signed off. Plot your seat cost forward on that step pattern and find the month it permanently passes your build quote. Everything after that month is money the build would have kept.
Below roughly 1,000 to 1,500 tickets a month with two or three people handling them, this crossover usually never arrives within a sane planning horizon. The fee stays small, and a build never gets the chance to amortize. That's not a close call, it's just math, and it means the honest recommendation for a lot of small teams is to keep the helpdesk they have.
Past that volume, the per seat and per resolution charges compound faster than a fixed price does, because your bill keeps stepping up while the build's number never moves again.
No-code workflow builders vs a build in your own accounts
Between "buy a helpdesk" and "build a system" sits a middle option: stitching your helpdesk, your order system, and your shipping tool together with Zapier or Make.
That solves a real problem at low complexity. One rule, flag orders over a set amount for manual review, works fine as a five minute automation. But Zapier and Make bill per task run or per active user, so at real ticket volume the pricing scales the same way seats do. They also get fragile at multi step logic, conditional routing across four systems with retries and error handling, in a builder designed for simple triggers.
This is why we build in n8n instead. It runs in your own account, on infrastructure you control, not a metered task runner charging you per run as volume grows.
Hiring an ops person vs building the automation
The other alternative to any of this is headcount: hire someone to handle the queue manually, with tools bolted on as needed. A loaded hire for an ops or senior support role, salary plus benefits plus overhead, commonly runs the equivalent of EUR 4,200 to 6,500 a month once fully ramped.
As a worked example: a EUR 11,000 fixed build pays for itself against that hire in under three months, and the automation doesn't take vacation or need a raise when ticket volume doubles. That's not an argument against hiring. It's an argument for handling the repetitive half of the job with customer service automation first, so the person you do hire is doing judgment work instead of answering "where's my order" for the two hundredth time that month.
Building customer service automation without per seat pricing
Two numbers get you most of the way to your own answer: your current ticket volume and its growth rate, and your current cost across every seat and add on. Plot those forward 24 months against a fixed price quote, the way the worked examples above do, and you'll find your own crossover month, if you have one at all.
That's exactly what a Revenue Roadmap works out, not just for support. Two weeks, EUR 1,997, refunded in full if it doesn't find at least 20 hours a month worth automating across your sales and marketing work, support included. If it does, the fee is credited in full against your first build. Every automation after that is quoted at a fixed price before work starts, so there's no invoice you haven't already agreed to. No retainer, no subscription and no platform to rent, and a 12 month warranty on defects in anything we build. The tools and data the system runs on carry their own running costs, itemised in the Roadmap before you commit. Full detail is on the pricing page.
Support sits next to inbound triage and ten other workflows on that Roadmap. If your ticket volume is one symptom among several, the Roadmap scores all of them against each other, not support in isolation.
Common questions
How long does a build take?
The Roadmap itself is two weeks. After that, each automation is scoped and quoted before work starts, and a typical support build ships in a few weeks once the scope is agreed, because it replaces a specific set of manual steps rather than a whole helpdesk.
Do we still need any software after the build?
Yes, the same tools you already use. The automation runs inside your n8n, your Airtable, your CRM, and Claude. There's no new per-seat bill because there's no new tool to pay seats on.
What if our ticket volume drops after we build?
The price doesn't move. It was fixed and paid once, not a per-ticket or per-agent charge that would have scaled down with you but also up against you.
Is a build only worth it at high ticket volume?
It's worth it once your seat or resolution cost is on track to permanently pass the fixed build price within a sane planning horizon, which the arithmetic above shows how to check for your own numbers. Under that crossover, a rented helpdesk is still the right call.
Start with the Revenue Roadmap
Two weeks, EUR 1,997, money back if it does not find at least 20 hours a month worth automating. The fee comes off your first build.
