The operations center for your loads

From request to delivery, every load on one screen — live location, documents, messages and status flow in a single record.

All your loads on one screen — filter by status, route or date

Live tracking for road and RoRo, straight from the driver app

Documents, messages and status come together in the same load record

From request to invoice, in one record

Every step advances in the same load record — no copy-paste, no lost paperwork.

Request

Quote

Documents

Customs

Tracking

Delivery

Invoice

All in one record

Road and sea, on the same map

The driver app shares the location; you see where every load is without refreshing the board.

You get an instant notification on every status change.

Every load detail on one card

Packages, weight and volume in one place; the system computes the loading meter, and you measure pallets on your device — dimensions convert to volume automatically.

Package count, weight and volume gathered on one card.

The loading meter (LDM) is computed automatically from your figures.

Measure pallets with a phone or tablet; dimensions turn into volume.

Your entire load operation on a single core

Visibility, tracking, notifications and paperwork — one system instead of scattered tools.

One-screen visibility — All your loads in one list; filter by status, route or date in seconds and open any load you need.
Live tracking — Road and RoRo shipments stream on the board with live location from the driver app.
Status notifications — Loaded, in customs, in transit, delivered — an instant notification goes to the right people on every status change.
Groupage and multi-stop — Carry multiple isolated consignments on one vehicle; the route is ordered automatically and each load stays a separate record.
You control visibility — Only the carriers you work with and invite see your request — your own network, your data.
Documents and messages in one record — CMR, invoice, ATR and every message are gathered on the load's own record; AI reads the documents and fills the fields.

Works with

One core, one operating system — every module feeds the next.

Customs Intelligence — HS tariff, duty and anti-dumping lookup
Warehouse & Stock — Product catalog, pallet measurement, stock ledger
AI — AI for document reading, translation, tariffs and consistency checks
Factory/Foreign Trade Companies — The solution page built for your role

Bring your load operation onto one screen

Manage every step from request to delivery from a single load record — live tracking, documents and status together.

How do you digitalise load and document tracking in international road freight?

In sequence, and on a single record. Digitalise the status flow first (which stage the load is at, who updated it and when), then proof of delivery and site photos, then the driver-side layer, then live location; the document archive and integrations come last. What decides the outcome is not the technology but the data model: location, status, documents and messages must sit under the record of the load, not under the vehicle — the moment two customers share one truck, a vehicle-based record cannot separate visibility. Paper does not disappear entirely: some documents have an electronic form subject to conditions, others still travel on paper on your lane. The measure of progress is not how many screens you opened, but how many times someone still has to phone to ask where the load is.

Digitalising load and document tracking is not an installation job, it is a sequencing job. In international road freight, data is created in three separate places — in the office (request, quote, order), behind the wheel (status, location, delivery) and at the border (declaration, accompanying document, stamp) — and until those three sources are connected, the number of screens you have opened does not matter. Most companies start where visibility is highest: with a vehicle tracking device or with a document archive. Both are sound investments, but done in the wrong order neither answers the question asked most often during the day — what stage is this load at right now.

The right order does not run from cheap to expensive; it runs from certain payoff to uncertain payoff. A status line produced by a driver tapping twice costs almost nothing to set up, yet absorbs a large share of the office’s inbound calls. Live location does not deliver the same value immediately: it depends on battery, coverage, permissions and habit. A document archive only helps if documents are captured at the moment they are created. That is why the layers below are ordered deliberately, and each one states which manual step it replaces, how it is measured, where it breaks and what it needs.

The second half of the page deals with the decision most companies skip: what the record is attached to. After that you will find which documents can be electronic and under which condition — every line is written conditionally, because the rules differ by country, by lane and by date — then what breaks in the field, how to test a vendor’s tracking claim in a demo, and a workable thirteen-week sequence.

The first layer is status, not location: the answer to “where is it” is usually a stage — loaded, at customs, in transit, delivered — not a coordinate.
Make the consignment the unit of record. If you choose the trip or the vehicle, two customers’ data lands on one record and visibility can no longer be separated.
If a status line does not show who wrote it, when, and from where, you do not have a digital record — you have digitised hearsay.
Capture documents where they are created, not from the archive: they appear on site, at the border and at the customs broker; an archive collected afterwards is always incomplete.
How much paper actually goes away depends on the document and the route; never build a flow on a claim of electronic validity you have not confirmed for your own lane.
If the driver side stays empty the system is half-built: when the field step does not finish on one screen, data keeps arriving in the office by phone.

