Why we built CSV bulk import into DropPilot

The gap between what we built and how people actually work

When we first launched DropPilot, the core promise was simple: smarter route planning for delivery drivers and small teams. We obsessed over the optimisation engine (nearest-neighbour with 2-opt refinement), the live traffic integration with Google Directions, the proof-of-delivery capture. All of that still matters. But we missed something obvious.

Dispatchers aren't sitting at a desk, leisurely adding one address at a time. They're juggling phone calls, customer changes, vehicle breakdowns, and a spreadsheet that came from a customer's ordering system or their own legacy database. Many of them already have their jobs listed in CSV format. Asking them to manually enter each one felt like we were solving a real problem (route planning) while creating an artificial one (data entry).

The dispatcher's message sat with me for weeks. I started asking other fleet managers how they currently build their daily routes. Most of them said the same thing, in different words: 'I have my addresses. I need to assign them to drivers and see what the actual time looks like.' None of them said, 'I love typing.'

Building the feature meant understanding dispatch reality

CSV bulk import sounds straightforward on paper. In practice, it's where real-world chaos lives. We had to ask: what format do dispatchers actually have? How messy is their data? What columns matter, and what can we infer?

We talked to couriers, food delivery services, field service teams, and logistics managers. Their CSVs looked different every time. Some had postal codes and street address on separate columns. Some had customer names we didn't need. Some had notes like 'gate code 4521' crammed into an address field. One had GPS coordinates instead of addresses (which we could use directly, but most didn't).

We designed the import to be flexible but strict where it mattered. You need an address. You can add a customer name, a phone number, a note. We validate the address against Google's geocoding, so if something's malformed or missing, the dispatcher sees that before they commit 50 stops to a route. We didn't want a team uploading their entire morning and then discovering half of it was garbage.

The feature shipped in our Plus tier and above because the use case is simple: if you're managing multiple drivers and dozens of stops, you're probably past the free plan anyway. For dispatchers with 30 or more rounds a month and 50 stops per round, bulk import saves hours every single week.

What changed once dispatchers could upload in bulk

Two months after launch, we got another message from that same dispatcher. 'I uploaded 290 addresses this morning. Took five minutes. The app planned nine routes and told me I could do it in two vans instead of three. Saved us a van day.' She was matter-of-fact about it, but that's exactly what we hoped for.

We noticed something else in the data: teams using bulk import ran more routes overall. Not because they were trying harder, but because the friction was gone. If you can upload a fresh CSV every morning in minutes, you're more likely to use the app daily, which means you're catching traffic problems in real time, rerouting when someone's delayed, capturing proof of delivery automatically. The feature didn't just save time. It changed the behaviour.

Fleet managers started using it differently too. One team used bulk import to test scenarios. They'd upload the same job list twice, assign one to their morning shift and one to the afternoon, and compare which split worked better. They got smarter about when to run their routes, not just how.

The constraint that shaped the whole decision

We could have built a web-based dispatch portal where teams upload CSVs, manage drivers, and see everything in real time. That's the enterprise play. But we didn't. We built bulk import into the mobile app, on the dispatcher's phone or tablet, because that's where the decisions happen. A dispatcher doesn't sit at a desk all day. They're in the office for 20 minutes in the morning, and then they're moving.

That constraint shaped everything. The import had to work offline so you could load your CSV before the day gets hectic. The routes had to update instantly so you see the impact on your fleet immediately. The validation had to be forgiving enough that a messy spreadsheet doesn't become a blocker, but strict enough that you're not sending drivers to fake addresses.

We added CSV export too, so teams could pull their completed routes and proof-of-delivery data back out, feeding it into their own systems. DropPilot isn't trying to replace a dispatch system. It's trying to be the bit of the puzzle where drivers get smarter routes and dispatchers get honest time estimates.

Why this matters for how we think about what comes next

Building CSV bulk import taught us something we probably should have known at the start: features that solve real friction in a real workflow beat features that look good on a product page. A dispatcher with 200 stops and 15 minutes to plan her morning doesn't want an elegant interface. She wants her data in and a better plan out, fast.

It also meant we had to stay disciplined about scope. We didn't build a full dispatch portal. We didn't add complex permission systems or multi-level approvals. We built the thing that solves one specific pain point for the teams that felt it most acutely, and we made it work within the constraints of how those teams actually operate.

There's a temptation in building software to assume that more features, more flexibility, more integration options equal more value. Usually the opposite is true. A team trying to run 200 stops in a van doesn't want optionality. They want the thing that gets them out the door five minutes earlier with a smarter route.