One booking, one record: fixing the hand-off in road freight

01The hand-off problem

Follow a single pallet from a manufacturer's dock to a customer's warehouse and count the hand-offs. A planner e-mails or calls the transport company. Someone at the carrier re-types the details into whatever system they use — or into a spreadsheet, or a notebook. The driver receives the job by phone or chat, and the paperwork that travels with the goods is filled in by hand from information that already existed in the original e-mail. The receiver, meanwhile, learns the delivery is coming when the truck turns up, or not at all.

None of these steps is unusual, and each of them works most of the time. The trouble is that each one is a one-way message. Nobody confirms that the booking was accepted. Nobody else can see that the pickup slipped by three hours. When the receiver rejects two cartons as damaged, that fact lives on a paper note in the cab until someone types it up. When the carrier later invoices for four hours of waiting time at the delivery dock, the sender has no shared record to check it against.

The cost does not show up as a single line in anyone's accounts. It shows up as phone calls, re-keying, disputed charges, missed delivery windows, and compliance problems found at the roadside instead of at the desk. In cross-border and regulated freight it also shows up as legal exposure: road transport in both Europe and India is built around documents that must be correct, carried and kept.

02What "one record" means

The fix is not another channel for messages. It is a single booking record that every party reads and writes — with one identifier and one status timeline, and with each party seeing the part that matters to them.

In CETAIN that record moves through a small, explicit set of statuses, and every change is stamped with who made it and when:

Two design choices matter more than the list itself. First, the status is one timeline shared by sender, carrier, driver and receiver; nobody maintains a private copy that can drift. Second, the views are role-specific: a sender sees their own bookings, a driver sees a shift itinerary, a receiver sees what is coming to their door — but all of them are looking at the same record.

Not every condition deserves its own status. When a booking contains goods that need approval, CETAIN holds it with a separate approval flag that blocks the step to acknowledged, instead of adding a new status that every report and integration would then have to understand. Keeping the status list small is what keeps the timeline readable.

03Acknowledgement is a feature

The single most useful moment in a booking's life is easy to overlook: the carrier saying "yes, we have it". In an e-mail chain that moment is often implicit — silence is read as acceptance — and the sender only discovers a problem when the truck does not arrive.

Making acknowledgement an explicit step changes behaviour on both sides. The sender knows the difference between "sent" and "accepted". The carrier's dispatch queue has a clear backlog of what still needs a decision. And because the step is recorded, it can be measured and escalated: an escalation rule can flag bookings that have sat unacknowledged for longer than a carrier's service level allows, and fire once per booking and trigger rather than repeatedly.

Silence is not a confirmation. A shared record should make the difference between "sent" and "accepted" impossible to miss.

04Taking the re-typing out of repeat work

Much road freight is repetitive: the same lanes, the same goods, the same customers, every week. Treating each of those as a fresh, hand-typed booking is where errors creep in.

Templates and recurring drafts

A booking template saves the whole shape of a booking — locations, goods lines, default quantities — not just an address book entry. A template can also produce drafts on a schedule. CETAIN deliberately creates those as drafts that a person reviews and submits; it never submits them silently, because a recurring booking that nobody checked is exactly how a truck gets sent for goods that are not ready.

Bulk import that is safe to repeat

Larger shippers plan in spreadsheets. A CSV import is validated against the same rules as a manual booking and returns a per-row error report, so one bad row does not block the other ninety-nine. The import also keeps a per-row ledger: uploading the same file again does not create duplicate bookings. Planners re-upload files; the system should expect it.

05Evidence at the point of delivery

Delivery is where most disputes start: missing items, damaged goods, waiting time. What settles them is evidence captured at the moment, attached to the booking — not a recollection a week later.

CETAIN's proof of delivery records the signature and the recipient's name, and the accepted and rejected quantity for each goods line. A rejection cannot be recorded without at least one condition photo. The result is a delivery record that already contains the answer to the questions a sender or insurer will ask.