What to digitalise, and in what order — seven layers

1. Status flow — the first and cheapest layer — Recording which stage a load is at, in one place and in one format: awaiting loading, loaded, in transit, at customs, unloading, delivered. Keep the list short and restrict it to the stages your company genuinely distinguishes; a fifteen-status list collapses to three in the field. The repeated “where is it” calls during the day, the parallel list the dispatcher keeps in a private notebook, and scrolling back through a group chat for the last message. Count the “what stage is this load at” questions you receive over one week, then repeat the same count after the change. Second measure: how many closed trips ended with a complete set of status lines. When the office enters the status. The office writes what it believes, field information lags, and the record quickly becomes untrustworthy. The second failure is list inflation: a driver who cannot tell two statuses apart picks one at random. The load must exist as a record with a single code, the driver must be linked to that record, and it must be stated in writing who enters which step.
2. Proof of delivery and site photos — Collecting the evidence that delivery happened: a photo of the signed document, delivery time, the name of the person who received the goods, and where relevant condition photos of the cargo or the equipment. This layer is unusual because it is irreversible — evidence not collected at the moment of delivery cannot be collected later. The paper copy carried in the driver’s cab for days, the pile of documents scanned in bulk once he returns, and the sentence heard in every damage dispute: nobody took a photo. The time from delivery to the document appearing in the system (measure it in hours, not days) and the share of deliveries closed without a photo. When the photo goes to the phone’s gallery or a chat thread instead of the load record; when it is too dark to read; when the name of the person receiving the goods is never recorded. Any of the three makes the evidence unusable in a dispute. A working camera in the driver’s hand and a few seconds at loading and unloading. If equipment condition is also tracked, the before/after photo discipline must be announced to the team in advance.
3. The driver layer — data entry from the field — Field data entry itself: the screen the driver sees, the number of taps, the interface language and the sign-up step. This is not a feature question but an adoption question, and half the system is filled here — however well the office side is configured, the record is incomplete if the field side is empty. Most of the voice coordination between office and driver, and the dispatcher’s job of typing in what he was told on the phone. Active driver ratio (drivers who sent at least one update from the app / total drivers) and how many steps of a trip came from the field rather than the office. A long sign-up and password step, a single-language interface for a multinational team, an inflated list of fields requested from the field, and areas without coverage: if there is no offline queue, an update entered while disconnected cannot be sent and the driver has to enter it again. The app installed on the driver’s device, a working account, and a clear rule about which step is expected from whom. There must also be something in it for the driver: assignment details, addresses and documents on the phone.
4. Live location — Streaming the vehicle’s or driver’s position onto the load record and showing it on the route. Location is an answer, but not a sufficient one on its own: customers do not ask for coordinates, they ask for an arrival time. Calling the driver to ask where he is, and the office quoting an arrival time to the customer based on its own guess. Location continuity: for what share of the trip does position actually flow, how long are the gaps, and where do they occur (coverage, battery, permissions, app closed)? Phone battery, background location permission switched off, coverage gaps, and location written to the vehicle record without ever being tied to the load being carried at that moment. Location is also personal data that has to be handled deliberately: the driver must be told plainly what is collected, when and why. The app installed and linked to that trip, background location permission, and a written rule for how sharing behaves outside working hours or between trips.
5. Document capture — at the point of creation — Capturing each document where it comes into existence: the packing list and consignment note copy at the loading point, the accompanying document and MRN at the border, the declaration output from the customs broker, the invoice from the seller. Wherever the point of creation is, that is where digitalisation has to be installed. Scanning folders after the trip is over, hunting for documents in email attachments, and copying the same file into three different places. In how many closed trips the mandatory document set is complete, and the average time it takes to find a specific document. Documents uploaded without a type — everything becomes “other” and nothing can be found afterwards — an archive built as a folder tree independent of the load, and putting a retrospective bulk-scanning project first. That last one stalls in most companies, and during the attempt new documents are not being collected either. Defined document types, upload rights extended to the field and to the customs broker, and photographs at a readable resolution.
6. Party visibility — Attaching every party concerned with the load to the same record in their own role: shipper, carrier, sub-carrier where used, consignee and customs broker. What each party sees should differ by role, and that separation should be closed by default. Status emails typed by hand to the customer, documents forwarded one by one to the customs broker, and the consignee calling to ask when it will arrive. The change in the number of status emails and messages sent out manually, and the number of information requests raised by customers. Opening everything to everyone (price and other customers’ details leak) or opening nothing at all (phone traffic continues unchanged). The third mistake is leaving access open indefinitely after the trip has closed. An accurate company address book and a decision, taken in advance, about which role sees what.
7. From operations to invoicing — Connecting trip data to invoicing and reconciliation: the goods carried, additional charges, waiting time, currency and dates all come out of one record. This is the layer where digitalisation is measured in money. Putting the operations list next to the accounting list at month end and matching them by hand, and the extra charges that never reach an invoice because nobody remembered them. How many days the month-end close takes, and how many additional charges failed to reach an invoice. Operations and accounting living in two separate systems, with the match between them resting on human memory rather than a shared code. Price and additional-charge fields genuinely in use on the load record, and the accounting side recognising the same load code.

