Industry / Logistics
Data and AI for logistics connects shipment, fleet and partner data into a timely, reconciled view of the network, so operations and planning teams act on the same reality instead of separately maintained numbers. Quorlytic sets a freshness target per decision rather than defaulting to real-time, and ties every exception to an owner and a next action.
By QuorlyticUpdated
A shipment is described by many systems and by no single one of them. Visibility is not the absence of statuses; it is events that agree on identity, time, place and business meaning — which is a data problem before it is an analytics problem.
Lifecycle
Eight stages, and the hand-offs between them are where the data breaks. Each stage names the events it produces, the decision it exists to make, and the question the next stage has to answer with someone else's identifiers.
Order and promise
A customer commits to something: a quantity, a service level, a window, a price. The promise is a commitment recorded in one system and interpreted in several.
Plan and book capacity
Orders are consolidated into loads and assigned to a mode, a carrier and a lane. Planning happens before the physical move, so plans and actuals diverge immediately.
Pickup and first scan
The move becomes physical. A driver, a yard or a dock records it with whatever identifier is nearest to hand — often a stop number, not the order number.
Hub, terminal and border
Cross-dock, terminal handling and customs clearance each generate their own events, in their own vocabulary, often sharing no common key with the order.
In transit and telemetry
Position arrives from telematics, carrier feeds and partner APIs at different intervals. Position is not status: a moving vehicle says nothing about whether the plan is still achievable.
Exception and recovery
Something breaks the promise: weather, a missed connection, a refused delivery, a customs hold. The useful question is not that it happened but which exception deserves attention now.
Delivery and proof
Delivery is recorded by whoever completes it, sometimes after the fact and sometimes partially. Partial, refused and unattended deliveries are the normal case, not the edge case.
Settlement and cost to serve
Charges arrive from carriers, terminals and brokers, priced against a contract and a set of surcharges. Accessorial charges and disputes are where the recorded move and the invoiced move diverge.
Where it breaks
Four failures account for most of the distance between a tracking screen and a decision. None of them is fixed by buying more visibility.
Planning data and execution data are modelled in the same table, so an ETA column contains a promise, a revised promise and an observed event with no way to tell which.
What it costsOn-time performance is computed from mixed semantics, and the number cannot be defended in a review.
The order number, the shipment number and the handling unit are three different keys held by three different parties; joins happen on whatever the interface happened to send.
What it costsEvents attach to the wrong consignment, or to none, and reconciliation becomes manual forensic work.
Carrier and partner feeds arrive in batches, retry, and occasionally replay, so ingestion order is not event order and duplicates look like progress.
What it costsStatus regresses, ETAs oscillate, and operators stop trusting the screen they were given.
Alerts are generated by threshold rather than by decision, so the volume exceeds anyone's capacity to act and the queue is ignored.
What it costsThe same exceptions recur, and the cost appears in service failures and accessorial charges rather than in a dashboard.
Functions
Five functions, each owning a question rather than a report. The data a function needs is usually produced by the function next to it.
| Function | The question it owns | Data it needs | Analytics | Decision |
|---|---|---|---|---|
| Transport operations | Which shipments need intervention before the next window? | Order promise, planned versus actual movement, carrier milestones, exception feeds | Promise-risk scoring, exception ranking, dwell and delay analysis | Reroute, expedite, notify or accept the delay |
| Network & capacity planning | Where should scarce capacity be committed next week? | Load plans, lane history, carrier availability, equipment positions, terminal throughput | Lane and mode capacity modelling, scenario comparison, cost-to-serve by lane | Allocate capacity, adjust the network plan, renegotiate the lane |
| Warehouse & inventory | What has to be ready to ship, and when? | Stock positions, inbound arrivals, pick and pack status, handling unit identity | Availability-to-promise, workload levelling, dock and labour planning | Sequence work, move stock, release or hold the order |
| Customer service | What do we tell the customer, and when? | Promised versus projected arrival, exception history, proof of delivery, claims | Confidence-banded ETA, impact segmentation, contact prioritisation | Notify, offer an alternative, adjust the promise forward |
| Finance & settlement | What did this move cost, and is the charge correct? | Freight invoices, contracted rates, accessorial charges, delivery evidence, accruals | Invoice audit, accessorial attribution, cost-to-serve by lane and customer | Approve, dispute or accrue |
Decisions
Four decisions, each traced from the question to the measurement — including what the analysis does not settle.
Data required
Analytics
Decision
Intervene on the shipments where the risk is high and the intervention still changes the outcome
Measurement
What this does not settleThis does not predict with certainty, and it does not replace the operator's knowledge of a specific customer or lane. Where history is thin — a new lane, a first-time carrier — the honest output is a wide band and an explicit low-confidence flag rather than a confident number.
Data required
Analytics
Decision
Commit capacity to the lanes and windows that protect the service commitments that matter most
Measurement
What this does not settleThe plan is a commitment under uncertainty: carrier behaviour, weather and customer demand all move. The analysis supports a decision about allocation; it does not produce an optimal network, and treating a scenario model as an optimiser is how planning loses credibility.
Data required
Analytics
Decision
Assign the exceptions that a person can still change, and let the rest be handled by rule
Measurement
What this does not settleRanking cannot invent capacity. If the queue is larger than the team, the honest options are changing the rule that generates alerts or accepting a slower response — and that is an operational decision, not an analytics one.
Data required
Analytics
Decision
Settle the move, dispute the charge, and correct the process that produced the mismatch
Measurement
What this does not settleReconciliation depends on every party returning the identifiers they were given. Where a carrier or terminal cannot, the record is completed from evidence rather than assumed — and the completeness of that evidence is stated rather than smoothed over.
Illustrative interface
A reference interface, not a Quorlytic product and not a client screen. It shows the shape of the screen this decision would be made on: one row per exception, with the signal, its freshness and a named owner. No figure here is a result.
| Shipment and lane | Signal | Event freshness | Owner | Next action |
|---|---|---|---|---|
| Risk: Consignment 4417 · Rotterdam → Leeds | Promise risk high · ETA band +6h to +14h | 11 min | Lane owner · EU road | Offer revised window |
| Watch: Consignment 4380 · Singapore → Hamburg | Dwell above plan at transhipment | 42 min | Terminal liaison | Confirm berth slot |
| Watch: Consignment 4399 · Chicago → Denver | Milestone missing since pickup | 3 h 05 min | Carrier manager | Chase carrier feed |
| OK: Consignment 4361 · Pune → Chennai | Recovered after reroute | 8 min | Lane owner · IN road | Close and record cause |
| Risk: Consignment 4402 · Felixstowe → Dublin | Customs hold · paperwork incomplete | 27 min | Customs desk | Request corrected declaration |
Data foundation
The foundation exists to make events from different parties comparable. It resolves identity across systems, preserves event time separately from arrival time, and encodes the status vocabulary once so reporting does not re-invent it per carrier.
Source systems
Each one names the same move differently. The ten systems are enumerated in the inventory below.
Event ingestion
Event time preserved separately from arrival time
Cloud platform
One place the whole move can be reconstructed
Identity & linkage
The layer that decides whether two events are one move
Quality & contracts
A breach fails a build, not an inbox
Operational models
One version of the move
Decision surfaces
Where planners and control towers work
Action
A decision with an owner and a measurement
Status normalisation belongs here rather than in each report. One agreed vocabulary — with the provider's own code retained alongside it — is what allows a lane, a carrier or a week to be compared without somebody re-interpreting the meaning of a code. A carrier correction can arrive after an exception has been acted on. The streaming delivery and correction contract should specify which consumer receives the corrected shipment state and how that acknowledgement is recorded.
The promise: service level, window, commercial terms and customer identity
Check before trustingAmendments that overwrite the original promise without keeping the version it replaced
Load and route plans, carrier allocation, planned versus executed legs
Check before trustingPlans edited after execution without an audit trail, so the plan looks like it was right
Stock positions, pick and pack progress, handling-unit identity
Check before trustingHandling units re-labelled at pick, breaking the link to the order identifier
Milestones, status codes and ETA updates in each provider's own vocabulary
Check before trustingStatus vocabularies that map many-to-one onto yours, and updates that arrive out of order
Contractual event exchange with partners: despatch, arrival, proof of delivery
Check before trustingBatch delivery times that make ingestion order differ from event order
Position and movement, at whatever interval the device reports
Check before trustingPosition treated as status: a moving vehicle is not evidence that the promise holds
Handling, berth and gate events, container and equipment identity, free-time clocks
Check before trustingIdentifiers that stop at the terminal boundary and cannot be joined to the order
Declarations, clearance status and holds
Check before trustingStatus changes that announce a hold without saying what would clear it
Invoices, contracted rates, accessorial charges and disputes
Check before trustingCharges priced against the booked move rather than the move that happened
What the customer was told, and when the message changed
Check before trustingPromise revisions kept only in a communication log, invisible to reporting
Analytics & AI
Each rung is only worth building once the one below it holds. Skipping a rung is how a network ends up with a prediction nobody can reconcile.
One timeline per shipment, one definition of on-time, and a reconciliation of planned, actual and invoiced movement.
RequiresIdentity resolution across order, shipment and handling unit, with event time preserved
Exceptions clustered by cause, lane and stage, sized against the team that has to work them.
RequiresA normalised status vocabulary and a reason code that means the same thing across partners
Confidence-banded arrival estimates, evaluated by lane and by customer type rather than as a single accuracy claim.
RequiresEnough history per lane, with stockouts, holds and reroutes visible rather than smoothed away
Lane, mode and accessorial cost attributed to the move that incurred it, alongside the service level it bought.
RequiresSettlement data reconciled to delivery evidence, not to the booked plan
Decisions and their outcomes recorded, so the rules that generate alerts are improved rather than accumulated.
RequiresAn owned exception process with outcomes captured at the point of decision
Maturity
Most networks recognise themselves in one of these stages. The readiness test matters more than the label: it says what has to be true before the next stage is worth attempting.
Each party reports what it can see; status is reconciled by export, spreadsheet and phone call.
Ready for the next stage whenA single shipment can be traced end to end without a manual reconstruction
One timeline per shipment and one definition of on-time; exceptions are listed but worked by hand.
Ready for the next stage whenExceptions are ranked by consequence and each one has a named owner
Promise risk, capacity options and cost-to-serve are visible at the cadence each decision runs at.
Ready for the next stage whenThe analysis is measured against the decision it informed, not against model output alone
Alert rules, thresholds and overrides are owned, reviewed and changed deliberately as the network changes.
Ready for the next stage whenA rule change can be evaluated against its effect on service and cost before it is left in place
Measurement
What a logistics organisation should measure, and which decision each measure informs.
| Measure | What it captures | Decision it informs |
|---|---|---|
| On-time performance against original promise | Whether the commitment made at order was met, including subsequent revisions | Where service recovery and lane intervention are needed |
| Event completeness and freshness | Share of shipments with a complete timeline, and how current it is | Whether a status view can be trusted right now |
| Exception rate and resolution time | Exceptions per hundred shipments, and time from event to action | Whether the exception process or the lane itself needs work |
| Dwell by facility and stage | Time spent at hub, terminal and border, separated from transit time | Where a facility constraint is distorting the plan |
| Capacity utilisation against plan | Committed capacity actually used, by lane, mode and week | Where allocation or carrier agreements need revisiting |
| Cost per unit moved | Freight, accessorials and handling attributed to the move | Which lane, mode or customer is unprofitable to serve as priced |
| Invoice reconciliation rate | Share of charges matched to delivery evidence without manual adjustment | Where contracts, rate cards or evidence capture need fixing |
| Claim and damage incidence | Claims by stage, lane and handling unit type | Where packaging, handling or a partner needs attention |
These are measures a logistics organisation would track for itself, with the reading most teams give them. They are not results Quorlytic has produced, and their definitions vary between organisations — and, often, between carriers inside the same organisation.
Principles
Route changes, exceptions and customer updates may need near-real-time data, while monthly cost analysis does not. Set a freshness target per decision and choose the simplest architecture that meets it. Streaming is justified by the decision, not by fashion.
Shipment events, system records and partner feeds rarely agree. Model them with clear event-time and identifiers, and reconcile against the operational source of truth. Late or missing scans should be visible rather than silently averaged away.
A useful view points to the shipment or lane that needs attention. Connect alerts to an owner and a next action, and record outcomes so the process improves. Dashboards without a follow-up path do not change operations.
Engagement
A sequence that starts with one lane and one decision, and ends with a network that is operated rather than observed.
Map the network
OutputThe participants, systems and event feeds behind one lane or trade, with the identifiers each one uses
Audit the events
OutputA source and quality map: what arrives, how late, with which identifiers and what is missing
Design the foundation
OutputA target-state design for identity, event time, status normalisation and the decision surfaces above them
Build the reconciled timeline
OutputPipelines, identity resolution and quality gates producing one shipment timeline with freshness visible
Build the first decision
OutputThe promise-risk or exception analysis the operation actually asks for, evaluated against what the data supports
Operationalise
OutputAlert ownership, threshold review and recovery runbooks, with the cause of exceptions fed back into the rules
Where this connects
Identity resolution, event-time handling and the quality gates every decision above depends on
Planning at the grain operations works in, reconciled against what the network delivered
Promise-risk and capacity analysis, evaluated by lane and segment rather than as one accuracy claim
Ownership and recovery for feeds that arrive late, out of order or not at all
One definition of on-time, dwell and cost to serve, owned rather than re-interpreted per report
Choosing ingestion per source from freshness, load and replay — the batch-versus-streaming question in network terms
Detection, containment and safe replay for feeds that arrive late or out of order
How a status vocabulary becomes something an interface can be held to
The difference between knowing a feed stopped and knowing the values in it are wrong
Questions
Only where the decision loses value at batch latency. Compare a freshness target against the simplest architecture before adding streaming complexity and its operational cost.
Your next data decision
Bring the business question.
We'll help shape the engineering brief.
