Pretty Good AI vs Clarus (ClarusCare)

The clearest version of the after-hours question

Most comparisons in this category are muddy because both vendors claim the same outcomes. This one is unusually clean, because Clarus publishes exactly what it does with each kind of call and the difference is right there in the description.

Urgent after-hours call: specialty-specific workflows route it to the on-call provider through the Clarus OnCall app, with patient information attached and flexible response options. That is a well-built answer to a real problem, refined over more than a decade.

Non-urgent after-hours call, such as a refill, an appointment request or a billing question, arrives in an organized dashboard with AI transcription, patient details and an audio recording, and is queued for staff to resolve the next business day.

Both of those are correct behavior for a call management platform. The second one is also the entire reason we exist.

Answering, documenting, resolving

There are three distinct things a system can do with an overnight call, and they get sold as though they were one.

Answering means the phone does not ring out. Every product in this category does this.

Documenting means the request is captured accurately, transcribed, attached to the patient and routed to the right queue. Clarus is genuinely strong here: transcription plus audio plus patient details plus EHR write-back is more than most answering services deliver, and it is why practices keep it for years.

Resolving means the patient hangs up and the thing they called about is done. The appointment exists in the schedule. The refill request is in the provider queue. The reschedule has already happened.

A queue of well-documented messages is a much better morning than a stack of pink slips. It is still a morning your front desk spends on yesterday’s calls while today’s phone is ringing.

Scope to confirm for your practice

Clinical on-call routing. This is Clarus’s core: specialty-specific escalation, an app physicians keep on their phone, on-call schedules your own staff manage, and a documented trail for every urgent message. Clinical decisions stay with your care team; urgent calls escalate to your existing on-call path. If urgent routing is the problem you are solving, confirm that requirement before looking at anything else.

Track record. Founded 2013, self-reporting 30,000 medical professionals and over 60 million calls managed across 40+ specialties, and a KLAS 2026 Top 20 Emerging Healthcare Solution.

What the product was designed to do. Clarus was founded in 2013, nine years before generative models were usable in production. A platform of that vintage was architected around templates, routing rules and on-call schedules, because that is what the technology of the time allowed, and a decade of customers and integrations now rests on those foundations. That is a structural starting point rather than a criticism: generative capability arrives as a layer on top instead of as the design premise. Ask what the system does when a caller says something the routing rules never anticipated.

Where the athenaOne bet lands

The administrative share gets finished, not filed. After-hours volume can include rescheduling, refill status, appointment requests, balance questions, directions and new patients trying to book. Those do not need a physician and they do not need to wait until 8am. Resolving them requires writing into the schedule and the queues, which is why we hold production access to 820+ athenaOne APIs and build workflows around the practice’s rules.

Evidence a buyer can check independently. Our athenahealth Marketplace listing publishes practice connections and ratings. Clarus does not carry a marketplace listing, so its athenaOne evidence comes from the vendor rather than from athenahealth.

Pricing you can read before the first call. Platform fee per location, per-provider modules, voice priced per call, month to month, no setup or implementation fee, and a first 30 days live.

Built in 2013, versus built after 2022

Clarus was founded in 2013, and the product reflects the good engineering of that era: reliable call capture, structured routing, clean escalation to the on-call physician. That design assumed a human would resolve the request at the other end, because in 2013 nothing else could.

Everything we build starts from the opposite assumption. The agent is expected to finish the administrative request itself, inside athenaOne, and hand a human only what genuinely needs one. That is a difference in what the two products were designed to do, not a difference in how well either does it.

The exercise that settles it

Pull one week of after-hours calls and sort them into urgent clinical versus everything else. Then count the second pile and ask what it costs you to work through it every morning.

If the urgent pile dominates, your requirement is clinical on-call routing and we are at best a complement.

If the second pile is the one that fills your mornings, the question stops being who takes the message and becomes who finishes the work before anyone arrives. The criteria to compare are accepted handoff for urgent calls, what each system does with the calls it cannot finish, and who owns the fallback.