They Said Yes. That Should Not Be Enough.
Before you hand over the work, find out whether they understand everything it touches.
"AI has made it impossible to get paid."
A physician said that to me during an in-person conversation, and I have thought about it more than the sentence probably deserved on its own, because that was not really where the problem started. It was just the most recent place the conversation had landed.
Before that conversation, there had been others. A peer mentioned lien-based revenue as an option. Someone suggested AI tools to speed up documentation. A friend floated a cash-pay service line to offset the insurance frustration. Someone offered to help promote the new service. Each conversation added a little information and a new possible answer. None of them connected to the one before it. The original question, what is actually happening with reimbursement, never got a real answer. It just got buried under four more decisions.
This is how practices collect answers without ever reaching a decision.
I am not telling you this to point at one physician. I see this pattern constantly, and it rarely looks like a mistake while it is happening. It looks like progress. Someone said yes. Something moved. That has to count for something.
It does not always count for what you think it does.
The Easy Yes Should Make You Pause, Not Relax
When you bring a problem to someone and they say yes immediately, that usually feels like relief. Finally, someone who can help.
But think about what that yes required from them. Did they ask what you were trying to accomplish? What you had already tried? What else in your practice this touches, or what success is supposed to look like when the work is done? Or did they just hear enough to recognize the task and say yes to doing it?
Those are two different things. One is someone evaluating whether this is the right move for you. The other is someone confirming they know how to perform a task they have performed before.
If they can accept the assignment before they understand what it touches, they may be preparing to process your request, not solve your problem.
I want to be clear about something here. This is not a blanket accusation against anyone who responds quickly. Plenty of tasks really are contained. A transactional vendor who processes something fast and correctly is doing exactly what they should. The skill you need to build is telling the difference between a task that only needed processing and a problem that needed someone to think about it first.
The Surface Scratcher
I call this kind of help a surface scratcher, because that is exactly what it does. It handles the visible request without looking at what sits underneath or around it.
For a small, contained task, that can be completely fine. You do not need someone interrogating your entire operation to fix one narrow thing.
It becomes a real problem when you are opening a new practice, adding a location, launching a service line, expanding into another state, changing your business model, restructuring revenue, transitioning ownership, or trying to fix something that has already survived two or three previous attempts.
Work at that scale crosses more territory than it looks like from the outside. Licensing touches enrollment. Enrollment touches staffing. Staffing touches operations. Operations touch contracts, technology, patient communication, positioning, and revenue. A surface scratcher was never built to see across all of that. They were built to complete the piece in front of them, well, and then move to the next request.
The RCM Example
Here is a version of this you will probably recognize.
Say you have used the same revenue cycle company for billing for two years. They now offer payer credentialing too, and since they already know your practice, adding credentialing with them feels like the obvious next step.
That history is real. It does not automatically mean they are the right choice for this next piece of work.
Before you say yes, ask who actually handles the credentialing itself, the same team or a different department you have never spoken to. Ask if there is one named person you can reach, or whether you are submitting into a queue. Ask how often you get an update without asking for one yourself. Ask whether the service ends the moment an application gets submitted, or whether someone stays with it if it stalls. Ask who handles a payer asking for a correction. Ask what you are still expected to track on your own. Ask what happens after approval, and whether anyone is still paying attention once the paperwork is done.
Also ask where the work is actually being done. A company calling itself US based does not necessarily mean every person accessing your systems, payer portals, or protected information is working in the United States. Offshore support does not automatically mean poor work. You should still know who is handling your accounts, what is being subcontracted, where access occurs, how that access is controlled, and who is accountable when something goes wrong.
And do the basic math. If a company says it has served a certain number of clients and collected an enormous amount of money in a short period, divide it. What would that equal per client, per month? Does that make sense for the size and type of practices they claim to serve? Does “clients served” mean current clients or everyone they have ever worked with? Does “collections” mean charges submitted, payments posted, or money actually collected? Are the client count and collection total even from the same period? A giant number is not proof just because it is printed in bold. Sometimes the math really isn't mathing.
Someone looking beyond the transaction notices things nobody asked them to look for. Malpractice coverage coming up for renewal. A DEA registration approaching expiration. CAQH information that needs attention before it becomes a problem. A payer revalidation deadline sitting a few weeks out. A state license quietly approaching renewal. A collaborating agreement still sitting under your name when it shouldn't be. An enrollment decision at one location that actually affects revenue at another.
Nobody promises every engagement catches every one of these. The point is that one company may submit the application you requested and stop there. Another person may also notice what is sitting around that application and why it matters.
Software Is Not the Enemy Here
I want to be direct, because it would be easy to read this as an argument against automation. It is not. Most billing and credentialing companies use software somewhere in their process. So do I.
Software can track what someone entered. It cannot take responsibility for what nobody thought to enter, connect, or review.
A drive-through version of this work might give you a portal, some automated reminders, and a completed transaction. The price alone may not tell you which version of the service you are buying.
The difference becomes visible in what happens around the transaction. Someone notices. Someone makes the connection between this piece and the next one. Someone tells you before you have to ask. Someone understands why a date, an agreement, or a missing document matters to the rest of your practice, not just to the task in front of them.
That is not a software problem. It is a human attention problem, and no portal fixes it by itself.
Before You Hire the Next Practice Operations Advisor
Before you say yes to whoever is in front of you next, ask yourself these questions:
What problem am I actually trying to solve?
Am I hiring someone to complete a task, manage a process, or own an outcome?
What questions did they ask before they said yes?
Who will actually perform the work, where are they located, and will any part be subcontracted?
Who will communicate with me, and how often?
What will they monitor beyond the immediate assignment?
What remains my responsibility after they finish?
How does this connect to the rest of my practice?
You do not need every vendor you hire to own your entire operation. You do need to know exactly where their responsibility ends, and who is responsible for everything past that point.
The danger is not hiring someone for one task. The danger is believing you hired someone for the outcome when they only agreed to process the task.
Where I Actually Fit
Zentara is not there to fill one pothole and leave. I need to know whether the road still goes where your practice is trying to go. Sometimes it needs to be repaired. Sometimes it needs to be widened, paved, or rerouted for where you are today.
I ask questions before I accept an assignment. I connect what you are asking for right now to everything else already running in your practice. I notice the expiration, the dependency, the agreement, or the operational consequence you did not know to mention, because you had no reason to know it mattered. I figure out whether the thing you are asking for is actually the right next move, or whether it is solving the wrong layer of the problem. I tell you what matters before it turns into something you have to react to.
I am not the fastest yes in the room. I am the person asking what that yes will set in motion.
Pick one outside person, company, or platform currently working with your practice.
What exact task were they hired to complete?
What result do you believe they are responsible for?
Does the agreement actually say they own that result, or does it only describe the task?
What happens before and after their part of the work?
Who is watching how those pieces connect?
If the final answer is you, your administrator, or nobody in particular, you just found the part of the work that was never actually handed off.
Comments