Meridian Freight
One dispatch system replacing two products and a spreadsheet
Meridian booked freight across a transport management product, a customer portal from a different vendor, and a spreadsheet that reconciled the two. We replaced all three with one system. Booking-to-manifest went from a 22-minute median to under four, and the reconciliation step stopped existing.
- Client
- Meridian Freight
- Sector
- Logistics
- Run
- 7 months · Feb–Aug 2025
- Filed
- 2025-09-08
- Capability
- Custom software development · .NET development · Cloud and Azure solutions · DevOps and IT infrastructure
- Stack
- .NET 8 · ASP.NET Core · C# · SQL Server 2022 · Azure App Service · Azure Service Bus · React · TypeScript · Bicep · Azure DevOps

Impact
22 → 4 min
Median booking-to-manifest time
6% → 0.2%
Booking mismatch rate after parallel run
11 / week
Deployments, up from one a month
Challenge
Logistics
7 months · Feb–Aug 2025
Every booking was entered twice — once in the transport management system and once in the portal the customer could see — and a supervisor reconciled the two each evening against a spreadsheet. The double entry produced a 6% mismatch rate, which surfaced as a customer complaint roughly forty times a month. Neither vendor would expose an API on a timescale that mattered, and the transport product was two major versions behind its supported release. Two previous attempts to integrate the systems had been abandoned, the second after four months.
Solution
We spent the first fortnight in the dispatch office rather than in requirements workshops, and found that half the documented process had not been followed since 2019. The build was a single .NET 8 application with one booking record and one state machine, delivered in fourteen fortnightly increments to a staging environment the dispatch team could log into. The legacy products stayed authoritative for the first four months while both systems ran in parallel and a nightly job compared them; the spreadsheet reconciliation continued in that period, and it was the reconciliation report going to zero variance for three consecutive weeks that triggered the switch. Customer-facing tracking moved last, behind a routing layer, so the portal URL never changed.
Plates

Plate 01The dispatch board. Density was a requirement, not an oversight. 
Plate 02Three weeks of zero variance was the gate for the cutover. 
Plate 03Eleven deployments a week by month four, with rollback proven in a drill.
Testimony
They spent the first fortnight watching our dispatchers work instead of writing anything. Half the requirements we had given them turned out to describe a process nobody had followed since 2019.