It runs six days a week
Everything else in this framework happens monthly or quarterly. This one happens every working day, and that changes what a defect costs.
The four stages are trips in, plan the day, run the day, get paid. They are one loop, not four departments. Almost every expensive problem in NEMT lives in a handoff rather than inside a stage: a trip accepted without a rate check that billing inherits, a plan built at 6am that nobody can hand over, a completed trip whose paperwork sits until Friday.
Running every day also changes what a fix is worth. Five minutes saved on a step your dispatcher repeats every morning is days back in their year, and a broken step in intake breaks every day rather than once. Which is why the loop is the one place in the company where it is always worth fixing the cause rather than the symptom: whatever you fix here you fix hundreds of times.
The cadence
| What happens | How often | Who owns it |
|---|---|---|
| The loop: trips in, plan the day, run the day, get paid | Daily | Dispatch |
| Tomorrow’s plan finished by a named time | Daily, before the day ends | Dispatch |
| Completed trips documented and submitted | Daily | Billing |
| Exception playbook checked against what actually happened | Monthly | Owner and dispatch |
| Intake channels audited: is everything landing in one place | Quarterly | Owner |
Trips in
Accepting is easy to do by default. The file arrives, the trips go into the system, and whether each one was worth running gets answered weeks later by someone in billing.
Four things belong on the front of that decision. Is the authorization in place. Does the rate clear your floor, which is the rule Vision asked you to hand to dispatch. Does the trip fit the shape of the day you already have, geographically and in time. And is it a standing order, which makes it worth more than a single trip and worth pricing differently.
A check that takes ninety seconds at intake takes six weeks to surface at billing, by which time the trip has been run, the driver paid and the fuel burned. The asymmetry is the whole argument.
Before any of that works, trips have to arrive in one place. Broker portals, emailed files, facility calls, and a text to a dispatcher’s personal phone is four inboxes, and a plan built from four inboxes is missing a trip that nobody has noticed yet. Consolidating intake is unglamorous and it is the single highest-return change available in the loop.
Plan the day
One question sorts operators quickly: what time is tomorrow finished?
If the answer is some version of “in the morning,” there is no plan, there is a scramble with a start time. The day begins already reacting, the first exception lands on top of an unfinished plan, and the dispatcher spends the morning doing work that could have been done in a quiet room the evening before.
Two things make a plan real. Every trip has a driver and a time against it before the day starts. And it is built on actual drive times rather than habit.
That second one hides a common failure. Routes get built on driver familiarity, because Maria always does the north side and knows which building has the loading dock on the back. That is efficient right up until Maria is out, at which point the company discovers that the route lived in her head and the replacement is forty minutes behind by ten in the morning.
So the real test of a plan is whether someone other than the person who built it could run it tomorrow.
Run the day
By nine in the morning some of your plan is wrong. Dialysis cancels, a driver calls out, a discharge runs two hours long. That is a normal Tuesday, not a broken plan.
What separates a calm operation from a loud one is what happens next. A dispatcher either re-plans, in which case the rest of the day stays coherent and the plan continues to be worth looking at, or patches, in which case the plan becomes fiction by lunchtime and everything after that runs on memory and phone calls. Patching feels faster in the moment and costs the rest of the day.
Which means exceptions deserve to be designed rather than improvised. Four of them account for most of what goes wrong, and each needs a written default, a name against the decision, and an answer to who tells the rider or the facility.
A trip cancels
Does the rest of that route close up, or does the driver sit? Who decides, and how fast?
A driver calls out
Which routes get covered, which get split, and which trips get given back to the broker before 7am rather than at 9?
A will-call comes in
Who owns the return, and what is the promise to the facility on pickup time?
A rider is a no-show
How long does the driver wait, what gets documented at the curb, and who tells the facility?
Write those four down and the loudest parts of the day become routine. That is the test, and it sounds backwards the first time you hear it: a well-run NEMT day is boring. Not slow, boring. The cancelled dialysis run gets absorbed, and nobody raises their voice, because handling it was part of the loop rather than an interruption to it.
Get paid
The loop is finished when the money arrives, and the distance between the drop-off and the deposit is mostly self-inflicted.
Billing in a month-end marathon feels efficient because the work is batched. Here is what it actually buys. Every resubmission window is finite, so the days you spend before submitting come out of the days you have left to fix a problem. Submit the same day and a denial surfaces while the driver still remembers the trip and the window is almost untouched. Submit at month end and the same denial arrives with half the window gone and nobody able to recall what happened at that curb.
Which puts real weight on what the driver captures at the time. Attestation or signature, odometer, actual pickup and drop times, and anything unusual about the trip. None of that can be honestly reconstructed on Friday, and a claim built from memory is a denial with a delay on it.
The number that tracks all of this is days to payment, measured from trip completion rather than claim submission, which is exactly why the Scoreboard defines it that way. The days between completing and submitting are the ones you control, so they are the ones worth counting.