AccAnalysisAccAnalysis
Transportation & Logistics

From a weekly plan on paper to a fleet you can see today

A B2B supply-chain vendor planned its delivery fleet once a week and then had very little idea what happened next. We delivered a driver mobile application and a management-side tour-planning capability on its operational system.

At a glance
Status
Delivered
Region
Germany
Engagement model
Dedicated team

Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.

The organisation

Context

A business-to-business supply-chain vendor operating its own delivery-truck fleet. Tours were planned manually on a weekly cycle.

Once a truck left, information came back by phone or at the end of the day, and returns were handled on paper.

The brief

The problem

  • Planning happened weekly, so any change during the week was handled by improvisation.
  • Dispatchers had no view of where a tour had got to or what had gone wrong.
  • Drivers recorded deliveries, exceptions and B2B returns on paper, which someone re-keyed later.
  • Coordination between office and driver ran over phone calls, leaving no record.
  • The delay between work performed and work recorded made every downstream process late.
The work

What we built

A driver mobile application

Connected to the operational system, carrying the day's tour, delivery confirmation, exception capture and B2B returns — designed for a cab, not a desk.

A management-facing tour-planning capability

In the operational system, so vehicles, drivers and routes are coordinated in the same place the orders live.

A continuous feedback loop

What the driver records updates the plan and the operational record immediately, rather than at the end of a shift.

A delivery pipeline for the mobile application

So app releases are a routine, repeatable step rather than an event.

Method

How we delivered it

  1. 1

    Ride along with the process

    Map how planning, dispatch and return handling actually work before designing either half.

  2. 2

    Foundation

    Environments, source control, an automated build and release pipeline for the app.

  3. 3

    Planning side first

    So there was something for the app to connect to.

  4. 4

    Mobile application

    Tested by real drivers on real routes, with the offline and glove-friendly constraints treated as design requirements.

  5. 5

    Pilot with one depot

    Through a full week.

  6. 6

    Roll-out

    Depot by depot.

Sequence

How it was phased

PhaseDurationWhat happens
1Discovery
2 wks

Planning, dispatch and returns mapped with the team

2Foundation
2 wks

Environments, CI/CD pipeline, app distribution

3Tour planning
3–4 wks

Vehicles, drivers, routes and orders in one place

4Driver app
5–7 wks

Tour view, delivery confirmation, exceptions, returns

5Pilot depot
2 wks

One depot, one full week, real drivers

6Roll-out
ongoing

Depot by depot

Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.

Hand-over

What the client keeps

  • The mobile application source in their own repository and developer accounts
  • The planning configuration
  • The build and release pipeline
  • Integration documentation
Stack
OdooFlutterPythonGitHub ActionsPostgreSQL
Keep reading

Related

Related case studies

Tell us what your current system can't do, and we'll tell you what it would take to change that.