The customer's system controls the customer's flow — who controls the haulier's?

A haulier may need to work in several customer systems without treating each of them as its own operating system. A customer’s portal can remain the ordering channel and the record for information that customer owns. The haulier still needs to plan its vehicles, drivers and work across customer boundaries.

This does not have to mean replacing customer systems that already work. The practical question is where the haulier plans its day, who checks incoming information and how each result reaches the next person.

Executive summary

Each customer’s portal presents that customer’s transport requirements. Dispatch must fit those requirements around the same fleet, drivers and working day. Navichain supports bookings, runs, transport planning, vehicle and driver management, documents and digital proof-of-delivery workflows. Together, these functions give the haulier a practical operating picture across customer boundaries.1

The starting point is a responsibility map: which system owns the order, who plans the vehicle, who records delivery and who tells the customer what happened? For each customer, agree how a booking enters Navichain and how status and documents return. The transfer can begin with a simple agreed routine and develop into a configured API or EDI connection when volumes and business needs justify it.

The problem appears between systems

Consider a haulier working for three customers. Customer A uses a portal, Customer B exchanges EDI messages and Customer C sends a spreadsheet. Each can have a useful view of its own orders without knowing whether the haulier has committed the same vehicle to somebody else.

Dispatch must combine those demands. A late amendment may affect more than one customer’s work. A returning vehicle may be useful for another collection, but only if someone checks capacity, location and time. The person taking over a shift needs to understand the decisions already made, not reconstruct the day from three separate customer views.

The lesson is not that the customer systems are poor. They serve the customers’ responsibilities. The haulier needs an explicit home for its own cross-customer planning and an agreed way of keeping customer information aligned.

How Navichain supports the workflow

1. Agree ownership before building a connection

Start with the customer’s order reference, collection and delivery addresses, time windows, packages, instructions and required documents. Agree who may amend each item, who checks a change and how both parties recognise the same job.

Navichain provides the booking foundation for this workflow.1 The right way to bring orders in depends on the customer and the volume. Manual entry can be an effective first step for a small flow, while an API or EDI connection can be mapped around the customer’s identifiers, status meanings and document requirements.

The required outcome is a booking that dispatch can plan and a customer reference that can be checked against the original order. The chosen transfer mechanism does not remove responsibility for checking the information.

2. Make the information comparable

A customer’s location code needs to identify the correct address and gate. Its service description must be understood by the person planning the vehicle. “Delivered” must mean something both parties recognise before that status is exchanged.

If an address is incomplete, the responsible person contacts the customer before planning the job. For larger connected flows, validation rules and a review routine can be designed around the information that matters most. The important point is that unclear data is resolved before it reaches the driver.

Consistent information makes jobs easier to compare regardless of how they were entered. It also makes a handover more intelligible: the next dispatcher should not need to guess what a customer’s shorthand means.

3. Plan the haulier’s day

Navichain supports bookings, runs and transport planning alongside the management of trucks, trailers and drivers.1 Dispatch uses those functions to plan the haulier’s work across customer boundaries.

The practical opportunity is to assess registered jobs together rather than considering each customer’s demand in isolation. The dispatcher compares transport requirements, capacity, locations and times, then decides how to use the available resources. Navichain gives that decision a shared and structured basis.

Where the facts are uncertain, a human decision remains necessary. A clear planning routine states who confirms a delivery window, who accepts a change and who informs the driver.

4. Give the driver a usable assignment

Once a run is agreed, the driver needs an intelligible basis for carrying it out. Navichain’s current Help documentation describes mobile runs, bookings, CMR display and pickup/delivery workflows, including parcel quantities, photographs, signatures, comments and timestamps.1

The driver should not need to understand the customer’s integration design. The operational question is simpler: what work is to be done, what must be recorded and whom should the driver contact if the plan cannot be followed?

5. Give an incident an owner

A blocked gate makes the distinction between information and action clear. The driver can describe the situation; dispatch must decide what happens next. Navichain has document and task/workspace functionality, and photographs and comments are part of its documented mobile workflows.1

Agree how these functions will be used together for the events that matter in your operation. A clear routine links the driver’s observation to the relevant assignment, identifies who makes the next decision and states what the customer needs to know.