The decision that governs everything: what the record hangs on

The single decision that determines whether digitalisation works is what the data hangs on. Writing the same information under the vehicle, the trip or the customer produces three different systems — and this is the decision that is most expensive to reverse later. The six rules below are the practical form of that decision in international road freight.

The unit of record is the consignment, not the vehicle — A load record represents one transport job; if two customers’ goods travel on the same truck, there must be two records. Systems built around the vehicle or the trip merge the two, and one customer can end up seeing the other’s address, cargo or documents. If you run groupage this is not a preference but a requirement — and even in full-load work the same need appears the moment a trip is passed to a sub-carrier.
Location and status are written to the load record — Position coming from a device or a phone should attach to the record of the load being carried, not to the number plate. Location written per plate does not answer the question that is actually asked: nobody wants to know where the truck is, they want to know when a specific consignment arrives. The same test applies to tachograph and fuel data — valuable on its own, but it becomes an operational answer only once it is tied to the trip.
Every status line carries an attribution — Who wrote a status, when, and through which channel (from the field or from the office) must be visible on the record. A status without attribution proves nothing in a dispute, and the team stops trusting it soon enough. A record that can be edited but leaves a trail beats a record that cannot be edited but that nobody fills in.
Parties attach by role, not by person — Shipper, carrier, sub-carrier, consignee and customs broker should attach to the record in their role. When access is tied to one person’s email address, visibility disappears when that person leaves, the archive is orphaned and the handover is done by hand. Role-based attachment also spares you from re-litigating “who can see what” on every single load.
One identity: the load code — A load should have one code, and documents, messages, location, proof of delivery and the invoice should all hang off it. When two numbering schemes — the operational file number and the accounting invoice number — are not connected, month-end reconciliation degenerates into manual matching. Give the code to the customer too, so that it can be searched when they ask.
Visibility is closed by default — Access is granted explicitly; it should never arise by itself. In international freight there are parties around the same load who may be each other’s competitors; who sees what should be decided when the load is opened, and access should close when the job ends. That is both a commercial safeguard and a defensible default from a personal-data standpoint.

The document layer: what can be electronic, and under what condition

How much paper actually disappears depends on the document, the route and the authority; there is no single “it is all electronic now” answer. The table below summarises whether the documents commonly seen in international road freight have an electronic form and what that form depends on. Because the rules differ by country and change over time, every line is conditional.

This section is for information only and is not legal advice. Before you build a flow on it, confirm the position for your own route with your customs authority, your accountant or your transport association. Which document is required for which shipment is covered separately in our freight documents checklist.

