Pretty Good AI vs RevSpring

One workflow in common, and it is the money

RevSpring sells a patient payment experience. The athenahealth Marketplace listing is plain about the job: let the patient pay by phone, online or text, keep the options secure, and get the practice collected faster. It requires athenaCollector, which places it squarely on the practice management side of athenaOne.

Pretty Good AI takes patient payments too. Patients pay on the Pretty Good AI web scheduler, and we send secure payment links through your practice’s existing payment portal wherever that is the rail your billing team wants, with balances, documented payment plans and follow-up running to your billing team’s rules.

So the overlap is real and it is narrow. It is the payment itself, and the text message that asks for it.

What surrounds it is the difference. The balance conversation at a practice running Pretty Good AI happens inside the same front office that answers the phone, fills the schedule, chases referrals and handles forms. A patient calling about a bill is talking to the system that also knows when their next appointment is.

Why this page exists before the install base does

RevSpring’s athenaOne listing is new. It went live on 26 March 2026 and recorded 2 practice connections, with no ratings and no written reviews, as of 5 October 2026. On the Marketplace numbers alone this is an early listing, not an incumbent.

The reason the comparison matters anyway is Thrive. RevSpring is sponsoring athenahealth Thrive 2026, and a sponsor is buying attention from exactly the practices we sell to. Brand exposure at an event runs ahead of install base, and the searches follow the exposure.

Worth saying clearly, because the temptation runs the other way: a low connection count is not evidence that anybody is unhappy. It is evidence of a recent listing. RevSpring is a long-established company in patient financial communications; what is new is this athenaOne listing.

The question a practice is actually asking

Almost nobody evaluates a payment tool and an operations platform side by side on purpose. What happens is messier.

The practice has a collections problem. Patient responsibility is aging, staff are not getting to the follow-up calls, and somebody suggests a payment vendor. That is a reasonable response to the symptom. The useful question is whether collections is the problem or the readout.

Here is the test. Look at why the balance did not get worked. If the answer is that the payment experience was clumsy and patients dropped out of it, a payment specialist fixes that directly. If the answer is that nobody made the call, nobody answered when the patient called back, and the account aged while the front desk was underwater, then the collections number is reporting a capacity problem and a payment tool will leave the cause in place.

Your own phone logs settle this faster than any vendor conversation. Count how many inbound billing calls went to voicemail last month.

The complication nobody plans for

The following is an illustrative workflow, not a customer story.

A multi-site behavioral health group turns on a payment vendor in March and an appointment reminder automation in May. Both are configured to be helpful. Neither knows the other exists.

The patients who complain are the ones with an outstanding balance and a rescheduled appointment: a text on Monday asking for $140, a call on Tuesday about moving Thursday’s visit, a second text on Wednesday about the same $140. A small group of patients, and the most valuable ones to keep.

The group finds out in month two, from a front desk escalation rather than a dashboard.

The resolution is not ripping anything out. It is a written rule, agreed before both systems go live, naming which one owns outbound contact for which workflow. Accounts in active payment-plan negotiation come off automated outreach entirely and sit with the biller who can agree terms, because that is a decision and not a message.

That rule costs nothing and almost nobody writes it down.

Where the architectures differ

A payment product is scoped to the payment. When the call is about paying, that scope is an advantage: everything in the product is built for that one transaction.

The difference shows up when the call is about something else, which at most practices is most of the time. Someone rings to move an appointment and mentions the bill. Someone rings about the bill and needs to rebook while they are on the line. A payment-scoped tool handles its half and hands off the rest.

Pretty Good AI handles the mix because the scheduling surface and the billing context sit behind the same athenaOne integration. The agent can answer why the balance exists, send the link, and put the follow-up visit on the calendar inside one conversation, then write what happened back to the chart so the biller is not reconstructing it later.

That is an architectural difference rather than a quality judgment about either product. Which one matters depends on what your callers actually ask for, and you already have that data.

Clinical decisions stay with your care team. What we take off the practice is the administrative work around the money conversation: making the call, answering it, surfacing the balance, taking the payment, booking what comes next.

How to decide

If you already run a payment product and the rail works, keep the rail. We send secure payment links through your existing portal, so the decision is who owns the phone line, the schedule and the balance conversation, not which tool takes the card.

If the phone is not being answered, the schedule has holes, referrals are sitting in a queue, and the balances are also aging, you have one problem showing up in four reports. Fix the capacity and the collections number moves with it.

And if you run both, the only question that needs answering this month is which system owns outbound patient contact for which workflow. Write it down before the second system goes live. The practices that skip that step find out from a patient.