XPULSEis coming.

The dot stops moving

A dispatcher watches a tanker cross a map. The route was planned, the vehicle is on time, the customer is expecting product. Order data, planning data and telematics have all done their job.

Then the dot arrives, and the screen goes quiet.

What happens next is the part of the journey that actually earns the money. The hose is connected. Access to the tank is checked. Product moves. A quantity is measured. A ticket is issued and an acknowledgement is collected. These are the minutes in which product, customer and proof finally meet, and in many operations they are also the minutes that leave the least usable trace.

The journey to the customer may be visible almost continuously. The delivery itself can still depend on a person reading one screen, entering a number into another device, explaining an exception by telephone, and carrying a paper record back into the billing process.

The problem is not a weak component

Each individual part of this usually works. The meter measures. The vehicle system controls. The driver knows the procedure and has done it several thousand times. The office software creates the order and the invoice.

The weakness is in the handover between capable components, and handovers are nobody’s product. No supplier sells them, no line item covers them, and no single system records what they cost.

That is why "more data" is not automatically an answer. A modern vehicle can produce a great deal of data and still leave the decisive delivery context fragmented. What matters is not volume. It is whether order, vehicle, product, metering event and proof remain recognisable as one operational sequence.

Small at one stop, structural across a network

At a single delivery, copying a value or making one clarification call is trivial. Nobody escalates it. Nobody logs it.

Repeated across every stop, every route and every working week, those small breaks stop being incidents and become the operating model. They consume driver time, but the cost does not stay with the driver. Dispatch waits for an answer. Customer service explains a delay. Administration reconciles a ticket. Service staff try to work out whether an interruption was caused by process, equipment or missing information.

The largest losses in a digital supply chain tend to live in exactly these ordinary transitions, and they are difficult to see precisely because no one system owns them.

Continuity has to reach the delivery point

A connected process does not mean every function depends on a permanent network connection. Local operation remains essential on a vehicle. Connectivity should preserve context, support synchronisation and put the right information in front of the right people, without making the physical delivery dependent on ideal reception.

It also does not mean replacing everything that works today. Most fleets run mixed vehicle generations and equipment from several suppliers, and most sites do too. Continuity has to begin with the installed environment, not with the assumption of a new fleet and a new forecourt.

The useful question is therefore not "how digital is our logistics chain?" It is more specific, and more uncomfortable:

Does the delivery remain one process from the order to the proof, or does it dissolve into disconnected moments in the last ten metres?

What this looks like from where you sit

• Fleet operators and distributors: the last ten metres are where your margin is decided and where your disputes originate, but they are usually the least instrumented part of the route.
• Site and network operators: you receive the consequences of decisions made in someone else’s vehicle and someone else’s software. Part 3 returns to this.
• Vehicle builders and integrators: the handover is designed, or it is inherited. It is rarely neutral.
• Service organisations: every gap in context becomes a diagnostic phone call later.

See the answer in Kassel

Over the coming weeks this series examines four of these operational gaps: the last ten metres, the paperwork that stays open after the delivery, the integration decisions a site inherits without ever making them, and the cost that keeps moving when a system stops.

Secu-Tech shows its answer at ETX in Kassel, 17 to 19 September 2026.

Two endings

At 14:40 the physical work is finished. The hose is disconnected, the ticket is produced, the vehicle moves to the next stop.

Three weeks later, the same delivery opens again. A quantity has been queried. The customer has a photographed ticket. The office has a record from the order system. The measured value sits in another source. Someone asks the driver what happened, but the route has since contained dozens of stops and the detail is gone.

Nothing here is dramatic. It is an email thread, a short call, a copied attachment, perhaps a credit note. But it exposes a structural divide: the physical event ends when product has moved safely, while the commercial event ends only when order, measured quantity, delivery record, customer acknowledgement and invoice all agree.

Most operations measure the first ending carefully and the second one hardly at all.

Four records are not the same as one event

Several records around one delivery is not automatically a problem. Different systems carry different legal, technical and commercial responsibilities, and collapsing them into a single database is neither realistic nor desirable.

The problem starts when those records have to be reconnected by hand, because they share no clear event identity and not enough common context.

A ticket shows a quantity. The planning system knows the order. The vehicle knows the compartment and the product. The customer holds an acknowledgement or a complaint. If these cannot be brought together quickly, a straightforward question turns into an investigation, and the investigation costs more than the disputed amount.

Late questions are especially expensive because context decays. The people who were present have moved on. A temporary exception may never have reached the final document. The longer a transaction stays open, the more work is needed to rebuild what was obvious at the delivery point.

This is a design problem, not a discipline problem

The instinctive response is to ask people to be more careful. Write the number down. Check the ticket. Confirm before leaving.

That response fails predictably, because it adds work at the exact moment when workload is highest and attention is lowest, and because it makes accuracy depend on the least supported person in the chain.

A better model starts from the event rather than the paperwork: one operational event that produces consistent information for the systems around it. Not one system for everything, but one recognisable delivery across metering, vehicle, customer proof and office processing.

The distinction matters more than it sounds. A large central platform can still receive incomplete or ambiguous data. A modest local system can create real continuity if the event is captured clearly, linked to the right context and passed on through defined interfaces.

Language discipline

Traceability invites overclaiming, so it is worth being precise about what any industrial record can and cannot be.

No event record should be described as legally immutable or court-proof without specific technical and legal validation for that jurisdiction and that use. The practical target is more modest and more useful: relevant process, status, operator and diagnostic information should be available to reconstruct what happened, and should be hard to lose by accident.

For the driver, that reduces the need to explain old stops from memory. For the office, it reduces document matching. For the customer, it shortens the path from question to answer, which is usually what they actually wanted.

The better performance question

The most useful measure is probably not how quickly the hose is disconnected. It is how quickly the delivery becomes a closed, consistent business event.

A delivery should not have two endings, one at the customer and another weeks later in administration.

Secu-Tech shows its answer at ETX in Kassel, 17 to 19 September 2026.