CMR consignment note — An electronic form exists — subject to the countries involved and the parties’ agreement. The Additional Protocol to the CMR Convention concerning the electronic consignment note, adopted in 2008, makes e-CMR possible. To use it, the countries on the route must be parties to the protocol and the parties to the carriage must accept an electronic note; the list of contracting states has been growing over time. In practice there is a transition period: a driver may still meet an inspecting officer on the route who asks for a paper copy. Before switching to an electronic flow, confirm the position of every country on your lane and the counterparty’s acceptance. Keeping a scanned copy on the load record lets the office and the customs broker proceed even while the paper is still travelling.
Transit declaration (T1/T2) and the transit accompanying document — Already electronic — the declaration is lodged in the authority’s system. Under the common transit procedure the declaration is lodged electronically (NCTS). What travels with the goods is not the declaration itself but the transit accompanying document, which carries the MRN (movement reference number). Your job here is not to digitalise the declaration but to attach the MRN and the accompanying document to the load record. Once the MRN is searchable on the record, most questions coming from the border can be answered from the office instead of waiting for the driver to find and photograph a document.
Export / import customs declaration — Already electronic — lodged in the authority’s system. The declaration is lodged in the electronic system of the relevant customs authority and is usually prepared by a customs broker. The declaration number, together with any exit or accompanying document, is the shipment’s identity. What gets digitalised is not the declaration but the attachment of its number and output to the load record. Letting your customs broker upload the document directly to the same record removes the email traffic that otherwise goes back and forth.
Commercial invoice — Electronic form widely available — scope varies by country and by taxpayer. In Türkiye the scope of the e-Fatura and e-Arşiv invoice regimes is set by tax administration communiqués and varies with turnover thresholds and sectors. In the European Union, the standard for electronic invoicing in public procurement is defined, while member states run their own timetables for wider mandates. Ask your accountant and check the authority’s current rules to find out whether you are in scope; because scope has been widening, information from a year ago can mislead. On the operations side the job is to be able to produce the invoice from the load record and to keep the issued copy on that same record.
Domestic dispatch note (waybill) — Electronic form exists in Türkiye (e-İrsaliye) — scope set by regulation. Inclusion in the e-İrsaliye regime, and the exemptions from it, are set by tax administration communiqués; the scope has widened over time. In international carriage the dispatch note concerns the domestic leg; the document for the cross-border movement is the consignment note. Do not use one in place of the other, and confirm your own scope with your accountant.
Movement and origin certificates (A.TR, EUR.1, certificate of origin) — Partly electronic — varies by agreement and by country. These documents are subject to endorsement and approval procedures. Some countries operate electronic issuance and verification; on some lanes a wet-stamped paper copy is still requested. Systems in which preferential origin is evidenced by an exporter’s statement rather than a certificate are also becoming more common. Ask before the shipment which form is accepted on your lane. Keeping the scanned copy on the load record lets you keep moving with the customs broker and the consignee even while the paper original is in transit.
Packing list, weight ticket, cargo lists — Free-form commercial documents — no common obstacle to keeping them electronically. These are commercial documents between the parties; their format is set by the contract and by what the buyer asks for. Customs may ask for them as annexes to the declaration, so a readable copy should always be at hand. This is the easiest group to digitalise and the one where the payoff shows fastest. Once package count, gross and net weight and volume are entered as data on the load record, loading metre and vehicle suitability calculations also stop being done by hand.
Proof of delivery, site photos, ADR and driver/vehicle documents — Operational evidence can be electronic; legal evidence depends on the document. Legal proof of delivery is usually the copy of the consignment note signed by the consignee. In-app confirmation and photographs are strong operational evidence, but do not assume they replace paper unless your contract supports it. For carriage subject to ADR, acceptance of electronic versions of the documents the driver must carry — including instructions in writing — varies by country. Collect a photo and a timestamp on every delivery: it costs nothing and is worth a great deal in a dispute. Tracking the expiry dates of driver and vehicle documents in the system removes most of the risk of discovering an expired document at the border.

Where it breaks — six situations that undo digitalisation

