40% less vehicle downtime: what changed in the fleet system

A fleet management system we built for a farmers' cooperative in Ethiopia reported 40% less unplanned vehicle downtime. The figure is ours and comes from one project. Our site does not publish the baseline behind it, so it tells you what one fleet saw and nothing about what yours would.

What problem did the cooperative have?

The cooperative had vehicles on the road every day to move its coffee, and decisions about them rested on delayed or incomplete data. According to the case study, that produced six linked problems. Deliveries ran late because nobody had live location data, and poor route planning pushed fuel consumption up. Vehicles were serviced only after something broke, so they failed without warning. Operations, accounting and fleet management each kept separate data. Without driver monitoring, safety standards were hard to enforce, and without fuel monitoring, theft and misuse were hard to spot.

The case study traces all six to the same starting point, which is decisions made on delayed or incomplete data. Downtime is the third of these. The other five matter for reading the result, because the system addressed all six together.

What did we build?

The logistics page describes the build as a fleet management system for a farmers' cooperative in Ethiopia: vehicle registration, live tracking, maintenance, drivers and fuel, with ERP and accounting integration and training for the team. The case study splits the work into four steps.

1. Discovery and an integration plan. Our engineers mapped the data silos between the existing ERP and accounting systems, so that every kilometre driven and every litre of fuel used flows into one set of reports.

2. Live tracking and route optimisation. A core module for real-time vehicle tracking and automated route planning.

3. Proactive maintenance. Maintenance triggers and scheduling. The page says the system tracks each vehicle's condition and books a service before it fails, so more of the fleet is available.

4. Monitoring and analytics. Monitoring of driver behaviour and fuel use, so the team can spot unsafe driving and fuel loss early.

The case study lists a duration of 6 months, and the logistics page says the system went live six months after kickoff.

What does the 40% measure?

The case study lists the result as "unplanned vehicle downtime down 40%". The logistics page words it as "vehicle downtime fell by 40%". We take both as one figure and use the case study's wording, since it is the detailed page.

Several things are not on any page we publish: the starting level of downtime (in hours, days or share of fleet), the period before and after that was compared, the number of vehicles, and how downtime was counted. A vehicle waiting for a part, for example, could count from the breakdown or from the workshop booking.

Without these, 40% cannot be turned into days of vehicle availability, and a reader cannot tell whether the cooperative started from a bad position or an ordinary one. A fleet that lost 10 days per vehicle per year and one that lost 40 days would see very different savings from the same percentage.

The same applies to the neighbouring figures. The case study says fuel consumption fell 20%. The logistics page says fuel expenses fell 20%. Consumption (litres) and expense (money) are different measures, because prices move. We use the case study's wording and list the difference under what we could not confirm. The case page also credits stopping fuel theft and misuse with a further 10% in costs, but it does not say whether that sits inside the 20% or on top of it.

Which part of the system did the work?

The case page names the maintenance step as the one that moved fleet care from reactive to proactive, and says it makes more of the fleet available. It publishes no breakdown of the 40% by module.

Our reading is that maintenance scheduling did most of the work on downtime. It is the only step described as aimed at failures that arrive without warning. Tracking and fuel monitoring may feed the schedule, but the case page does not say so. This reading rests on the descriptions alone and is not a statement from the project record.

The 30% fall in delivery delays raises the same question. Fewer breakdowns would cut delays, and so would better routes and live positions. The page does not separate them.

What should you measure before building something similar?

This section is our addition. The case study does not give a method, so the list below is what we would ask a fleet owner to write down before a project starts, so that a later percentage means something.

1. Define unplanned downtime in one sentence. Decide when the clock starts (breakdown, report to the workshop, or vehicle off the road) and when it stops.

2. Record the baseline for a full period. A month of data hides seasonal use. A full year, or at least one full business cycle, is better.

3. Count vehicles in service, not only vehicles owned. A fleet that grew during the project will show a different percentage from one that did not.

4. Record what one day of downtime costs your business. The same lost day costs different amounts in a busy week and a quiet one.

5. Separate fuel litres from fuel cost. Log both, so a price change does not read as a saving.

6. Decide which change you will credit to which module, and log the date each module went live. The case page cannot answer this question, and a fleet that stages the roll-out can.

7. Plan for driver data early. Our logistics page says positions and trips of named drivers are personal data, and that we collect only what the purpose needs and delete it on a schedule you set. A lawyer should confirm what applies to a specific fleet.

If you want a system built around your own workflows and connected to your ERP and accounting, our custom software development page describes what we build.

What we could not confirm

No page we publish states the baseline, period, vehicle count or counting rule for the 40% downtime figure, and there is no independent audit or third-party measurement, so all figures are first-party. The split of the downtime result between maintenance scheduling, tracking, routing and monitoring is our reading, not a published breakdown.

Two points about fuel are open. We do not know whether the further 10% cost saving from stopping fuel theft sits inside the 20% fuel result or on top of it, nor whether fuel fell 20% in litres or in money: the case study says consumption, and the logistics page says expenses. We also cannot say whether the same result would repeat in another fleet, and the logistics page says results depend on the fleet and its starting point.