Courier Software Problems: The 7 That Leak Margin Every Week, and How to Avoid Them

Why does the customer portal get built before the dispatch board works?

The scope failure in courier is almost always the customer-facing layer arriving first. It is easy to see why. The portal is what your sales team can show a prospect, it is what the owner imagines when picturing the new system, and it demos beautifully. So the portal, the tracking page and the branded emails get built, and the dispatch board and driver app arrive later and rushed.

The result is predictable. Customers get a portal that shows them status derived from data your dispatchers do not yet trust, drivers keep working around a half-finished app, and the first time a tracking page shows a stop as delivered that has not been delivered, an account manager spends a week rebuilding credibility.

The sequencing that works is the reverse and it is deliberate. Release one is the dispatch board with contract-aware assignment, the offline-first driver app with configurable proof of delivery capture, and the rating engine producing a billable line and a payable line. That is the spine. Nothing customer-facing ships until dispatchers and drivers trust it, because the portal is only as good as the data underneath it and there is no way to fake that.

The test to apply to any proposed release one feature: if the operation would still function without it on Monday morning, it belongs in phase two. Customer portals pass that test. Offline proof of delivery does not.

What goes wrong when rate cards and open receivables come off the legacy system?

Migrating from CXT or Key Software's Xcelerator is not a data export, it is an audit of agreements nobody has read in years.

What you will find: accounts with rate structures that do not match any signed contract, because a dispatcher added a special rate in 2016 and it stuck. Fuel surcharge configured three different ways across similar accounts. Waiting time rules that reference an increment the current system cannot actually apply, so a clerk has been doing it by hand. Redelivery fees that are configured but always waived. Two customer records for the same company because a purchasing entity changed name. And an open receivables balance that does not tie to your accounting system by a few thousand dollars for reasons predating anyone currently employed.

The failure mode is a clean technical migration that carries all of it across. You now have the same mess in a new system, plus a project that was supposed to fix it.

Treat rate card cleanup as a distinct workstream with an owner from operations, not from the development team. Extract every account's effective pricing, compare it to the signed agreement, and produce a list of discrepancies for someone to decide on. Reconcile open receivables line by line before cutover, not after. Bring historical proof of delivery across as read-only archived records so old disputes remain answerable, and accept that this alone typically adds three to six weeks to the timeline. Run both systems in parallel for two to four weeks with new jobs in the new system while legacy billing finishes its cycle.

Why do the customer and accounting integrations break after launch?

Two integration classes carry the money here, and they fail differently.

Electronic data interchange connections with enterprise customers break on their calendar, not yours. Each connection is a couple of weeks of build plus their testing schedule, which you do not control, and a hospital system or national logistics provider will not accelerate for you. The real failure is committing a go live date that assumes three customer connections land in parallel. They will not, and the account that slips is usually the one you promised the system for.

Accounting integration breaks on mapping and on timing. Posting invoices into QuickBooks or NetSuite through the interface rather than by file import is the right approach, and it fails when a new accessorial has no mapped account, when a credit needs a different treatment than a negative invoice, or when a batch posts against a closed period. It fails quietly, and your controller finds out at month end.

The controls: sequence customer connections one at a time and put their testing calendar in your project plan explicitly. Require an unmapped-item queue with a dollar value rather than a silent default account. Reconcile invoiced totals against posted totals daily for the first two months. And have the developer name, in writing, which status codes map to each customer's milestone vocabulary, because that mapping is exactly where a customer's automated exception reports start firing at your account manager.

What happens when proof of delivery is not built as an evidence chain?

Most courier operations already have proof of delivery in some form. Very few have evidence.

The distinction matters the moment a claim arrives. An attachment on a stop record shows a signature. An evidence chain shows that this artefact was captured on this device, at this position, at this time, by this driver, on this app version, and has not been altered since. When a surgical instrument shipment goes missing or a filing deadline is contested, the second one ends the conversation and the first one starts an argument.

