

23
broker templates migrated
2
weeks against 6 weeks scoped
4
to 5 vendors evaluated
Unlimited
imports, on a 3-year term
About Bambi
Bambi provides AI-powered NEMT scheduling, dispatch, routing and billing software, used by more than 700 fleet owners and operators.
Bambi had scoped a month and a half to move its data importer. Twenty-three broker templates, every one of them carrying protected health information, all landing on schedules that dispatchers were working that morning. It took two weeks.
| Company | Bambi, AI-powered NEMT scheduling, dispatch, routing and billing |
| Industry | Healthcare logistics, non-emergency medical transportation |
| Scale | 700+ fleet owners and operators, single vehicle up to 300-vehicle fleets |
| Interviewed | Charles Henick, CTO and Co-Founder, LinkedIn |
| Replaced | OneSchema |
| Agreement | Three-year agreement with Dromo, unlimited imports |
Every trip is protected health information
Bambi runs the whole operation for non-emergency medical transportation providers. Scheduling, route optimization, live dispatch, billing and claims, and a driver app. More than 700 fleet owners run on it, moving Medicaid, dialysis, PACE and private-pay passengers.
Bambi works with brokers and health plans across the country, including MTM, Modivcare, Verida, Alivi, Call the Car, Provide A Ride, SafeRide Health, Access2Care, Tennessee Carriers, American Logistics and a long tail of regional brokers. Some send trips through live API integrations. Many still send files, and the ones that do each have their own CSV template. Twenty-three of them, and no two agree on anything. Column names differ, date formats differ, and a field that one broker requires is absent from the next.
Those files are not a back-office concern. They land on schedules dispatchers are working right now, and they are full of PHI.
Fundamentally a trip is PHI. You have someone's name, the fact that they require medical service, and the address where they are being picked up and dropped off.
Charles Henick, CTO and Co-Founder, Bambi
The two kinds of importer, and why the difference decides everything
Most CSV importers are bought for a job that happens once per customer. An implementation or onboarding team takes a spreadsheet from a new account, maps the columns, loads it, and moves on. The people using the tool work at the company that bought it. They are trained on it, they do this weekly, and when a file fails someone walks over to the engineer who owns it.
Bambi bought the other kind. Its importer is part of the product, in front of its own users, running every day. The people using it are dispatchers and fleet operators with a schedule to fill in the next hour. Nobody trains them, nobody reads a tooltip, and a failed file is not a support ticket, it is a trip that does not get assigned.
That second shape is far more common than it looks. It turns up wherever a business runs on files produced by parties it does not control:
- Partner and broker feeds, like Bambi's 23 transportation brokers, where each counterparty has its own template and no interest in changing it
- Supplier and marketplace catalogs, where every vendor exports from a different system
- Payroll, benefits and HR census files that move between systems every cycle
- Field service asset registers and work order lists arriving as customer spreadsheets
- Financial and transaction files, where a mis-mapped column is a reconciliation problem rather than a formatting one
Bambi's requirements followed from that. The importer had to carry Bambi's brand rather than a vendor's, because a dispatcher should never notice they have left the product. Validation had to catch a bad date format or a missing trip identifier at the moment of upload, not in a log an engineer reads the next morning. And the error a user sees has to be one that the user can fix without calling anyone, on a schedule that still has to go out.
Why Bambi went looking
Bambi had been running an embedded importer from OneSchema on an annual agreement priced as a platform fee. As Bambi grew, that structure made forward planning hard. The issue was never the price itself. It was that nobody could say in advance what it would be.
Not knowing how much our bill was going to be from year to year, and having to resubmit for a quote based on estimated growth and usage, did not feel great.
Charles Henick, CTO and Co-Founder, Bambi
The renewal ran on estimates. Bambi would submit a forecast of the files it expected to process, and a number would come back. Charles's objection was not the commitment. He has said he would not have minded committing for years, given a deal that showed how the price was going to move. It was that the mechanism was opaque, and that the input was a guess about his own growth.
That is a structural problem, not a vendor quirk. When an importer is part of your product, its volume is a function of how many customers you win and how active they are. A model priced against a forecast of that number hands your budget to the part of your business you least control.
What predictable pricing actually looks like
Dromo publishes its numbers. The Professional plan is listed at $599 a month on the pricing page, so a team can see what it costs before speaking to anyone. Enterprise agreements, which is what Bambi signed, are negotiated, and they can include unlimited production imports. OneSchema's pricing page lists its tiers and routes every one of them to a demo request, with no figures published.
Two questions worth putting to any importer vendor, whoever you end up choosing:
- What does this cost at ten times my current volume, and can I work that out without booking a call?
- Three years out, is the price something I can model, or something I have to ask for?
Bambi got both answers in one conversation. Unlimited imports, so growth stops being a billing event, and a three-year agreement with the price movement written into it, so the number three years out was visible on day one.
When you told me you have unlimited files, and that you were willing to do a three-year term with a realistic price ramp over the course of it, it was ‘sign me up.'
Charles Henick, CTO and Co-Founder, Bambi
Bambi built the exit before it chose the door
Rather than shop for a replacement and hope, the team did something more disciplined. While evaluating four to five vendors, Bambi's engineers refactored the importer integration behind an abstraction layer of their own, so that any vendor could be dropped in behind a stable internal interface. Front-end engineers did most of that work, with one back-end engineer on the foundations.
This is the part worth copying whether or not you switch anything. Most teams discover during a migration how much vendor-specific code has leaked into their application, because the integration was written against one SDK and never meant to be moved. Doing the separation first turns a vendor change from a rewrite into a swap, and it gives you real leverage at renewal, because the cost of leaving is now known rather than feared.
It also set the requirement that decided the shortlist. Bambi did not want a vendor UI holding its configuration.
We do not even use the Dromo UI for storing our templates. Everything is stored in code, all the transformers are written in code. We wanted it fully version controlled and managed in our own GitHub repository, instead of split across two platforms.
Charles Henick, CTO and Co-Founder, Bambi
Dromo supports schemas and transformations defined entirely in code, which is how Bambi runs all 23 of its broker templates. Field definitions, validation rules and row transformations live in Bambi's own repository, go through the same review as the rest of the codebase, and ship on the same deploy. Adding a new broker is a pull request. See the embedded importer documentation for how that is set up.
Where the file actually goes
For a platform where every file carries PHI, the certificate is the floor rather than the answer. Dromo is SOC 2 Type II certified and HIPAA compliant, and BAAs are available. Private Mode processes the file in the end user's browser, so file contents never transit Dromo's servers, and teams with stricter requirements can run Dromo self-hosted inside their own infrastructure.
Every broker file we touch has PHI in it. Being able to say the file never leaves our infrastructure is a much easier conversation than pointing at a certificate.
Charles Henick, CTO and Co-Founder, Bambi
That distinction matters to any team whose files carry regulated data, whether that is health information, financial records or personal data under GDPR. It is the difference between a vendor promising to look after your data and a vendor never holding it. More detail on the data privacy page.
The migration
Twenty-three broker templates moved. The team cut over on the abstraction layer it had already built, rewriting each template as a schema in code, with Dromo and Bambi engineers working out of a shared Slack channel throughout.
Questions raised during the move were answered in under five minutes. Where Bambi needed behavior the product did not have yet, Dromo shipped it during the migration rather than adding it to a roadmap. Two weeks after starting, every broker template was running in production.
I was scoping at least a month and a half of transition time, and we crammed it into about a week and a half. The cutover went a lot smoother than I thought it would.
Charles Henick, CTO and Co-Founder, Bambi
What Bambi runs today
All 23 broker templates run through Dromo in production, configured in code and version controlled in Bambi's own repository. Import volume is unlimited under the agreement, so onboarding a new broker is a schema, not a budget conversation. The engineering time that would have gone into managing an importer relationship goes into the product instead.
I am happy to not have to worry about building/maintaining/managing our own CSV import, and to actually build new features in our product.
Charles Henick, CTO and Co-Founder, Bambi
Common questions
Why did Bambi switch from OneSchema to Dromo?
Pricing predictability and developer control. Bambi could not see how its importer bill would move as it grew, and it wanted schemas and transformers defined in code and version controlled in its own repository rather than held in a vendor UI. Bambi moved 23 broker templates to Dromo in two weeks and signed a three-year agreement with unlimited imports.
What is the difference between an internal data importer and an embedded one?
An internal importer is used by your own onboarding or implementation team, usually once per customer, by people trained on the tool. An embedded importer is part of your product and used by your customers, often daily, by people who will never be trained on it. The second has a much higher bar for validation, error messaging and interface quality, because a failure is visible to your user rather than to your staff.
Can a data importer handle protected health information?
Yes, if the architecture supports it. Dromo is SOC 2 Type II certified and HIPAA compliant, and BAAs are available. Private Mode runs the import in the end user's browser so file contents never transit Dromo's servers, and self-hosted deployment is available for teams that require it. See the data privacy page.
How long does it take to switch data import vendors?
Bambi scoped a month and a half and did it in two weeks, across 23 broker templates. The single biggest accelerator was refactoring the integration behind its own abstraction layer before choosing a vendor, which is worth doing whether or not you switch.
Can Dromo schemas be defined in code?
Yes. Bambi defines every schema and transformer in code, version controlled in its own GitHub repository, and does not use the Dromo UI for configuration at all. Adding a broker template is a pull request rather than a change in a vendor console. See the developer documentation.
Evaluating a switch? Bring us your ugliest broker file and we will run it in front of you.
See pricing | Compare Dromo and OneSchema | Data privacy and compliance