Cases / Logistics · Booking and documents platform
Client under NDA Documents and integrations

A booking becomes a full document set in seven minutes instead of forty — and reaches the carrier without errors.

40 min → 7 min
to process a booking
12% → 2%
document sets with errors
~3 mo
to the full loop

The client is under NDA, so the industry and size are given as a range. The figures are the client’s own, comparing the periods before and after launch; on similar projects the result landed on both sides of these numbers. Run the numbers on your own volumes →

Context

Forty minutes of retyping per shipment, and every eighth document set came back to be redone.

A freight forwarder, 50–70 staff, several dozen carriers in regular use. A booking arrived by email, by messenger or over the phone, a dispatcher typed it into a spreadsheet, carried it from there into document templates, took the carrier’s details from a folder on a drive and the addresses and cargo figures from the customer’s email. One shipment took around forty minutes, and roughly every eighth document set came back to be redone: the wrong delivery address, a mismatch in the number of packages, out-of-date carrier details, a weight that differed between the waybill and the booking. The error surfaced after printing, sometimes only once the driver had it. Customers learned where their cargo was by calling the dispatcher, and the dispatcher by calling the driver — and there were more of those calls in a day than there were shipments.

Solution

One platform between the booking, the carrier and the documents.

The same stack as on our other projects: Python and Django at the core, PostgreSQL as the source of truth for the booking, the shipment and the document. A booking comes in from any channel and is entered once, the document set is assembled from a carrier directory rather than from a folder on a drive, and mismatches are checked before printing. Statuses arrive from the carriers and are visible to the customer, so there is no longer a reason to call a dispatcher to ask where the cargo is.

Architecture
Bookingsemail · messengerCarriersrates and detailsCustomerscontracts and addressesCargopackages and weightPlatform corebooking · shipment · documentDocumentswaybills and ordersChecksbefore printingStatusescustomer portalInvoicingrates and reconciliationReportingmargin and failures
What we built

Six loops in three months.

The order was set by the money: first the thing that removes the retyping and the redos, then everything else.

01
Bookings from any channel
Email, messenger, web form and phone converge on one intake. The platform parses the message and fills in the addresses, the cargo and the customer, and the dispatcher corrects what was filled in rather than typing it all again.
02
Carrier directory
Details, rates, insurance and document expiry dates live in one place. Documents are assembled from the directory, so out-of-date details stop reaching the set.
03
The document set
Assembled in minutes. Checks run before printing: addresses, package counts, weight and dimensions, booking against waybill, both parties’ details. Sets with errors went from around 12% to around 2%.
04
Shipment status
Statuses come from the carriers and are visible to the customer in a portal. The dispatcher stopped being a relay between the customer and the driver.
05
Rates, invoices and reconciliation
The rate is fixed on the booking, the invoice is built from it, and reconciliation with a carrier runs shipment by shipment rather than from memory and a chat history.
06
Reporting
Margin is calculated per shipment and visible immediately, and failures are broken down by cause — carrier, customer, documents — instead of collapsing into one "it did not work out".
Before and after

Before and after.

Before
Processing a booking~40 min
Sets with errors~12%
Booking intakethree channels
Carrier detailsfolder on a drive
Document checksafter printing
Cargo statuscall the dispatcher
Margin per shipmentat month end
After
Processing a booking~7 min
Sets with errors~2%
Booking intakeone intake
Carrier detailsdirectory
Document checksbefore printing
Cargo statuscustomer portal
Margin per shipmentimmediately
Limits
What stayed with people, on purpose.
Choosing the carrier for a particular load. The platform shows rates, availability and a history of failures; the dispatcher decides.
Negotiating the rate. We made no attempt to automate haggling.
Anything that goes wrong in transit — a delay, a breakdown, a refused load. That needs a person with a phone, not a scripted flow.
Vetting a new carrier before it enters the directory: paperwork, insurance, reputation.
Stack
Python Django PostgreSQL Inbound email parsing Document generation Carrier exchange Monitoring and alerts
Straight about what we left alone

We did not abolish the booking by phone.

Some customers call and will keep calling, and we were not going to push them into a web form for the sake of a tidy diagram. The dispatcher takes the call and enters the booking on one screen, and the document set is assembled from there. The seven minutes cover the whole path from booking to finished documents — they are not a robot replacing a person: the person stayed, they just no longer retype anything. The three months went largely on something other than code: the carrier directory and the document templates had to be put in order first, because there is nothing to assemble a set from when a carrier’s details exist in three versions across three folders. That part was done by the client’s own people.

Related

What this case is made of.

The service pages explain the method behind this project; the solution pages take the same building blocks on their own, each with its own scope and price.

Want the same for your process?

A free mini-audit projects the ROI for your highest-impact process — then the build is a fixed price.

Get a free mini-audit →