Customer systems move the load. Who runs your business?

A major customer may have an excellent transport portal. It receives statuses, presents deliveries and gives the customer the control it needs. The problem begins when a haulier works for three, five or ten principals, each with a different system, set of codes and view of the flow.

Every individual portal may work well, yet the haulier’s working day becomes fragmented. A booking is collected in one place, driver instructions are copied into another and proof of delivery is hunted down when the invoice is due. Traffic control becomes the manual integration layer between systems that were never designed to show the haulier’s complete operation.

Navichain gives the haulier its own operational backbone. Customer systems can remain in place while orders, runs, drivers, vehicles, statuses and delivery evidence form one workflow built around the haulier’s responsibility.

Executive summary

Working in a customer’s system is often part of the contract. That does not mean it has to become the haulier’s only business view. Navichain brings together the work that must be managed across customer boundaries: receiving or registering bookings, planning runs, allocating resources, giving drivers current instructions and connecting delivery documentation to the correct order.

Where a customer system exchanges information with navichain, the parties configure an agreed connection such as an API, webhook, EDI flow or supported freight partner. Once the connection is in place, information can move without staff retyping the same data. Where no automated connection exists yet, traffic control can still manage the work in navichain and complete the customer’s required reporting through the agreed process.

The benefit is not collecting data for its own sake. It is being able to see what must happen, who is doing it, what has changed and whether the evidence is ready for follow-up and invoicing.

Three principals can create three working days

Imagine a haulier running distribution for a retailer, trunking for a forwarder and recurring deliveries for an industrial customer. The retailer wants status in its portal. The forwarder sends order files. The industrial customer emails changes and expects signed proof the same afternoon.

For the driver, it is still one working day. For the planner, the same vehicles, hours and capacity must cover all three flows. The customer systems normally see only their own part. They are designed to optimise the principal’s process, not to show how the haulier’s total resources are being used or where the next conflict will arise.

The European Commission’s Digital Transport and Logistics Forum identifies fragmentation and a lack of interoperability between information systems as an important logistics challenge. It also describes how digital information exchange can improve cooperation, visibility and real-time management, and how existing platforms need to connect in federated environments.2

That is the haulier’s practical problem: not deciding which single customer system is best, but keeping its own business manageable when several systems must be used at once.

Build your own operational chain

In navichain, the booking can be the connecting point. It is linked to a run and to the resources that will perform the work. The driver receives stops, instructions and documents in the driver app. Statuses, photographs, comments and signatures can then return to the transport record.1

This does not mean the system makes every operational decision. The planner still decides which vehicle and driver should take the job, how an exception should be handled and what should be communicated to the customer. Navichain puts the decision support and documented event sequence in one place, so a person can decide with the wider picture and the next colleague can understand what happened.

That chain makes ordinary questions easier to answer:

• Which bookings from different customers compete for the same vehicle?
• Has the driver received the latest instruction?
• Which delivery is still waiting for usable proof?
• Who owns the next action when a delivery changes?
• Is there enough information to close and invoice the work?

Opening another customer portal rarely answers those questions.

Integration should remove duplicate work

Navichain provides a REST API with scoped API keys for areas including bookings, organisations, tracking and documents, together with webhooks for event-driven exchange. The platform also describes connections to freight and integration partners.1

When a customer connection is configured, start by deciding which system owns each item of information. The customer’s order number can remain as a reference. Addresses, times, handling units and instructions can be mapped to the booking. Statuses need agreed meanings so that, for example, “started”, “arrived” and “delivered” are understood on both sides. Documents and exceptions need clear destinations.

This is concrete integration work, but the result can be simple for the user: the order arrives, the planner schedules it alongside other customers’ work and the agreed status returns to the principal. Staff no longer have to serve as the connection, copying the same information between windows.

GS1’s EPCIS standard applies the same idea at industry level. Event data records what happened, where and when it happened, why it happened and how, enabling disparate applications to share a meaningful view of a flow.4 Navichain does not remove the need for agreed concepts in an integration, but it gives the haulier a place where those events remain connected to its own work.

