Concurrency Is a Design Decision, Not a Capacity Number

Why “how many calls can you run at once?” is the right question to ask, and the wrong place to stop.

In almost every early conversation with a new healthcare partner, someone asks how many calls we can run at the same time. It’s a reasonable question. If you have 20,000 members to reach before a deadline, simultaneous capacity feels like the number that decides whether the program works.

My honest answer is usually “it depends.” That isn’t a dodge. As a forward deployed engineer, I sit with our partners while programs are designed and launched, and I’ve learned that the right level of concurrency is shaped far more by the use case than by the infrastructure. Sometimes the best-performing program is the one that deliberately runs fewer calls at once.

Here’s how we think about it, from the inside out: what limits concurrency on our side, how we prioritize when not every call can go at once, and why the most important concurrency limits are often the ones you set on purpose, based on what your use case needs.

What actually limits a live call

A voice AI call isn’t one system. It’s several working in real time, every second of the conversation.

There are several real time systems working in tandem - doing live transcription, classification inference and speech synthesis across the carrier network that makes the call show up on someone's phone in the first place. That's not even counting external integrations with client systems - all of which is a potential bottleneck that does not scale the same way.

Some can add capacity almost instantly as demand rises. Others take longer to expand and can’t simply be turned up on demand.

So we handle the two cases differently. Where we can scale in real time, we do, dynamically. Where we can’t, the responsible move isn’t to push harder. It’s to manage concurrency: decide deliberately how many calls run at once, and which calls get the next available slot.

That second case is where the interesting decisions live.

Not every call is equally urgent

When concurrency is limited, every call in progress holds a slot. When one ends, a slot opens, and something has to decide what fills it. That decision is where a lot of the real design work sits.

A simple rule: inbound calls take precedence. Someone who calls in has chosen to pick up the phone, usually because they need something now: a question about a bill, a referral, an appointment. They’re already waiting. An outbound call can go out a few minutes later without anyone noticing. An inbound caller left on hold notices every second, so we work to keep them from holding. When a slot opens, an inbound call gets it first.

Outbound is where prioritization gets more interesting. The calls we place don’t all carry the same kind of urgency, and treating them alike would mean keeping pace on some while breaking promises on others. Understanding the difference starts with knowing the three types of outbound calls.

Campaign calls reach a defined group of contacts over a defined window. They’re the most flexible. If a campaign has an hour to run, we could place every call in the first five minutes or spread them across the full hour. We pace them by looking at how much of the window remains and what it will take to finish on time.

Scheduled calls are tied to a specific moment. If we texted someone earlier to say we’d call at 2:00, the goal is to call at 2:00, not 2:40. Timing is the whole promise.

Real-time calls are triggered by a partner’s own systems the moment something happens. Their value depends on speed, so they need to go out quickly.

These needs pull against each other, and weighing them well is what lets a campaign finish, a scheduled call land on time, and a triggered call go out promptly, all on shared capacity.

When more at once is the wrong answer

Everything above is about technical feasibility: what our platform can run, and how it keeps competing demands in balance. That’s the easier half of the problem. The more important half is knowing what makes a good experience, and what delivers better outcomes, for the person on the other end of the call, and that comes from understanding the use case. A level of concurrency can be entirely feasible and still be the wrong choice, because its consequences show up downstream, in your operations and in your members’ experience.

Take appointment scheduling. Outbound reminder calls can run at high volume without much trouble; each call is independent. Now picture a program that calls patients to book the earliest available visit. Every one of those calls is looking at the same pool of open slots. Run too many at once and two patients can be offered the same 9:00 appointment, or a slot gets held for one caller while another caller needs it. At that point, more concurrency doesn’t reach patients faster. It means more patients being told the appointment they just accepted isn’t theirs after all.

The systems we connect to have limits too. Scheduling platforms, eligibility services, and records systems often cap how many requests they’ll accept in a given period. A burst of simultaneous calls can hit those ceilings long before our capacity becomes a factor.

And then there are people. If a call ends in a warm transfer to your team, whether that’s enrollment, care coordination, or scheduling staff, the right concurrency depends on how many people are available to pick up. If two staff members are taking transfers, running dozens of calls that each end in a hand-off just builds a queue of callers waiting on hold.

That’s why we can limit concurrency for a single partner, or for a single workflow within a partner’s program, and hold it below a set threshold while the campaign still runs to completion. The goal isn’t the highest number of simultaneous calls. It’s the number that gets the most people to the right outcome.

Plan the campaign around people, not capacity

Once the right concurrency is set, the next question is when to use it. This is where campaign planning becomes less about infrastructure and more about the population you’re trying to reach.

Here’s a simplified example. Say you have 5,000 people to call, and the scheduling workflow behind the program means no more than three or four calls should run at once. To plan the campaign, we need a few numbers: how long a typical call lasts, what share of calls get answered, and when people in this population are most likely to pick up.

That last one matters more than most teams expect. Answer rates shift across the day, and the pattern varies by population. For this example, assume early morning is the strongest window, late afternoon is second, and midday is the weakest. With limited concurrency, every hour of calling spent in a weak window is capacity you can’t spend in a strong one. So rather than running straight through the day, we’d likely split the campaign into two windows: one in the morning and one in the late afternoon.

The arithmetic makes the stakes clear. If each attempt averages three minutes, running four calls at a time yields roughly 80 attempts an hour. Five thousand attempts is then more than 60 hours of calling. Spread across a few strong windows a day, that’s a couple of weeks of outreach, which is exactly why it matters which hours you choose.

We can go a step further and segment the population itself. Different groups of people are reachable at different times, so we can place subgroups with shared characteristics into their own campaigns, each timed and paced for the people in it.

What to bring to the planning conversation

If you’re preparing to launch a voice AI program, the most useful thing you can bring isn’t a target number of simultaneous calls. It’s the context that tells us what that number should be.

• The size and deadline. How many people you need to reach, and by when.
• The shape of the call. Roughly how long it runs, and what it does beyond talking: booking, verifying, updating a record.
• What calls compete for. Appointment inventory, reserved slots, or anything two calls could reach for at the same moment.
• Downstream limits. Rate limits on the systems we connect to, and how many of your people can take a transfer at once.
• What you know about your population. When they tend to answer, and whether subgroups behave differently.

None of this is a formality. It’s the discovery work that decides whether a program reaches people or just dials them. That’s why we treat concurrency as something we design together with each partner rather than a setting we hand over.

The question worth asking isn’t how many calls can run at once. It’s how many should, for this program, for these people, right now. Getting that answer right is how a campaign turns into what it was meant to be: people getting access to care.

By John Showel, Forward Deployed Engineer, Attune

John Showel is a Forward Deployed Engineer at Attune, where he works directly with healthcare partners to design, configure, and launch voice AI programs. Attune is the Agentic Engagement Platform for healthcare. It conducts voice, chat, and SMS engagements and orchestrates the workflows that connect them, carrying the outcome of each interaction into the next one a patient or member experiences. That continuity spans reminders, follow-ups, and closing gaps in care. Every engagement updates systems of record in real time, and when a conversation calls for a person, Attune warm transfers to the partner’s team. Attune serves payers, providers, risk-bearing organizations, diagnostics, and MedTech companies.

‍