Pricing an n8n voice agent automation… how to calculate costs?

Questions
1

Hi everyone,

I’m looking for advice on how to price an automation I’ve built for a client

The setup: a voice agent (ElevenLabs) connects to an n8n workflow that handles call context, checks calendar availability, and books or reschedules appointments based on availability

My main challenge is that call volume is unpredictable, there’s no fixed number of calls per month. How do you typically approach quoting in such cases? Do you base your pricing on estimated monthly call volume and charge per call, or do you use a different model?

I’d really appreciate any insights or best practices you can share. Thanks

2

Hey @Maxwell45, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Entrepositive, @Gallo_AIA, @Niffzy - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Split the price: a fixed monthly platform fee plus a per-call rate, because your own costs split the same way.

Your variable floor is ElevenLabs conversational minutes plus the LLM tokens per call. Measure it before quoting: add a Set node at the end of the call flow that writes duration_seconds, and reconcile against the ElevenLabs usage page. Ten real calls gives a cost per call good enough to mark up.

The fixed part covers the parts volume does not change: workflow maintenance, calendar edge cases, and the error path.

Two n8n details that decide whether per-call billing survives contact with reality. Turn on “Save successful production executions” in the workflow settings, otherwise you have no record to invoice from. And put a Merge node with mode “Combine” plus an IF on the booking branch, so a caller who hangs up mid-slot-check does not get counted or double booked.

Sell a band, not a number. Up to 300 calls included, overage per call above it. Predictable for them, no downside for you.

4

Hey @Maxwell45,your n8n floor isn’t one execution per call. A webhook counts one execution for every inbound request, so each tool round trip the agent makes during a conversation bills on its own: context, then availability, then booking is three, not one. Pull your execution count for a known period and divide by actual calls before you quote anything.

If that ratio looks bad, collapse the tools rather than the workflow. One tool that checks availability and books in a single round trip costs one execution where two separate tools cost two. Splitting the logic into sub-workflows is free either way, since only the parent execution counts towards quota.

5

price the platform not the call. fixed monthly covers build + maintenance, per call fee on top for usage. the trap is pricing only per call, one quiet month and you eat the dev time. i take the monthly run cost (elevenlabs + n8n + your time) as the base, everything above that is profit. clients like it too bc the base is predictable

6

The pure per-call rate can usually cause friction with unpredictable volume use cases like this. The client will either feel nickel and dimed in busy months or you can eat the cost in the slow ones. Using a hybrid model will tend to work better. Use a base monthly fee that covers infrastructure, maintenance and a set volume tier and then an overage rate for each call beyond that. You can have the predictable minimum cost while still scaling the actual usage.

You should also price in the value delivered rather than just the call volume. For some agencies they charge a flat retainer in addition to a small fee for booking. Since not every call ends in a booking it makes sense to not charge by call.

What you should do first is track your ElevenLabs and n8n execution costs for a month or so before you lock in on the numbers. This will tell you what the real cost floor per call is so you’re not guessing at margins.

7

Hi, @Maxwell45

I wouldn’t suggest you charging only on per-call basis as the call volume is not fixed. If there are few calls in a particular month, you may not even recover the time and effort you have made in building the automation.

What I normally feel is better is to keep the things in parts like one-time development and setup cost, fixed monthly maintenance/support charge, actual usage cost for n8n executions and other APIs.

You can include a certain number of calling minutes in the monthly plan and charge extra if the usage crosses that limit. This will also give the client some clarity about the expected monthly bill.

Also, clearly define what is included in maintenance. Small fixes and monitoring can be covered in the monthly fee, but any new feature or major workflow change should be charged separately.

I think this is safer for both sides as the client gets expected pricing and you are not depending with only the number of calls. I think this might be helpful for you.

8

Hi @Maxwell45 ,

The best pricing model for unpredictable AI voice volume is a hybrid setup:

  1. Upfront Setup Fee: Covers the initial workflow build, prompt tuning, and calendar integration.
  2. Minute-Based Retainer: Charge based on total call minutes (e.g. 200 minutes included + overage rate) rather than call count, as a 30-second call costs far less than a 5-minute call.
  3. Client API Pass-Through (Risk-Free): Have the client connect their own ElevenLabs and OpenAI API keys so they pay raw API usage directly. You simply charge a flat monthly fee for n8n workflow maintenance and support.

Pass-through billing completely removes financial risk when call volume fluctuates.

9

The hard part to answer without real numbers is the variable floor, so here is mine from a Vapi + n8n booking agent that’s currently running. These are off the dashboard, not estimates:

Vapi platform: ~$0.05/min

STT (Soniox RT v5): $0.004/min

LLM (GPT-4o): $0.022/min

TTS (Vapi voice): $0.02/min

Telephony (Twilio inbound): ~$0.0085/min

