Skip to content

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

  • The dispatch board screen: a dense table of the day’s loads with columns for reference, customer, collection window, vehicle and status, and a filter panel down the left-hand side.
    Plate 01The dispatch board. Density was a requirement, not an oversight.
  • Parallel-run comparison report showing bookings created in the legacy products against the replacement system, with a variance column reading zero across the final three weeks.
    Plate 02Three weeks of zero variance was the gate for the cutover.
  • Deployment pipeline diagram showing build, automated tests, staging deployment, approval gate and staged production rollout with an automatic rollback path.
    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.

Clara Fernandes · Operations Director, Meridian Freight5 out of 5