The second failure is treating capture requirements as uniform. A standard envelope needs a signature. Medical courier work needs a printed recipient name, a role, a cooler temperature and a photo of the sealed container. Pharmacy work needs a barcode scan per tote so the count is provable. Legal work needs a photo of the stamped copy. A single capture screen for all of it either overburdens the envelope run or under-documents the specimen run, and drivers optimise for speed, so you get the second one.

Build capture as a per service level specification, write artefacts offline first to the device, hash them, then sync with the position fix, timestamp, driver identity and app version into an append-only record. Corrections create a new linked record with a reason code rather than editing the original. This is also what makes a business associate agreement for medical work defensible, because the audit trail exists as a consequence of the data model rather than because somebody remembered.

Should you build custom or configure what you already own?

A meaningful share of courier operators reading this should not build, and the line is clear.

If you run under roughly 150 jobs a day on standard point to point work, with fewer than four distinct pricing models, and no customer has ever asked you for an interface, buy. OnFleet, Circuit for Teams, Onro or Dispatch Science will run your operation for a few hundred to a couple of thousand dollars a month, and a custom build at that scale competes directly with hiring drivers. Tighten dispatch discipline and grow.

It is also worth checking whether the tool you already have is configured properly. Many operators run an off-the-shelf platform on defaults, with service levels undefined, capture requirements uniform and no account-level configuration, then conclude the tool cannot do it. Sometimes that is true. Often it has not been asked.

The signals that flip it are countable and you probably have three. You employ someone whose actual job is moving data between two systems. You cannot produce per-job margin by account, so renewals are priced blind. You have lost or declined an enterprise account in the last year over an integration or proof of delivery requirement. Your rate card has structures your software cannot express, so someone applies them by hand every billing cycle. Or your differentiator is an operational capability, a two hour guarantee, temperature controlled chain of custody, a dedicated route model, that your software cannot represent at all.

How do hidden costs get into the quote?

Five omissions turn up with enough regularity to name.

Rate card complexity, which is the biggest single driver in this category. Every hand-negotiated legacy account adds build days, and a book with a dozen pricing structures makes the rating engine a project rather than a module.

Customer connections, priced per connection including their testing calendar. A quote that says integration support without naming the customers and the formats is quoting nothing.

Offline reliability. Making sync genuinely dependable across bad networks and inexpensive Android hardware is expensive engineering, and it is the single line you must not trim, because trimming it returns you to texted photographs.

Compliance scope. Medical courier work brings a business associate agreement, chain of custody obligations for controlled or legal work, and the audit logging that goes with both. Ask specifically how patient identifiers are scrubbed before anything reaches an error reporting service, since that is where teams without healthcare experience leak them.

And migration from the legacy system, which is three to six weeks and a rate card audit rather than a data load. Add 15 to 20 per cent of build cost annually for hosting, support and change once live.

What separates a build that works from one that fails here?

Four things, and the first is a modelling decision made in the first week.

The hard object in courier is the contract, not the stop. If a developer models orders and deliveries as flat records, they have built food delivery. The job record has to carry the rate, the service level, the penalty terms, the capture specification and the driver agreement rate, joined at assignment time, because that is what lets the dispatch board show margin at risk rather than distance. Ask any candidate to whiteboard a job with a pickup window, a hard deadline, three barcoded pieces, a waiting time accessorial, a billable rate from one contract and a payable rate from another, plus a legal hold on the proof of delivery.

Second, one rating engine with two consumers. Billable and payable lines written in the same transaction from the same captured data is what finally produces per-job margin, and per-job margin is usually what pays for the project. Two engines drift, and the drift is where the margin goes.

Third, shadow mode on anything automated. If you use document extraction to turn emailed run sheets into draft jobs, run it for about three weeks measuring field-level accuracy per customer before anything auto-releases, and never auto-dispatch an extracted job on day one. Operators who skip that send a driver to the wrong suite in week two, and the customer service team never trusts the queue again.

Fourth, parallel run with a subset of drivers before the fleet. Two to three weeks with your most and least patient drivers, on real jobs, surfaces the reconnect and sync problems that no test environment produces. Fix those before anyone else touches it.