The Follow-Up Gap: Why a 90-Day Enrollment Becomes a 150-Day Enrollment

09/10/2026

The standard answer to "how long does credentialing take" is 90 to 120 days. We publish that number ourselves, because it is the honest range for a clean application to a payer working at normal speed.


Most practices do not experience 90 to 120 days. They experience 150, sometimes more.


The gap between the published number and the lived one is where this article lives, and the useful finding is that almost none of it belongs to the payer.


Where the days actually go


Take a single application and account for it in intervals rather than as a total.


Days 1 to 7 - Preparation. Collecting current documents from the provider, verifying data, completing the payer's forms. This interval is entirely yours and is routinely underestimated, particularly when the provider is slow to return a document nobody is formally chasing.


Day 8 - Submission. The only moment in the entire process that feels like progress.


Days 8 to 35 - Payer processing. Genuinely the payer's time. Nothing you do here changes the speed.


Day 36 - Information requested. The payer needs a clarification, a missing attachment, a corrected field. This is normal and happens on a large share of applications.


Days 36 to 55 - The gap. This is the interval that matters.


Day 55 - Response sent. Processing resumes, having lost nineteen days.


Days 55 to 95 - Payer processing, second pass.


Day 95 - Approval. Or a second information request, and the cycle repeats.


Notice the shape. Payer processing consumed roughly 67 days across two passes, which is inside the published range. The overage came from a single 19-day interval in which the application sat with a request nobody had picked up.


Two of those and a 90-day enrollment is a 130-day enrollment. Add a slow document collection at the front and you are at 150 without anyone doing anything wrong.


Why the gap opens


The 19-day interval almost never has a dramatic cause. In our experience it has four ordinary ones.


The request arrived to a shared destination. A general inbox, a portal notification nobody is subscribed to, a fax. Shared destinations have no owner by definition, and everyone who sees the item assumes the person who submitted it will handle it.


The submitter was unavailable. Vacation, illness, a different client's crisis. The application does not know this and continues aging.


The request was ambiguous. Payer information requests are frequently vague. Resolving the ambiguity takes a phone call, the phone call takes forty minutes on hold, and forty minutes on hold is a task that gets postponed to tomorrow every day for a week.


Nothing escalated. Nothing in the system said "this application has not moved in fourteen days." An application with no activity generates no signal, which means the quiet failures are structurally invisible while the loud ones are not.


What to measure


If you want to close the gap, four numbers are worth tracking. None require new software to define, though tracking them by hand is its own project.


1. Median response time to payer information requests. From the moment a request arrives to the moment your response is sent. This is the single most diagnostic number in a credentialing operation, and most teams have never measured it. If it is above five business days, it is your bottleneck, and it is larger than any efficiency you will gain elsewhere.


2. Percentage of in-flight applications with a named owner. Not a team. A person. Anything below 100% is a list of applications that can silently stall.


3. Count of workflows with no activity in 14+ days. This is your delinquency queue, and it should be a standing view someone reviews weekly, not a report generated when someone gets suspicious.


4. Elapsed days by stage, not just total. A total tells you an application is late. Stage-level timing tells you where, which is the only version that leads to a fix.


What to change


Give every application an owner at submission, not at problem time. The assignment must survive absence - which means the system needs a concept of reassignment that carries context, not just a name field someone overwrites.


Make no-activity visible. The applications worth worrying about are not the ones with problems. Those announce themselves. They are the ones with nothing happening. Any status that can hold an application indefinitely without generating a signal is a design flaw in your process.


Set expectations against real data, not the published range. If you know from your own history what a specific payer and work type typically takes, tell the client that instead of quoting 90 to 120 days. CredyApp now generates an estimated approval time from historical data on similar applications, which is an approximation rather than a guarantee - but an approximation grounded in your own outcomes beats an industry average every time. The number matters less than the fact that a client who was told 140 days and got 130 is satisfied, while a client told 90 and given 130 is not, on the identical timeline.


Flag troubled applications explicitly. An application in unusual difficulty should be marked as such and reviewed differently, not left in the same queue as one progressing normally. Otherwise the hard cases receive the same attention as the easy ones, which is to say, whatever is left over.


The uncomfortable version


Payers are a convenient explanation for slow enrollment, and they are sometimes the correct one. But when a team measures its own response intervals for the first time, the usual discovery is that a substantial share of the overage was internal, sitting in the space between a request arriving and someone deciding it was theirs.


That is good news, in the sense that matters. You cannot make a payer faster. You can absolutely make that interval shorter, and the work required is not heroic - it is ownership, visibility, and a weekly look at what has stopped moving.



Find out what your median response interval actually is. Start a 30-day free trial HERE .

Read more articles