Capacity & Scale

The short answer: thousands of concurrent calls, tens of thousands of calls per day, hundreds of thousands per month. The platform is designed to scale horizontally. This page covers what those numbers actually look like in practice, the limits at each plan tier, and how to grow without surprises.

Don't pre-optimize for scale. Most accounts run fewer than 100 concurrent calls in production. Even mid-market customers rarely hit 500 simultaneous. If you're not sure what your peak will be — start, measure, scale up later. Plans are easy to upgrade.

Limits at a glance

Per-Finn limits exist because a single Finn = single contact point in your audience's mind. Beyond a few hundred concurrent dials from one identity, you create unrealistic call-volume patterns. Use multiple Finns or number pools to scale beyond the per-Finn limit.

What "concurrent calls" actually means

When the platform says "200 concurrent calls," it means 200 active conversations happening simultaneously. Each call is using a dedicated:

• LLM inference instance (processing the conversation)
• TTS streaming instance (generating voice audio)
• STT instance (transcribing the caller's speech)
• Telephony channel (the actual phone connection)

The platform scales each of these independently. You don't have to think about provisioning — it just works.

How to estimate your peak load

A few back-of-envelope calculations:

Outbound campaigns

peak concurrent calls ≈ (calls per hour) × (avg duration in minutes) / 60

Example: 1,000 calls to make, 2-minute average duration, run over 4 hours = 250 calls/hour × 2/60 = ~8 concurrent peak.

Inbound

peak concurrent calls ≈ (calls per hour at peak time) × (avg duration in minutes) / 60

Example: a clinic receives 30 calls/hour at lunch peak, 4-minute avg duration = 30 × 4/60 = 2 concurrent peak.

Most businesses are surprised by how low their actual concurrent peak is. Even a busy receptionist Finn rarely needs more than 10-20 concurrent.

When parallel deployments push numbers up

Parallel deployments (Enterprise) are different — they explicitly maximize concurrent dialing to complete a large list fast.

Example: 50,000 contacts, 90-second average call, want to complete in 4 hours = 50,000 calls / (4 × 3600/90) = ~313 concurrent average; peaks 2x that = ~625 concurrent.

For parallel deployments, you need both plan capacity AND number-pool capacity. Single numbers can't physically support more than ~50 simultaneous outbound calls (carrier limits).

Number pools and concurrent capacity

For high-concurrency outbound, the limiting factor is usually phone numbers — not platform capacity.

Per-number limits

These are carrier-imposed, not platform-imposed. Exceeding them gets calls rejected by the destination carrier.

Pool sizing rule of thumb

pool size ≈ peak concurrent calls / per-number limit × 1.5 (safety margin)

Example: planning 500 concurrent US outbound calls = 500/50 × 1.5 = 15 numbers in the pool.

Buy more numbers than you think you need. Numbers are cheap ($1-$5/mo); failed calls from undersized pools are expensive (lost answers + brand damage from "this number can't be reached" errors).

Latency and quality at scale

The platform's latency target is <800ms end-of-user-speech to start-of-Finn-response. This holds whether you're running 1 call or 1,000 concurrent calls — the system is designed to scale horizontally, not just throughput but per-call quality.

What can degrade quality at scale:

Rate limits

Beyond concurrent-call limits, the platform enforces request-rate limits on:

Rate-limited responses return 429 Too Many Requests with a Retry-After header indicating when to retry.

Multi-region and data residency

For latency-sensitive use cases or compliance requirements, you can pick which region your account runs in.

Choose region at account creation. Cannot be changed later without data migration. If you're targeting EU customers, pick EU during signup.

Data never leaves your chosen region. Recordings, transcripts, audience records, post-call analysis — all stay in-region.

Burst capacity

Sometimes you need a one-time spike beyond your plan limits (election outreach, product launch, weather event response).

• Pre-authorized burst — contact support 48h ahead with expected peak. We provision capacity, you pay only for actual usage beyond your tier.
• Soft burst — the platform allows up to 20% above your plan's concurrent limit for short bursts (under 15 minutes). Use sparingly; sustained burst gets throttled.

When you hit a limit

If you exceed your concurrent-call limit, new outbound calls queue rather than fail. The queue drains as active calls complete.

For inbound, exceeding the limit means new inbound calls get a "currently busy" tone or go to fallback voicemail (configurable per-number).

In both cases, the dashboard shows a yellow warning banner. If you see it more than occasionally, upgrade your plan.

Performance benchmarks from production

Real numbers from customers running at scale (anonymized):

If your projected numbers are in these ranges or below, the platform handles them without issue. Above the top row, contact sales for capacity planning.

How to scale up safely

Stage 1 — Pilot (1-50 calls/day)

• Single Finn, single deployment.
• Run on Starter or Growth plan trial.
• Measure: success rate, completion rate, cost per outcome.

Stage 2 — Production launch (50-1,000 calls/day)

• Same Finn config; add monitoring.
• Set per-deployment spend caps.
• Register caller ID, set up auto-suppression.

Stage 3 — Scale (1,000-10,000 calls/day)

• Add number pool (5-15 numbers).
• Consider multi-Finn segmentation (different Finns for different audience segments).
• Set up Slack alerts for deployment failures.
• Move to Scale plan.

Stage 4 — High scale (10,000+ calls/day)

• Parallel deployments.
• Larger number pools (50+).
• Webhook stream for real-time analytics in your own systems.
• Enterprise plan with dedicated CSM + SLA.

Stage 5 — Mass scale (100,000+ calls/day)

• Dedicated infrastructure (Enterprise).
• Multi-region for latency optimization.
• Custom rate limits, custom integrations.
• Direct line to engineering for spike planning.

Common questions

Q: What's the actual technical limit on concurrent calls? A: Not a published number. We've stress-tested above 50,000 concurrent. In practice, the limit you'll hit is your plan tier or your number-pool size, not the platform's capacity.

Q: If I exceed my plan limit, does it auto-upgrade? A: No — that would be a recipe for surprise bills. The platform queues or rejects calls and shows a warning. You manually upgrade when ready.

Q: Do calls cost more during peak hours? A: No. Pricing is flat per minute regardless of when the call happens.

Q: Can I run different Finns at different concurrent volumes? A: Yes. Each Finn has its own per-Finn limit, and the account-wide limit is shared across all Finns. You can run a 100-concurrent qualifier and a 20-concurrent receptionist simultaneously without issue.

Q: How fast can I ramp up a new deployment? A: Most deployments hit their target concurrent within 2-5 minutes of launch. Very large ramps (1,000+ concurrent in <1 minute) need pre-coordination with support.

Next

• Phone Numbers → Number pools — how to set up pools for scale.
• Billing → — what each plan tier costs.
• Campaigns & Deployments → Parallel deployments — for high-concurrency outbound.