Fleet agreements, bonuses and invoices taken out of the paper loop

A fleet agreement is a deal with a company that buys vehicles in volume. The manufacturer sets bonus terms and the customer buys through the dealer network. It makes commercial sense and it is an administrative nightmare, because every agreement has its own terms and settlement runs across three parties at once.

What it looked like before

The process was paper. Terms were agreed in a document, the document circulated between manufacturer, dealer and customer, invoices were approved by signature, and whoever was holding the folder knew the state of play.

Three things cost the most. Cycle time, because each approval meant days in the post. Uncertainty, because nobody had a current picture of which invoices were approved and which were waiting. And missing data, because a sales summary for a given agreement had to be assembled by hand from several sources.

What we built

Bonus term configuration. Each fleet customer has their own set of terms, configured in the system instead of described in an annex.

Invoice approval online. The invoice enters the system and is approved where its link to the agreement is visible. A cycle measured in working days becomes one measured in hours.

Statistics view. The current state of an agreement – how much has been bought, how far to the next bonus threshold.

Sales reports for customers. Generated from the system, in the same shape for everyone, rather than assembled by hand for each conversation.

An FAQ section. Dealers ask the same questions repeatedly, so the answers sit in the system next to the process they concern.

What changes day to day

Digitising a paper loop pays off in two places in the business.

The first is operational and obvious: a shorter approval cycle and less retyping. The second is commercial and less obvious. When a salesperson can see that a customer is twelve vehicles short of a bonus threshold, they have a concrete reason to call. That number was always derivable before, but nobody derived it, because it meant gathering data from several places.

We are not quoting savings figures – the client did not share them.

Why we built it this way

The company already ran older applications based on an earlier generation of web components, and replacing everything at once was out of the question. The new interface therefore had to coexist with the old one in a single ecosystem rather than replace it overnight. That is the typical situation in a large organisation: modernisation only works when it can be done in pieces, without stopping the day job.