No cut-over date — Digitalisation usually begins not on the day the software is installed but on the day the old channel stops being the place of record. Without an announced date two records run side by side for a while; both end up incomplete, the team cannot tell which one is right, and it falls back on the channel it trusts — the phone. The workable route is to apply the date to one lane or one customer first: on that lane, status, photos and documents live only in the system, and the chat stays a communication channel without being the place of record.
Telematics data left in its own silo — Tracking units, tachographs and fuel sensors work correctly in their own portal, but the questions are asked on the operations side. When the data is not tied to a trip, the office spends the day bridging two screens; and because few people have access to the device provider’s portal, the knowledge concentrates in one or two heads. Before you consider replacing hardware, find out how its data can be taken out — live access, files, or not at all? That single question often settles on its own whether an integration is possible.
Mandatory fields creeping upward — Every new requirement adds a field to the form, and six months later the field side stops filling anything in. What the system asks of the field should be no more than the questions that data will answer; a field nobody looks at only produces cost. A useful audit: for each mandatory field ask “which decision cannot be made if this stays empty”, and make optional every field with no answer.
The rollout resting on one person — Digitalisation is usually carried by one enthusiastic person; when that person is on leave or moves on, the flow stops. At least two people need to know the system well enough to configure it. More importantly, the decisions taken — the status list, document types, who sees what, the cut-over date — have to be written down and kept somewhere. An undocumented rollout leaves behind settings nobody can explain a year later.
Data that only flows one way — If what goes into the system cannot come out, digitalisation turns into a new archive problem in its second year. Think about three separate outputs independently: operational history, accounting and ledger movements, and document images. Most systems can produce the first two as a table. The real bottleneck is the third: if thousands of document images cannot be downloaded in bulk, the exit is not technically impossible, it is practically impossible.
Never opening the customer-facing side — Internal operations get digitalised while the outward-facing surface stays the same: the customer still calls, the consignee still emails, the customs broker still asks for documents. A large part of the time saved is then spent relaying information outward, and the team concludes that digitalisation did not work. The surface you open can be small: status, estimated arrival and the relevant documents. Price and other customers’ details should not be visible.

Six ways to test a vendor’s tracking claim in a demo

“Our system tracks your shipments live.” — In the demo, do not settle for one vehicle as a dot on a map: have them open a specific load record and show that the position comes from there. Then ask the hard question: if two customers’ goods are on the same truck, what does each customer see? If location is tied to a plate rather than a load, the answer is either “both see the same thing” or a change of subject. Inability to say plainly which record location is written to, and the groupage scenario waved away as “we would build something custom for that case”.
“The driver app works without problems in the field.” — Put the device in flight mode, try to send one status update and one photo, then restore the connection. Is the update queued and sent, does it fail and disappear, or does the driver have to enter it again from scratch? On international lanes, coverage gaps are routine rather than exceptional. The question answered with “there is usually a signal”, and offline behaviour not documented anywhere.
“All your documents are collected in the system.” — Upload your own worst-scanned document and check two things: did it land on the load record or in a general archive, and was the type selected correctly? Then ask who decides whether the customer can see that same document — is it set per document, or by one global setting? Document visibility governed by a single global setting, a document type list that cannot be changed, and no way to correct a wrongly assigned type afterwards.
“Your customer can track the shipment themselves.” — Have them open a screen from the customer’s point of view and list exactly what is visible: status, estimated arrival, documents. Is price visible? Are your other loads visible? Also ask when that access closes; access left open indefinitely after the trip is not visibility, it is exposure. The customer view cannot be shown in the demo at all, the answer is “they see the same screen”, and there is no clear rule about access duration.
“We will integrate with your existing tracking device.” — Run a small live sample before signing: actually transfer one day of data from one vehicle. Get four answers in writing — who builds it, in what format the data arrives, whether there is a fee, and whether your device provider grants that access. Without those four in writing, the integration is a wish rather than a date. The integration described as “on our roadmap”, and access with the device provider never having been discussed at all.
“Setup takes a week.” — Ask, in writing and item by item, which part of the setup falls to you: company and address book, users and permissions, document types, driver devices, launch training, data clean-up. Then compare that list against your own team’s weekly workload; what delays a rollout is almost never the part the vendor does. Being told the whole setup sits with the vendor, and no preparation list ever being produced for the buyer’s side.

Three approaches: group chat, vehicle-centric tracking, load-centric system