That lands around $0.10/min all in. A three-minute booking call is roughly $0.30, so 300 calls a month at a three-minute average is about 900 minutes - call it $90/month in pass-through cost.

Swap in ElevenLabs and the TTS line goes up. Move to a cheaper model and the LLM line drops. But the shape holds, and notice the platform fee is about half the total. That’s the bit people miss when they price off model costs alone.

Three things that caught me out and are worth pricing for:

Band on minutes, not calls. Cost tracks duration, not call count. A caller who rambles for eight minutes costs nearly three times one who books in three, so “300 calls included” quietly exposes you to that. Either band on minutes, or set a max call duration in the assistant config.

Abandoned calls still cost you. Someone who rings and hangs up after twenty seconds still burns platform and telephony minutes. On an inbound receptionist that can be a real share of traffic, so it’s worth sampling before you commit to a number.

Tool latency is a line item, not just a UX problem. If a calendar lookup takes four seconds and the agent covers it with “let me just check that for you”, you are paying for those seconds on every call that books. Getting a slow tool call from four seconds down to one is a genuine cost reduction across a month, not only a nicer conversation.

Agreed on measuring before quoting - ten real calls gets you close. Just make sure a few of them are the messy ones. The clean happy-path call is the cheapest one you will ever have.

10

I think the dangerous part is calculating only the normal call.

A clean 2 or 3 minute call is probably the cheapest scenario you will have. In real usage you can have longer calls, retries, multiple tool calls, calendar requests, failed bookings etc.

Before giving the client a fixed price I would calculate a few scenarios: normal usage, high usage and a bad month. Then make sure even the bad one doesn’t destroy your margin.

For this kind of workflow I would probably separate the client price from the actual API costs too.

11

Although platform/STT/TTS/Twilio costs scale with minutes, the LLM line doesn’t. It scales with how many tool steps the agent takes during the call, and every step re-sends the conversation so far, so a reschedule with two availability checks and a failed booking could cost more in model calls than its extra minutes suggest.

I have a free simulation tool that you can use to cost out the LLM calls. On OpenAI, for a planner call plus say 3 to 9 tool steps for context, availability and booking (you can tweak the assumptions), the model calls come to about $0.06 per call at the median, with 80% of 2,000 simulated runs between $0.05 and $0.08. You can also switch models in the tool to see what it would cost on Anthropic, Gemini or DeepSeek.

Two things push that line up in a bad month that a per-minute band won’t show. A calendar lookup that times out and retries bills its input again, roughly $0.008 an attempt on this shape. And an agent that keeps re-checking availability grows with the square of the step count because of the re-sent context. You could set max iterations and a spend cap to limit your exposure.

The tool is at How much does an AI agent cost per month?. It’s the model calls only, on your own key. The voice minutes aren’t on it, so it covers one of your five lines, not the total.

12

If volume is unpredictable, don’t quote a flat monthly number, you’ll either eat the cost or overcharge them most months. Two models that actually hold up:

  1. Base + usage. Flat fee covers the build, hosting, and a set number of calls/minutes (say 200 calls or X ElevenLabs minutes), then per-call or per-minute overage above that. This protects you when volume spikes and gives the client a predictable floor.

  2. Straight per-call/per-minute with a minimum monthly commitment. No base fee, just a minimum they pay whether they use it or not, plus usage above that. Simpler to explain but harder to sell since it feels like a metered utility bill.

Either way, you need to know your actual cost per call before you price anything. ElevenLabs charges per character/minute, n8n execution has a cost if you’re on cloud, calendar API calls are usually free but check quotas. Add those up per call, that’s your floor. Price meaningfully above it, not 10-20%, because failed calls, retries, and debugging time aren’t in that number.

Also track cost per call type separately if you can, a quick reschedule costs way less in TTS minutes than a long qualifying conversation. Blending them into one average price per call works until someone starts using it heavily for the expensive kind.

Last thing: build in a review point after the first month or two to adjust the base/included volume once you have real usage data instead of guessing upfront.

13

Coming at this from the sales side rather than the engineering side.

Two things I’d separate that often get quoted as one number:

BUILD is a one-off. Scope it, price it, done.

MAINTENANCE is not optional and should be quoted separately, monthly. Data
sources change their layout, APIs deprecate endpoints, a provider changes a
response format. When that happens the workflow doesn’t error loudly — it just
quietly stops producing anything useful, and often nobody notices for weeks.
Someone has to be watching. That’s a real cost and it should be a real line
item.

On the build number itself: I stopped estimating from my own hours and started
estimating from what the client currently spends on the task. If a process
eats half a day every week, that’s roughly 26 days a year of someone’s time.
A build priced at a fraction of that is an easy conversation. A build priced
by my hours is an argument about my hourly rate.

Same work, completely different conversation.

One caveat: this only works if you can name the current cost specifically.
“It saves you time” is not a number. “Your team spends 4.5 hours on this every
cycle” is.