Secure Message or Phone Call: Routing the Same Request Two Ways

Every multi-specialty group runs two front doors into the same work. A patient calls to move an appointment. A different patient sends a secure message asking for exactly the same thing. The call lands in a queue with owners, hours, and an escalation path. The message lands in a portal inbox that somebody checks between other tasks.

The gap is not technical. The phone has been managed as an operation for decades. The messaging channel was switched on because the platform included it, and it has been growing ever since without anyone assigning it the same rules.

So the two drift apart. Phone requests get worked against a standard. Message requests get worked when a person has a gap. Patients do not experience this as two channels. They experience one practice that was quick last time and slow this time, and they form an opinion about the practice rather than about the inbox.

The message channel grew while nobody assigned it an owner

Portal messaging stopped being a side door some time ago, and most staffing models have not caught up.

ONC reporting on a decade of patient access data notes that patients used portals to message their providers at a rate of 64% in 2022, up from 53% in 2018. That is a channel carrying real request volume, not a convenience feature.

In a multi-specialty group the effect compounds, because a single patient may hold relationships in three departments and send all three departments a message through one portal account. The phone routes that patient by what they say. The portal routes them by whichever provider name they happened to pick from a list.

The practical result is a channel with volume, no service standard, and no clear owner. Nobody decided that. It is what happens when a channel arrives switched on.

Message types are a routing taxonomy you already have

Most practices treat portal messages as one undifferentiated pile, then complain that the pile is hard to work.

athenaOne already carries a configured set of patient message types for the practice, readable through GET /patientsecuremessage/getavailablemessagetypes. That list is the same thing the phone side calls an intent list. Appointment request, billing question, refill request, records request, general question. The taxonomy exists. It is simply not being used to decide who works what.

Once a message carries a type, it can be treated the way a call is treated. A billing question goes to the billing queue whether it arrived by voice or by portal. A refill request is captured with the pharmacy and the medication name attached, then routed to the clinical staff queue that handles refills, exactly as it would be from a call.

The rule worth writing down is that channel decides how the request arrived, and type decides who works it. Practices that conflate the two end up with a billing question sitting in a provider’s message queue for four days because a portal message is assumed to belong to the provider it was addressed to.

Department mapping is where the message actually lands

In a multi-specialty group the harder half of routing is not what the patient wants. It is which department owns the answer.

athenaOne exposes the provider-to-department mapping used for patient messaging through GET /patientsecuremessage/providers/departmentsmapping. That mapping is what turns a message addressed to a provider into a message sitting in the right department’s work queue. A provider who sees patients in three departments is three different routing destinations depending on why the patient is writing.

The common failure is leaning on the chart’s primary provider field to make that decision. That field is stale almost everywhere. Panels change, providers leave, and nobody goes back to update it, so routing built on it sends a meaningful share of messages to a clinician who has not seen the patient in two years.

The workable fallback is recent encounter history. Who has actually seen this patient, in which department, most recently. That is a query rather than a maintained field, which is precisely why it stays accurate while the maintained field rots.

The complication: the rules the phone obeys, the message channel skips

Here is where a message channel quietly produces bookings that cannot be delivered.

Most practices run two different minimum lead-time rules at once. New patients cannot book inside roughly three to four business days, because forms, prior records, and eligibility all have to be completed before the visit is useful. Established patients can often book next business day. Every scheduler knows this. It lives in training and habit rather than in the scheduling template.

A phone request runs into a human who applies the rule. A portal message asking to move an appointment to Thursday frequently does not, because the person working the inbox is trying to clear it, and the request looks reasonable. The booking gets made, the forms are never completed, and the visit turns into a rescheduled appointment discovered at check-in.

Automation is only an improvement here if it carries the rule. A message-driven reschedule should resolve the patient’s status first, apply the same lead-time rule the phone side applies, then offer only compliant openings in the reply thread. Scheduling calls are among the most time-consuming phone work practices report, ranking second at 31% behind eligibility and prior authorization at 45% in a March 10, 2026, MGMA Stat poll of 294 applicable responses, so the point of moving some of that volume to messaging is lost if the moved volume creates rework.

The handoff is the exception. When the patient pushes back, when the request crosses two departments, or when the only compliant opening is weeks out, the thread goes to a scheduler with the constraint stated in it. The automation does not negotiate. It presents what the rules permit and hands over the cases where the answer is no.

Measure both channels as one queue or you will optimize the wrong one

Channel-level reporting hides the thing you want to know, which is whether the request got resolved.

A practice can post a strong average hold time and a clean abandonment rate while the message queue runs four days behind, and the phone numbers will look better every month as patients give up on calling and write instead. Front-office automation investment is concentrating in exactly these queues: a Feb. 10, 2026, MGMA Stat poll of 177 applicable responses ranked scheduling at 31%, calls at 27%, registration and eligibility at 23%, and prior authorization at 16% as the top targets. Splitting the measurement by channel makes it very hard to tell which of those actually improved.

Three measures do the work. Time to first meaningful response by request type rather than by channel, so an appointment request is held to one standard however it arrived. Resolution without a channel switch, which counts the requests that finished where they started. And the channel-switch rate itself, the share of patients who sent a message and then called, which is the cleanest signal that the message channel is not trusted.

That last one is worth watching weekly. A rising channel-switch rate means the practice is now paying for both channels to handle the same request, which is more expensive than either one alone.

Key Takeaways

Route by request type, not by arrival channel. A billing question belongs in the billing queue whether it came from a call or a portal message.
Use the message types athenaOne already carries for the practice as the routing taxonomy instead of treating portal messages as one undifferentiated pile.
Resolve the destination through provider-to-department mapping. A provider working across three departments is three routing outcomes, not one.
Do not route on the chart’s primary provider field. It is stale in most practices. Use who has actually seen the patient recently.
Apply the same minimum lead-time rules to message-driven scheduling that your schedulers apply on the phone, or you will book visits that fail at check-in.
Set one service standard per request type across both channels, then staff to it. A channel with volume and no standard is the one that will slip.
Track resolution without a channel switch, and watch the share of patients who message and then call. That number tells you whether the message channel is trusted.
Hand off rather than negotiate. When the rules do not permit what the patient asked for, the thread goes to a scheduler with the constraint stated.

A multi-specialty group has one intake problem arriving through two doors, with rules written down on one side and improvised on the other. Choosing a channel does not solve that. What solves it is making request type, department mapping, and scheduling rules apply the same way regardless of how the patient reached you. An AI team working both channels inside athenaOne can classify the request, resolve the department, apply the booking rules, and hand a person the cases that need judgment.

Sources