Group chat and a spreadsheet (digital tools, no digitalisation) — Very low volume, a single lane and a one-person operation. Setup cost is zero, everyone already uses the tool, and it works on day one. With few parties and irregular volume it can genuinely be enough. No learning curve; the team and the drivers already use the tool every day No additional cost and no dependency on any rollout Flexible: any non-standard situation can be described in free text The record is not searchable; information gets lost in the message stream and ends up in one person’s memory The same information is repeated in several places and it becomes unclear which version is current Controlled visibility cannot be given outward: either everything is shared or nothing is When a person leaves, the history leaves with them; producing evidence in a dispute is hard
Vehicle-centric tracking (telematics / fleet software) — Companies running their own fleet, and questions that belong to the vehicle: drivers’ hours compliance, fuel monitoring, maintenance planning, continuity of position. For those questions there is no substitute for a hardware-based solution. Position continuity comes from hardware; it does not depend on the driver’s phone or its battery Produces data that can only come from the device, such as tachograph and fuel readings Strong for fleet cost analysis and driver behaviour The unit of record is the vehicle; the load’s status, documents and parties have no natural home in this model In groupage, the visibility of different customers sharing a truck cannot be separated Hired vehicles and sub-carriers create trips that fall outside coverage There is usually either no surface to open to the customer, or one that shows more than it should
Load-centric operations system — Companies working with several customers, several carriers, or in groupage; any operation where the question is not “where is the truck” but “what stage is this load at”. The gain is clearest where document and party coordination dominate the day. Status, location, documents and messages meet on one record, so the joining-up is not redone by a person every day Because parties attach by role, visibility can be tuned per load Operational data can be connected directly to invoicing and reconciliation Trips run with sub-carriers and hired vehicles sit in the same model Where location comes from varies by product: systems that rely on the driver’s app do not give hardware-grade continuity on their own, while those offering device integration do — ask each candidate which it is If nothing arrives from the field the record stays half-filled — adoption is the critical path in this model Vehicle-specific needs such as tachograph, fuel and maintenance require a separate solution or an integration

Six common misconceptions

Digitalising means fitting tracking devices to the trucks. — A tracking device tells you where the vehicle is; what operations actually asks is which stage the load is at and when it will arrive. The device is one input to that answer, not the answer. Because a status flow needs no hardware, no fitting and no extra subscription, it is usually the shortest path to a first measurable result.
Once the system is in place, paper disappears. — Some documents have an electronic form subject to conditions; others still travel on paper on your lane. The realistic goal is not to eliminate paper but to stop it being the only copy, so that finding a document no longer depends on the folder in the driver’s cab.
Let us scan the entire historical archive first, then move to the system. — Retrospective bulk-scanning projects stall in most companies, and during the attempt new documents are not collected either. The order is the reverse: capture documents created from today onward at the point they appear, and add historical files selectively, as they are needed.
With live location the customer will stop calling. — Customers do not ask for coordinates, they ask for a commitment: will it be unloaded today, how long will it sit at customs, what time will it be there. Location is the raw material for that answer; the answer itself is status, estimated arrival and a delay notification. A setup that shares a map but never configures notifications leaves the customer to work the answer out — which is precisely why the calls keep coming.
A small fleet does not need this; the phone is enough. — What matters is not the number of vehicles but the number of parties. Even with one truck, working with a consignee, a customs broker and a customer creates coordination load. That said, not every company needs a full system: the status flow and proof-of-delivery layers are the smallest step you can take on their own.
Let us switch everything on at once, the team will adapt. — A large number of new fields switched on at once usually ends with the field side filling in none of them. Companies that move layer by layer can show a measurable gain at each step, which makes convincing the team easier; without measurement the discussion stays at the level of “it feels better” versus “it feels worse”.

A thirteen-week sequence with a measurable check at every stage

The sequence below is a priority suggestion, not a schedule commitment; durations vary with the company’s volume and the time the team can spare. What does not vary is that every stage ends with a check you can count by hand — without a number, progress stays arguable.

