How Trips Actually Get Into a Dispatch System

The part of the day nobody demos

Before a single driver is assigned, somebody in your office has to get tomorrow's trips into the system.

If you run broker work, you know what that looks like. Log into the first portal. Filter to new offers. Accept what fits, decline what doesn't. Move to the second portal, which has a different login, a different layout, and a different idea of what "pickup time" means. Then the third.

Some portals have an export button. You download a CSV, open it, and find the column headers don't match anything your dispatch software expects. Some portals have no export at all — so trips get read off the screen and retyped by hand, one leg at a time, with a second person spot-checking addresses because a transposed house number turns into a missed ride.

Then there's everything that isn't a broker portal. The dialysis center that faxes a schedule every Friday. The discharge planner who emails a Word doc with three trips in it. The group home that calls because Mrs. R's appointment moved to 9:15. The standing orders that never change but have to be created every week anyway.

And then the day starts, and the portal updates. A pickup time shifts. A trip cancels. A new one appears. None of that reaches the file you downloaded at 6 a.m.

Why the API answer is incomplete

"Integrate with the broker API" is the usual answer to all of this, and it is a real answer for part of the problem.

When a broker has built an API and you have access to it, trips can flow in without anyone accepting them on screen, and changes can flow in during the day rather than sitting in a portal until someone refreshes it. That's genuinely better than retyping.

The limits are worth being clear about.

An API only exists where the broker built one. Large national brokers are more likely to have something; regional and state-specific brokers often don't. Access is usually something you have to be approved for, and the terms are between you and the broker — not something a software vendor can promise on your behalf.

An API also covers exactly one source. It does nothing for the facility that faxes, the case manager who emails, the group home that calls, or the second broker that hasn't built one. If most of your volume comes through two national brokers, a pipe for each of those covers most of your day. If your volume is spread across a national broker, two regional brokers, four facilities and a handful of direct-pay riders, two pipes leave most of your intake untouched.

So the question to ask about any dispatch system isn't only "does it connect to my broker." It's "for every place a trip can come from, what is the fastest path from there into the schedule."

The realistic version: many doors, each one short

Different sources need different doors. What matters is that each door is short — a step or two, not twenty minutes of typing.

Here is how EzMedTrip handles intake today through different options tailored to your reality.

File import. When a portal gives you a CSV or Excel export, you upload it. Columns get mapped once so the next file from the same source lands the same way.

Paste a table. Some portals let you select the trip list on screen and copy it, even with no export button. You paste that block in and it gets parsed into trips.

Screenshot read by AI. When a portal won't export and won't copy cleanly, you take a screenshot of the trip list and the system reads it into structured trips. You review what it pulled before it's committed.

Fax parsing. Facility schedules that arrive by fax get read and turned into trips for review, rather than retyped.

Email intake. Trips sent by email can be routed in the same way.

Standing orders. Recurring trips — the three-times-a-week dialysis run — get created once as a pattern instead of re-entered every week.

Duplicate detection. Because the same trip really does arrive twice when a facility faxes a schedule and the broker also assigns it, the system flags likely duplicates so the same rider doesn't end up on two manifests.

Be clear about what "automated" means here

These paths cut typing. They do not remove the person.

Somebody still logs into the portal and accepts the assignments. Somebody still uploads the file, pastes the table, or takes the screenshot. Somebody still glances at what came in before it goes live, because an address read off a blurry fax can be wrong and it's cheaper to catch that at intake than at the curb.

The honest framing is that manual import is faster manual work, not no work. The transcription goes away. The review does not, and shouldn't.

Same with intraday changes. When a broker updates a trip in their portal and there's no live connection, nothing tells your system on its own. Someone has to check the portal and bring the change over. Any vendor telling you otherwise, without a live connection to that specific broker, is describing something that isn't happening.

What to ask any vendor

Whether you're looking at us or anyone else, these questions separate what a system actually does from what a demo implies.

• Which brokers do you have a live connection to, by name? Is it a direct connection you maintain, or does it depend on my credentials and my approval from the broker?
• For brokers you don't connect to, what's the path? How many clicks and how many minutes for a typical day's trip list?
• What happens when a portal has no export button?
• Can you take in a faxed facility schedule? An emailed one? What does the person in my office have to do to each one?
• How do recurring trips work? Do I re-enter them every week?
• How do you catch the same trip arriving from two sources?
• When a trip changes in the broker's portal midday, how does that reach my dispatcher — automatically, or because someone checked?
• Who fixes it when an import reads something wrong, and how long does that take?

Write your own answers first. List every place a trip reaches you this week, including phone calls. Then make each vendor account for that whole list, not just the two names they've built for.