An agreed delivery update and an operational note do not necessarily have the same audience. Keep the detailed working record where the team can use it, and return the relevant status or document through the channel agreed with the customer.

6. Hand over evidence, not assumptions

After delivery, finance needs the documentation required for that customer’s job. Navichain supports digital CMR document workflows and proof-of-delivery/signature workflows.1 Finance checks the resulting evidence against the agreed documentary requirements before invoicing.

This creates a clearer handover from operations to administration. Where status or documents should be distributed automatically, that return flow is configured to match the customer’s receiving system and documentary requirements.

Measure the handover rather than assuming its value. Useful checks include the number of bookings requiring clarification, time spent entering the same information twice, and deliveries with the required documentation available to the responsible person. Establish a baseline before setting improvement targets.

An illustrative working day

Imagine the following working day. At 05:40, dispatch has five jobs from Customer A and two from Customer B to register in Navichain. An eighth request from Customer C is missing the consignee postcode. The dispatcher contacts the customer and keeps that job out of the plan until the address is complete.

The seven registered jobs can be considered alongside the rest of the day. After checking capacity, times and locations, the dispatcher chooses a returning vehicle for four jobs. Two need another run, and one awaits confirmation of unloading time. Navichain provides booking, run and resource support; the combination is the dispatcher’s decision.

At the third stop, the gate is obstructed. The driver records a photograph and comment and contacts dispatch. The dispatcher checks with the customer and changes the plan after agreement. The customer receives the relevant update through the agreed channel. After delivery, finance reviews the proof of delivery against the customer’s requirements.

The example makes the roles explicit: Navichain supports the bookings, runs, resources and documents; dispatch makes operational decisions; the driver records execution; the next person checks the result. An integration can subsequently be evaluated to reduce repeated entry without removing those responsibilities.

What makes the setup work

A dependable integration is built around the real customer flow. It needs stable identifiers, agreed status meanings, representative test orders, clear handling of exceptions and ownership of future changes. Starting with one customer and one representative flow makes it easier to establish a robust pattern before expanding.

Order changes and documents also need a defined master system. If two systems can edit the same information, agree how differences are detected and resolved. Walk through a normal job, an amended job and a cancelled or interrupted job so that the routine works on difficult days as well as easy ones.

The result should be a working division of responsibility rather than an integration for its own sake. Navichain provides the operational foundation; the customer-specific connection is shaped around the systems, data and response times involved. That keeps the solution useful today and easier to develop as the collaboration grows.

Business value: a shared basis for decisions

The intended value is to keep serving customers through their chosen channels while giving the haulier a coherent basis for its own decisions. The opportunity is less dependence on one dispatcher remembering every commitment, clearer incident handovers and more systematic use of delivery documentation.

The value becomes visible in the work: fewer separate views to reconcile, clearer handovers when plans change and more consistent access to delivery documentation. Start with a representative flow and compare the effort required to register, plan, execute and close it before and after the change.

The objective is not the largest possible number of integrations. It is a reliable process in which information has a known owner and the next person can act without guessing.

Related perspectives

• NP-0002 — Cabotage: three operations in seven days are only the beginning.** How work for several customers still needs to be assessed against one shared compliance position.
• NP-0036 — The shortest route is not always driveable. Why every transport plan needs to reflect the road, vehicle and assignment in the real world.
• NP-0073 — Not everyone has to work in the same system. How specialist systems can work together when ownership and information exchange are clear.

Next step

Choose a real customer flow and map the incoming order, planning decision, driver execution, delivery evidence and return reporting. Mark who owns each step and where the same information is entered more than once.

Contact Navichain to walk through that flow using your own orders, roles and customer channels. Together, you can identify a practical first step and see how Navichain can support the whole working day. Explore the platform.2

Sources

1. Navichain product documentation, 29 August 2026. Describes bookings, runs and transport planning; management of trucks, trailers and drivers; documents and tasks; and digital CMR and proof-of-delivery workflows.

2. Navichain — TMS and WMS in one platform, accessed 7 September 2026. Overview of the platform and its role in transport and warehouse operations.