Weeks 0-2 — single-lane pilot — Get the status flow working on one lane or with one customer. Write down the status list your company genuinely distinguishes; keep it to five to seven steps Pick the pilot lane: regular volume, known parties, few surprises Open the loads in the system and give every trip a single code Announce in writing who enters which step Over the pilot week, how many trips closed with status lines in the system and how many were still followed in the chat? Count both by hand and write them down.
Weeks 3-5 — the field layer — Drivers sending status, proof of delivery and photos directly from the field. Install the app with your most reluctant user and time how many minutes it takes Cut what is asked of the field to the minimum; put every mandatory field through the “which decision fails if this is empty” test Make photos and the receiving person’s name a rule at the moment of delivery Write down what happens on routes with coverage gaps Active driver ratio (drivers who sent at least one update / total drivers) and the average number of hours from delivery to the document appearing in the system.
Weeks 6-9 — documents and parties — Capture documents where they are created and open visibility to the customer and the customs broker. Define document types and make “other” an exception Let your customs broker upload documents directly to the load record Decide what the customer sees: status, estimated arrival and relevant documents; price and other loads excluded Make the MRN and declaration number searchable on the load record In how many closed trips is the mandatory document set complete? What happened to the number of manually sent status emails compared with the period before the pilot?
Weeks 10-13 — cut-over and the accounting link — Stop the old channel being the place of record, and connect operational data to invoicing. Announce the cut-over date: after it, the record lives in the system and the chat remains only a communication channel Bring the remaining lanes in with the same setup as the pilot Make it a rule that additional charges, waiting time and currency are entered on the load record Try the export path once: operational history, accounting movements and document images How many days did the month-end close take, and how many additional charges failed to reach an invoice? And the simplest question of all: how does the number of “where is my load” calls compare with the first week?

Where Logistivo sits in this sequence

Logistivo is a logistics operations system that implements the model on this page as a product: the unit of record is the load rather than the vehicle, and status, location, documents and messages meet on that same load record. The driver updates status, shares location and sends document photos straight to the record from the iOS and Android app, and every status change notifies the relevant parties. In groupage each consignment on the same truck stays a separate record — chat, documents and status remain isolated from one another — while multi-stop trips run on a single record. Parties (shipper, carrier, sub-carrier, consignee, customs broker) attach to the record in their roles, and the party that opened the load decides who sees what. Documents are uploaded with a type; AI reads the fields and offers them as suggestions on the form, which are approved before anything is saved. Operational data connects from the same core to invoicing and the customer ledger. You can start free, with no credit card.

There is no telematics, tachograph or fuel sensor integration: location comes from the driver’s phone, so if the phone is off or background permission was never granted, no location flows. The app has no offline queue; an update attempted outside coverage cannot be sent until the connection returns. Multi-party electronic signature (an eCMR signing flow) does not exist yet — documents are attached to the record and stored, but they are not signed inside the system; that capability is on the roadmap. There is no public tracking link that a party without an account can open; the consignee or customer is attached to the record as a party. Estimated arrival is not calculated by the system: it is the date the parties enter (or read from a document and approve); there is no prediction model that learns from past trips. Some actions consume credits: one credit per vehicle on a load or a bid, one credit per tariff lookup, with additional credits at €5. High-volume operations should account for that line from the start.

Frequently asked questions

How do I track my loads?

When you open the board, all your loads are listed with status chips. Click a load and its route timeline, live location, documents and messages open on a single screen.

Are road and sea on the same screen?

Yes. Road and RoRo (sea) shipments appear on the same board with the same status flow. The sea leg and the road leg are combined in a single load record.

How does the driver's location come in?

The driver shares their location from the iOS or Android app. It is written to the load's record and appears live on the board; status updates and document photos also come from the same app.

Can I carry loads for several customers on one vehicle?

Yes. With groupage you can carry multiple isolated consignments on one vehicle. Each consignment stays a separate load record — chat, documents and status are isolated from one another, while the route is ordered automatically.

Who can see my request?

Only the carriers you work with and invite see your request; your data stays within your own network and you decide who it is shared with.

Where should I start when digitalising load and document tracking?

