Patient Outreach Capacity Planning: Size Campaigns Your Team Can Support

The release decision starts after eligibility is established

An approved outreach list answers who may be contacted for a defined administrative purpose. It does not answer how many invitations your team can support at once.

Keep list eligibility, approved contact preferences and stop rules in the specialty referral outreach workflow. This article begins with a ready list and a named receiving team. Its job is to decide how much new work to invite into that team's day.

The dependency is recognized in product documentation. Artera's Referral Triggers Queue supports timed release rates and tells organizations to align those rates with staff response capacity. That describes Artera's configured feature, not a universal staffing formula.

The worksheet below is an original planning model. It turns a release into expected staff work across time, including work that remains after the messaging system has finished sending.

Choose a unit that connects the invitation to the work

For the examples here, one release unit is one eligible referral episode receiving one initial invitation. An episode is not necessarily a unique patient, and a task is not necessarily a unique episode.

A patient might reply once, need a scheduling callback, and later require an administrative correction. Those are separate staff tasks associated with the same episode. Conversely, a patient may complete the offered task without staff assistance.

Record the task types your team handles: a scheduling reply, requested callback, booking correction, or other approved administrative follow-up. Measure active handling time, including the record update needed to finish that task. Waiting for another person is elapsed time, not continuous staff effort.

AWS's forecasting import documentation separately records incoming contact volume, handled contacts and average handling time by interval. This is a useful example of keeping demand and handling units distinct. The campaign formula here is not an AWS forecast.

Use the call-center operating model to distinguish contact counts from completed requests. For batch sizing, the immediate input is the staff work generated, whether or not the patient's larger task finishes in that interval.

Build a release worksheet with an accountable owner

Nominate a release owner who can see the campaign queue and the staff worklist. The sending system alone cannot tell that person whether the receiving team has become unavailable.

Count only usable capacity. Two staff members present for an hour do not necessarily provide 120 minutes to this queue if one also covers check-in or a meeting. Equally, do not subtract that competing assignment twice after it has already been removed from available minutes.

Check capability as well as totals. If a response needs a particular authorized role or supported language, minutes belonging to another team may not be usable. The multilingual outreach guide provides related communication context; this calculation treats approved support arrangements as an input.

Map when the work arrives

Estimate staff tasks per released episode for each receiving window. This factor can include initial replies, delayed first replies, requested callbacks and later follow-up tasks.

Do not require the factors to sum to 100%. They describe tasks per episode, not mutually exclusive patient outcomes. One episode can generate several tasks, and some generate none. Name the unit in every column so a task factor is not mistaken for a response probability.

Associate each observed task with its originating batch where the available records support that relationship. Preserve an unattributed category when they do not. A vague increase in phone volume is not enough to establish that every extra call came from the campaign.

Follow the batch beyond its first burst of replies. A morning invitation can create afternoon work or a callback tomorrow. Later tasks belong in future commitments even while today's visible inbox is empty.

If there is no useful history, use clearly labelled assumptions and a small monitored release. An observed zero from a tiny sample does not justify an unlimited batch.

Calculate the new-work budget in each window

Use this planning identity:

New-work budget = available staff minutes minus routine demand minus existing commitments minus reserve.

If that result is negative, the window is already overcommitted under the assumptions. Show the deficit and hold additional release. Do not erase it by displaying only zero capacity.

For a proposed batch, calculate:

Induced work in a window = released episodes x expected staff tasks per episode in that window x minutes per task.

When task types have different handling times, calculate each separately and add their minutes. Compare that total with the window's new-work budget. The permitted batch must fit all relevant windows and any separate role constraints.

The formula is a workload screen, not a queueing guarantee. Variation in arrivals and task duration can still produce waiting. Check actual work and the age of outstanding replies before making the next release decision.

Work through a hypothetical batch

Hypothetical example: a team has a ready list of 100 eligible episodes. Each would receive one initial invitation. The release owner considers the current hour, the following hour and a staffed follow-up window tomorrow.

All figures below are invented staff minutes. "Available" already excludes breaks, meetings and duties assigned elsewhere. Existing commitments include only work not counted as routine demand.

The current-hour commitments consist of 15 minutes of already queued work and 15 minutes expected from previous batches. Those previous releases still consume capacity even though they are no longer in the send queue.

The team uses these hypothetical demand factors for the proposed batch:

The last row includes later follow-up work, not just first replies. These factors are illustrative assumptions, not industry response rates.

The window limits are 20/1.0 = 20 episodes, 15/0.5 = 30 episodes, and 12/0.4 = 30 episodes. The smallest limit is 20 episodes, so the team releases 20 and holds 80.

That batch creates expected work of four tasks and 20 minutes now, two tasks and 10 minutes next hour, and one task and eight minutes tomorrow. Total expected work is 38 staff minutes across seven tasks. The seven tasks are not necessarily seven different patients.

Adding the budgets first would conceal the constraint. The combined 47-minute budget divided by 1.9 total minutes per episode suggests 24 whole episodes, but those would require 24 minutes in the current hour when only 20 are budgeted. The current window controls the decision.

Carry commitments forward without counting them twice

After release, move its expected future work into the commitments register. For this example, reserve 10 minutes in the next hour and eight tomorrow. Those minutes are no longer free for another campaign owner to allocate.

As tasks arrive, replace the relevant forecast with actual remaining work. Do not keep both the original predicted task and its now-visible queue entry as separate demand. Conversely, do not delete all expected later work merely because one patient has replied.

At each checkpoint, reconcile opening unworked minutes, newly arrived work, minutes completed and closing unworked minutes. Keep the task records behind the estimate. If a long task is partly finished, carry its estimated remaining effort rather than its original full duration.

For a campaign assembled from payer files, the payer-list workflow is the upstream context. Apply the organization's approved list reconciliation and prioritization before this release calculation. Capacity arithmetic cannot decide clinical eligibility or which service a patient needs.

Replan when the receiving conditions change

Suppose the 20-episode batch produces six current-hour tasks instead of four, each requiring five minutes. Actual demand is 30 minutes, which uses the planned 20 plus the 10-minute reserve. Hold the next batch and reassess the remaining day rather than assuming the first forecast remains accurate.

Check whether the difference is additional work or earlier-than-expected arrival. Until the evidence resolves that distinction, keep future commitments visible. Reducing tomorrow's reservation just because today's replies increased can create another shortfall.

Pausing release affects unsent invitations. It does not withdraw messages already sent or stop patients responding. Keep the receiving queue staffed under the approved coverage plan while the release owner changes future volume.

Use the same review after an absence, a source-system outage or a change in task mix. Record the decision, revised batch size and next checkpoint so another supervisor can continue it.

To discuss the administrative response workflow around AI voice agents for healthcare, bring one ready cohort, the expected reply pattern and the staff work already committed.

FAQ

Sources

• Artera: Referral Triggers Queue, configured release pacing and staff-response capacity; accessed September 8, 2026.
• AWS: Import historical data for forecasting, separate interval-level contact and handling inputs; accessed September 8, 2026.