Waiting time from server clocks

Detention and demurrage charges are only defensible if the times behind them are. CETAIN starts the dwell clock when the driver marks arrival and stops it at proof of delivery, using server-recorded timestamps — never times typed into a phone. A charge computed that way can be explained line by line to the party paying it.

Consignment documents follow the same principle. In Europe the CMR Convention — signed in Geneva in 1956 — governs the contract for international carriage of goods by road and its consignment note^[1]. In India the Carriage by Road Act 2007 requires the consignor's goods forwarding note and a goods receipt from the carrier^[2], known in practice as the lorry receipt (LR) or GC note. When those documents are generated from the booking data, they cannot disagree with it — and regenerating one creates a new version rather than silently overwriting the old.

06The receiver is a party, not an afterthought

Receivers — warehouses, stores, construction sites — usually deal with many carriers at once. Asking them to keep a login with each one does not work, so most never log in anywhere and simply phone.

CETAIN gives receivers a single verified identity that works across every transport company on the platform. It is the one place in the system deliberately built to span companies, and it is isolated and reviewed as such: a receiver only sees bookings addressed to an e-mail address they have verified. From there they can see what is coming, ask to reschedule, mark days they cannot receive goods, and rate deliveries.

Ratings are handled with care. They feed the carrier's dashboard as an aggregate, next to on-time performance; individual comments are not pushed to drivers, so feedback becomes a signal for the business rather than friction on the road.

07Public tracking without leaking data

Not everyone who wants to know where a shipment is has an account — an end customer, a site foreman, a colleague in another department. A public tracking page solves that, but done carelessly it becomes a way to scrape other companies' shipments.

CETAIN's public tracking requires two pieces of information: the tracking code and the delivery postal or PIN code. Requests are rate-limited per IP address, and a wrong combination returns exactly the same "not found" answer as a code that does not exist, so valid codes cannot be discovered by trial and error. The page shows the status timeline — not names, addresses or goods.

08Measuring what changed

A shared record produces, as a by-product, the data that an e-mail chain never could. Because every status change is timestamped and attributed, a carrier can see on-time performance against the agreed windows, exceptions by reason code, waiting-time charges, cancellation fees, delivery ratings, and how each driver and vehicle is used — without anyone filling in a report.

We recommend choosing two or three measures before go-live and recording a baseline from your current process, however rough. Useful starting points are the time from a booking being sent to it being accepted, the share of deliveries with complete proof of delivery, and the number of disputed waiting-time charges. Comparing those after a few weeks says more than any general claim — including ours.

09A practical rollout path

1. Pick one lane and one customer. A regular, repetitive flow shows the benefit of templates and acknowledgement fastest.
2. Use the documents you already use. Compare the generated LR, GC note or CMR with the one your drivers carry today before relying on it.
3. Load drivers and vehicles with their papers. Compliance gates only help if expiry dates are on file.
4. Invite the receiver. One verified login per receiver removes a surprising number of calls.
5. Agree what to measure, then widen to more lanes and customers.

Looking further ahead, regulators are moving the same way. The EU's eFTI Regulation requires authorities to accept freight information shared electronically through certified platforms from July 2027^[3], and the e-CMR protocol has allowed electronic consignment notes between its parties since 2011^[4]. Structured, versioned booking data is the prerequisite for both.

SourcesReferences

1. Convention on the Contract for the International Carriage of Goods by Road (CMR) — signed 19 May 1956, in force 2 July 1961 — UN/CEFACT Digitalize Trade
2. The Carriage by Road Act, 2007 (Act 41 of 2007) — India Code, Government of India
3. Electronic freight transport information (eFTI) Regulation — European Commission, DG MOVE
4. Additional Protocol to the CMR concerning the Electronic Consignment Note — signed 20 February 2008, in force 5 June 2011 — UN/CEFACT Digitalize Trade