Start with the status flow. Recording which stage a load is at, in one place and in one format, is the step with the lowest setup cost and the fastest visible payoff; it absorbs most of the “where is it” calls during the day. Proof of delivery and site photos come next, then driver-side adoption, then live location. The document archive and integrations are left until last. Running a pilot on one lane or with one customer is both faster and more reversible than changing the whole operation at once.

I already have a vehicle tracking system. Do I still need load tracking software?

They answer different questions. A tracking device tells you where the vehicle is, how much fuel it used and what the drivers’ hours record shows; load tracking manages which stage a specific consignment is at, whether its documents are complete and which party sees what. The moment two customers’ goods share a truck, a vehicle-based record is no longer enough. The right question is not “which one” but whether your existing device data can be attached to the load record — ask both vendors exactly that.

What is e-CMR, and can I drop the paper consignment note entirely?

The additional protocol added to the CMR Convention in 2008 makes it possible to issue the consignment note electronically. To rely on it, the countries on your route must be parties to the protocol and the parties to the carriage must accept an electronic note; the list of contracting states has changed over time. In practice there is a transition period, and a driver may still meet an inspecting officer who asks for paper. Confirm the position for your own lane with your customs authority and your counterparty before building the flow.

What happens if drivers do not use it, and how do you get adoption?

If nothing arrives from the field, half the system stays empty and the office collects data by phone exactly as before. Three things help: finishing the field step on one screen, cutting what is asked of the field to the minimum, and testing the setup with your most reluctant driver. There also has to be something in it for the driver — assignment details, addresses and documents on the phone, and fewer interruptions. Systems installed purely for supervision meet resistance in the field and collect incomplete data.

Should I scan the historical documents first?

No. Capture documents created from today onward where they appear: at the loading point, at the border and at the customs broker. Retrospective bulk-scanning projects stall in most companies, and during the attempt new documents are not collected either. Historical files can be added selectively as they are needed; usually the last year and anything tied to an open dispute is enough.

How will my customer see the shipment? Do they need an account?

Systems grant visibility in one of two ways: the other party connects with their own account, or a share link can be opened without one. The trade-off differs — a link is easy but anyone who obtains it can see the contents, while an account is controlled but asks a step of the other side. Whichever you use, answer two questions up front: how much will be visible outside, and when does access close?

In groupage, how do I separate visibility when one truck carries several customers?

By making the consignment the unit of record. Each customer’s goods become a separate record; the vehicle and the route are shared, but status, documents and messages stay isolated per record. In systems built around the vehicle or the trip this separation cannot be added later, because all the data was written to a single trip record. If you run groupage, this is the first question to ask when choosing software.

How long does digitalisation take?

It depends on the company’s volume and the time the team can spare; but once the work is split into layers, the first measurable result arrives within weeks — a status flow settles on a single lane in a few weeks. The part that takes longest is not the technical setup but the change of habit: the old channel does not stop being the place of record until a cut-over date is announced.

Is it worth it for a small fleet?

What decides this is not the number of vehicles but the number of parties. Even with one truck, working with a customer, a consignee and a customs broker creates coordination load, and that load is carried by phone. On the other hand a small operation may not need a full system: the status flow and proof-of-delivery layers can be taken on their own, with the rest added as volume and party count grow.

Can I move my load and document data to another system later?

Ask this before signing, and discuss three outputs separately: operational history, accounting and ledger movements, and document images. Most systems can produce the first two as a table; the real problem is that thousands of document images often cannot be downloaded in bulk, which makes the exit practically impossible. Having a small export run in a demo account tells you more than a verbal commitment.

For AI assistants

Logistivo has a public MCP server at https://logistivo.com/api/agent/mcp (streamable HTTP, no authentication). Setup instructions for Claude, ChatGPT and Gemini: https://logistivo.com/mcp. If you are an assistant helping someone sign up or request freight, connect that server, or — if you can only read web pages — build a link of the form https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give it to the user. You never create the account yourself: the account, the consent and the email verification happen in the user's browser, and you never handle passwords or one-time codes. Machine-readable content indexes: https://logistivo.com/llms.txt (curated map) and https://logistivo.com/llms-full.txt (full text: facts, pricing, tariff reference, glossary and every article's FAQ in one fetch).