It always starts the same way. The customer sends a PDF. Or an email. Or a photo of a handwritten waybill. The operator opens the document in one window and the booking form in another — and starts typing. Address. Reference number. Weight. Number of packages. Date. Delivery instructions. Everything the customer has already entered in their own system is now entered again. Manually. By hand. Character by character.
This is not administration. It is double work. And it has been going on since the transport industry got computers.
Magic Drop is Navichain's solution. You drag in the document. The AI reads it. The booking is complete. The entire process takes less than 30 seconds — and you don't need to configure a single format or write a single template.
"An operator who processes orders for five to eight hours a week spends a full working day copying data that already exists in the customers' own systems."
Navichain · Internal analysis of operator behaviorWhat Magic Drop actually does
Navichain has always handled bookings. Magic Drop changes how they are created. Instead of you filling in the form, the AI fills it in — based on what is written in the customer's document.
It works with PDFs, photographed waybills, scanned papers, and text copied directly from an email. There is no list of approved formats, no mapping table to maintain. The system identifies sender, recipient, addresses, goods description, weight, number of packages, reference number, date, and delivery instructions — and places them in the correct fields in the booking form.
If a field is ambiguous in the original document, it is marked in yellow. You see exactly what needs to be checked. The rest is ready.
Drag in the PDF — or paste the email
You open a new booking in Navichain. At the top, you see a red box: Import from document. You drag the waybill, order confirmation, or email text there. That's the whole job from your side.
✓ Takes 5 secondsAI reads and fills in everything
The system automatically identifies all booking fields. Sender, recipient, addresses, goods description, weight, number of packages, reference number, date, delivery instructions. Everything ends up in the correct field. Uncertain information is marked in yellow for review.
⟳ Ready in a few secondsCheck through — and go
You see a complete booking: customer, transport, packages, schedule, fees, delivery terms. Does everything match? Click Save. The driver gets the assignment. The invoice is triggered automatically when the trip is complete.
✓ Booking complete — assignment outThe invisible cash bleeding
Manual processing is rarely seen on a single line in the result statement. Instead, it appears as a diffuse cost mass — a few extra full-time positions, correction invoices that hailstorm during the quarter, a liquidity that never quite matches the volume.
Break it down into concrete items, and the picture becomes clearer.
| Cost source | What it means in practice | Order of magnitude |
|---|---|---|
| Double work · time | 5–8 hours/week per operator copying data that already exists | One full working day/week |
| Input errors | Misread address, wrong reference → driver drives to the wrong place → credit note + customer dissatisfaction | Happens every week |
| Delayed invoicing | Order processed tomorrow is invoiced tomorrow. Hundreds of orders × one day = liquidity problems | Every day delays payment |
| Incorrect use of competence | Dispatchers hired to manage transports are used as human copiers | Competence is misused daily |
Why traditional EDI solved the wrong part of the problem
The EDI integrations that came in the nineties solved a real problem — but only for the very largest customers. For an EDI bridge to be profitable, IT projects of 50,000–200,000 SEK and months of implementation per customer connection were required. It was reasonable when the customer accounted for ten percent of the volume. It was never reasonable for the customer who sends twenty shipments a month.
The result is that transport companies have a divided reality: large customers integrated, the rest stuck in manual flow. Magic Drop solves the entire queue.
Traditional EDI
Navichain Magic Drop
Part of a complete flow
Magic Drop is Navichain's solution for the analog inflow — customers who send PDF and email. But a modern haulage company rarely has only one type of order source.
Navichain handles the entire spectrum. API connections to nShift and Logtrade are activated in minutes: when the customer clicks Book in their own system, the order appears directly in Navichain, without anyone on your side needing to do anything. e-CMR with electronic signature covers international traffic — the sender signs at loading, the recipient at unloading, and the invoice is triggered automatically when the CMR is signed.
Three order sources. One system. The same booking. The same invoicing.
to complete booking
before you can start
Magic Drop is included
Data storage and sovereignty
All data is stored on Swedish servers under Swedish jurisdiction. US Cloud Act and FISA 702 — the American laws that give American authorities access to data stored by American cloud providers, regardless of where the servers are physically located — do not apply to Navichain. For haulage companies handling sensitive customer flows, logistics agreements, or public contracts, this is a distinction that actually matters.
What it means in practice
Your customers' orders, addresses, and goods descriptions are not in an American cloud service. They are on Swedish servers, under Swedish laws, without a backdoor that anyone else controls. This is not a marketing headline — it is a legal reality that sets Navichain apart from most competitors in the market.