Consolidating Four Software Systems Into One Courier Operations Dashboard

Four systems, four versions of the truth

Transit Couriers is a courier and transport operator whose day-to-day work was spread across four separate software platforms. Dispatch lived in one. Delivery data in another. Finance in a third. Management reporting was assembled by hand from all of them.

Nothing was broken, exactly. Each system did its job. The problem was that answering an ordinary question — how did last week actually go — meant opening four tools, exporting from each, and reconciling the differences by hand before anyone could form a view.

That reconciliation is where the cost hides. It is not just the hours. It is that by the time the numbers agree, the week they describe is over.

The consolidation, not the rebuild

The instinct in this situation is to replace the four systems with one. That is a long, expensive project with a lot of change management attached, and it usually is not necessary.

What the operator needed was not one system. It was one dataset.

We connected the four software databases through API integrations and brought them into a single consolidated dataset, then built the reporting layer on top of that. The source systems kept doing what they were already good at. Dispatch stayed in the dispatch tool. Finance stayed in the finance tool. What changed is that the numbers stopped disagreeing, because they stopped being separate.

That distinction matters when you are scoping this kind of work:

Most operators who think they need the first one need the second.

Where the real work is

The API connections are the visible part of this job, but they are rarely the hard part. The hard part is deciding what a field means when four systems disagree about it.

A delivery might be marked complete in dispatch, unconfirmed in the delivery app, and uninvoiced in finance — all correct, all at the same moment, because each system is describing a different stage. Consolidating them without deciding which definition governs just moves the argument into the dashboard.

So the sequence we work in is:

Doing it in that order is what stops a dashboard becoming a fifth version of the truth.

The PDF pack is part of the system, not beside it

One detail worth calling out, because it is the part most reporting projects get wrong.

Plenty of businesses now have a dashboard and a weekly PDF pack, produced separately. Someone screenshots the dashboard, pastes it into a document, adds commentary, and sends it out. The pack immediately starts drifting from the live view, and within a month nobody is sure which one is current.

For this build, the PDF reports are generated by the dashboard system itself, from the same consolidated dataset. There is one set of numbers. The dashboard is how you interrogate them; the PDF is how you circulate them. Neither can contradict the other, because there is nothing to contradict.

That is what makes the reporting survive contact with a busy month. A pack that regenerates itself gets sent. A pack that needs an hour of assembly gets skipped, and then the rhythm is gone.

What this pattern suits

This shape of work fits when:

It fits less well when there is only one source system and the reporting problem is really a data-quality problem inside it. That is a different job, and worth diagnosing before anyone connects anything.

The starting point

If this is familiar, the useful first step is not a platform decision. It is a scoping conversation about which decisions the weekly numbers are supposed to support, and which sources have to agree before they can.

That is the work a Dashboard / Reporting Sprint is built around: map the current reporting pain, rebuild the weekly pack around decisions with owners, then decide whether deeper integration earns the next sprint.

The full build is written up in the Transit Couriers case study.