The best exchange channel can still differ by customer and partner. Navichain’s Swedish-language guide to API and EDI explains how to choose the channel for each relationship without creating separate operational chains.5 This perspective addresses the next question: how the haulier maintains its own joined-up working view when several such customer connections meet.

Exceptions reveal whether the chain works

A normal flow can often survive fragmented tools. The cost becomes visible when something changes. A driver is late, a pallet is missing, a temperature reading is questioned or the receiver cannot accept the goods. Someone must understand both the customer’s requirement and the haulier’s actual position.

In navichain, an exception can be documented against the transport. The driver can contribute a status, photograph, comment or failed-delivery reason. Traffic control can decide the next action and keep subsequent communication attached to the correct job.1

Ownership is the important difference. The system can present the event and carry the evidence, but an accountable person decides whether to reattempt the delivery, contact the customer or follow up the cost. When responsibility and evidence share one working view, an exception is less likely to dissolve into an untraceable phone chain.

Proof closes the same story

Delivery evidence is more useful when its context is clear. A signature without an order reference, a photograph without a time or a comment in a separate chat creates more questions. Navichain’s driver app supports status updates, photographs, signatures and failed-delivery reasons. Its digital CMR capability connects documents to the relevant delivery and can seal a document with a hash and timestamp.1

The EU Regulation on electronic freight transport information, eFTI, establishes a legal framework for electronic information exchange between economic operators and authorities. The wider direction is clear: freight information should be manageable in digital, structured forms that can be exchanged between parties.3

For the haulier, the value is practical. When booking, run, execution and proof remain one chain, it becomes easier to find the right document, report to the right customer and prepare an invoice without reconstructing the whole working day.

Start without replacing everything

You do not need to begin with every customer and traffic type. Choose a flow where recurring friction is obvious: a customer with many manually entered orders, a lane where late proof delays invoicing or a segment where exceptions cause an unusual number of calls.

Set a bounded pilot:

1. Decide which order information should be present in navichain.
2. Define who makes planning and exception decisions.
3. Connect or register the selected order flow.
4. Let the driver perform the work from the current run and instructions.
5. Capture the delivery evidence against the same transport.
6. Measure manual entries, phone calls, late proof and time to invoice input.

If the result is clear, connect the next customer or lane. If something needs improvement, you have a bounded flow to refine, not a large replacement programme to defend.

Take back the complete picture

Customer systems will remain important. They should support customer processes and provide the information customers need. The haulier also needs its own perspective: one view of jobs, resources, execution and evidence across customer boundaries.

That is where navichain makes the difference. It gives planners, drivers and administrators a shared operational context while established customer flows can be connected step by step. Start where duplicate entry, phone chains or late proof cost the most, and test how the working day changes when you can follow the whole chain yourself.

Create a free account and try navichain.

Related perspectives

• NP-0006 — When delivery departs from the plan:** documentation, responsibility and the next action when reality changes.
• NP-0007 — The truck should not live in another system:** keeping vehicles, workshop activity and transport planning in one operational context.
• NP-0009 — Delivery is not complete until the proof holds:** the connected evidence chain from assignment to delivery.

Sources

1. One platform, from booking to delivery. navichain. Product description covering Transport, Driver app, Customer portal, Digital CMR and Integrations & API. Accessed 9 September 2026. Read the product description.

2. Digital Transport and Logistics Forum (DTLF). European Commission, Directorate-General for Mobility and Transport. Covers fragmentation, interoperability, visibility and the connection of existing logistics platforms. Accessed 9 September 2026. Read the European Commission overview.

3. Regulation (EU) 2020/1056 of the European Parliament and of the Council on electronic freight transport information. Official Journal of the European Union. Read the regulation on EUR-Lex.

4. EPCIS and Core Business Vocabulary. GS1. Standard for capturing and sharing visibility events across applications and organisations. Accessed 9 September 2026. Read about EPCIS.

5. API eller EDI? Att välja rätt kanal för varje partner. navichain, published 31 August 2026. Swedish-language guide to bringing different partner channels into one booking, status and document chain. Read the article.