---
title: "Six channels, and none of them is a system"
url: "https://edriq.com/blog/six-channels-and-none-of-them-is-a-system"
description: "Dispatch software assumes orders arrive in it. They arrive by email, portal, message and phone, and the gap between those two facts is where the day goes."
---

# Six channels, and none of them is a system

August 4, 2026·3 min read·EdrIQ

Transport systems are built around dispatch: assigning loads, planning routes, tracking vehicles. All of it useful, and all of it starting from an assumption that turns out to be false — that an order is already in the system when the work begins.

In an actual forwarding office, orders arrive by email with the details in the body, by email with a PDF attached, exported from a customer portal in whatever format that portal produces, as a message on a phone, and by telephone while the dispatcher is doing something else. Getting them into the system is somebody typing, and that somebody is the most expensive person in the office.

## Why it does not get fixed

**Every customer is different.** The large ones send structured data through their own portal. The medium ones send a PDF. The small ones send a message, and the oldest relationship in the company still calls.

**Integration is per customer.** Connecting one portal is a project. There are eleven of them and three change their format each year, which is why almost nobody does it below a certain size.

**Typing feels fast.** Two minutes per order does not feel like a problem. Thirty orders a day is an hour of the dispatcher, every day, and it is invisible because no single instance is worth mentioning.

**The errors surface later.** A transposed reference or a wrong postcode is discovered at delivery, or worse, at invoicing when the customer rejects it.

## Reading rather than integrating

The change is to stop trying to connect to every source and start reading what arrives, whatever form it takes.

An order in the body of an email has the same information as one in a portal export. A PDF has it in a layout that varies by customer but stays stable per customer. A photograph of a handwritten note has it too. What was hard about this ten years ago — reading unstructured text reliably enough to trust — is the part that has genuinely changed.

The right output is not an automatically created order. It is a prepared one: customer, route, dates, references, price, filled in and waiting for the dispatcher to confirm or correct. Two minutes of typing becomes ten seconds of reading.

## What makes it work in practice

**It has to learn per customer.** The same consignee writing the same way every week should be right by the third time, not merely right on average.

**Corrections have to be cheap.** A dispatcher fixing one field should take a second, and the system should not ask again next week.

**It has to say when it is unsure.** A flagged field with a question is useful. A confidently wrong postcode that reaches a driver is expensive.

**Nothing goes out unconfirmed.** The order is prepared, not accepted. Confirmations to customers, prices and assignments stay with a person.

## Why this is the first thing rather than the last

Every other feature in a transport system depends on the data being in it. Route planning, utilisation, profitability, the invoice — all of them assume an accurate order exists.

Intake is where accuracy is won or lost, it is where an hour a day disappears, and it is the part that conventional systems treat as somebody else’s problem. Fixing it first makes everything downstream better, and fixing it last means the reports have been describing typos for years.

-   order intake
-   dispatch
-   integration
-   workflow

## Keep reading

-   [Payment waits on a photograph](https://edriq.com/blog/payment-waits-on-a-photograph)
-   [The margin on a load is decided in the first two minutes](https://edriq.com/blog/the-margin-is-decided-in-two-minutes)