Algeria AgencyArtificial intelligence
AI in logistics: the list of abnormal parcels, before the customer calls
A network learns about its incidents by telephone. The parcel in trouble is the one that produced no event, and that is exactly what tracking cannot see.
A carrier in Rouiba, Tuesday morning. Customer service takes the fourth call of the day on the same subject: a parcel announced for yesterday, which has not arrived and about which tracking has said nothing. It has been at the depot since the day before, nobody loaded it, and nothing in the system flagged it.
That is the normal state of this trade, and it is not a fault in the tracking tool: it is a consequence of its design. Tracking displays events, and a parcel in trouble is precisely the one that has stopped producing them. What an artificial intelligence system can add here is the list of silences, every morning.
This article describes how that list is produced, who it is addressed to, and what must not be done with it. It does not repeat what the recipient really wants to know, nor how a round is built, which are covered elsewhere.
The parcel that has not moved for thirty hours
Take the crudest possible definition and see what it gives in your network: every parcel whose last event is more than thirty working hours old and which is not delivered. On most networks that single query returns between two and five per cent of parcels in transit.
The figure does not need to be exact to be useful. What it tells you is the order of magnitude of the work: if your daily list is ten lines, one person clears it before noon; if it is three hundred, your problem is not detection, it is the flow itself, and no list will change that.
Most carriers have never run that query, not through negligence but because the system is designed to answer "where is this parcel" and not "which parcels are silent". The first question starts from a number; the second starts from nothing, and it has to be asked explicitly.
Before any project, have somebody with access to the database run it once. It is an hour of work, and it tells you whether the rest of this article is worth reading.
What "abnormal" means in your network
The thirty-hour threshold is a starting point, not a rule. A road shipment from Algiers to Oran and a shipment to a remote commune in the south do not share a normality, and a system applying the same threshold to both will produce silly alerts on one and silence on the other.
The useful definition is built per route and per stage, and it is written from what your data already shows: for each pair of depots, how long a parcel usually takes. It is not a prediction, it is descriptive statistics on your own history, and it is within reach of a spreadsheet.
Three states are worth separating, because they call for three different actions. The parcel that is late but moving, which asks for nothing. The parcel motionless for longer than its stage’s normal, which asks for a look. And the parcel that produced a failure event — address not found, recipient absent — which asks for a decision, and which the round already handles.
Writing those three definitions is half the work of this subject, and it is the half nobody can do for you. A supplier arriving with thresholds already written is describing a different network.
The signals you already have, with nothing installed
A network, even a lightly computerised one, produces four usable families of trace. Stage scans, which are the most reliable. Statuses entered by depots, looser but rich. Round returns, often noted by hand. And inbound calls to customer service, which are a trace of a problem, with a lag.
The fourth family is the one never used and it is instructive: the distribution of inbound calls by route and by depot draws the map of the network’s difficulties, with no sensor and no model. Three weeks of roughly classified calls say more than a six-month project.
What is almost always missing is not the data but its timestamp. A status entered in the evening for the whole day makes any stage-duration calculation impossible; the correction is not technical, it is organisational, and it costs an instruction rather than software.
The preparatory work therefore fits in one sentence: check that each event carries the time it happened and not the time it was entered. Without that, everything below rests on sand.
The absence of an event is the strongest signal
This is the article’s central point. Every tracking tool reacts to what happens: a scan, a status, a delivery. The parcel in trouble is the one producing nothing, and an event-driven system cannot react to a non-event — you have to go and look for it.
Concretely that means a daily query walking the open parcels and computing, for each, the time since the last sign of life, compared with its stage’s normal. That is not artificial intelligence, it is a subtraction, and it produces four fifths of the benefit.
The second absence signal, subtler, is the parcel that skipped a stage: arrived at destination without having been recorded at departure, or delivered with no round scan. It causes the customer no problem, it causes your data a problem, and it is what will make your route statistics wrong in six months.
Keep the wording, it transfers beyond logistics: a system that listens only to events is blind exactly where the incident happens.
What a model adds, and what a rule is enough for
It is worth being honest about machine learning’s real share here, because it is smaller than you will be told. Thresholds per route, motionlessness detection and spotting skipped stages are rules; they are computed, explained and corrected, and they need no model.
What a model genuinely adds is ranking the remaining cases by probability of failure, from combinations nobody would write by hand: this pair of depots, this weekday, this parcel size, this type of recipient. It is useful when the daily list is too long to be worked through, and only then.
The practical consequence is an order of work that saves a lot of money: build the rules first, measure how many lines they produce, and consider a model only if the volume demands it. Many networks find the rules are enough.
And if you do reach a model, insist that it shows why a line is ranked high. An ordered list with no justification is unmanageable for the person working it: they can neither dispute it nor learn from its mistakes.
The list is addressed to a person, not to a dashboard
An anomaly list displayed on a management screen produces no effect. It has to be addressed: a name, a time, and a state updated in one gesture — seen, chased, resolved.
The right recipient is almost never customer service, whose job is to answer what comes in. It is the depot manager or the operations lead, who can make a parcel move. Addressing the list to customer service turns a capacity to act into a stock of worrying information.
Size matters more than precision. A ten-line list worked through every morning beats a hundred-line list perfectly detected and never opened; if you have to choose, tighten the thresholds until you get a volume one person clears in thirty minutes.
That constraint has to be written into the specification, or the tool will deliver everything it can detect. The right request is not "detect all anomalies", it is "give me the twenty that matter today".
What the system does not tell the recipient
The immediate temptation, once the list exists, is to notify the recipients concerned automatically. That is the moment to stop: a delay notification sent before the network has decided what to do produces an inbound call, not a reassured customer.
The rule that holds is sequential. The list goes to the manager, they decide — chase, reroute, call the recipient, or nothing because the parcel leaves tonight — and the information leaves the network only once there is something to say. Warning with no usable news is a confession, not a service.
There is one clear exception and it is commercial: the missed appointment. If a recipient is waiting for a delivery at an announced time and it will not happen, the information has to go immediately, because it frees their time. The difference from the previous case is that here the absence of information costs them, not only you.
So the system may write to the recipient in one case only: where a specific commitment will not be kept. Everywhere else it writes to somebody in your network.
Warning before being asked: service or confession
Many networks hesitate to report a problem before the customer notices it, and the hesitation is well founded: some late parcels arrive on time anyway, and warning would have created needless worry.
The dividing line is not lateness, it is irreversibility. A late parcel leaving tonight does not need announcing. A parcel known not to be leaving today, or needing rerouting, or with a wrong address, belongs to the customer: hiding the information only moves the call two days later.
There is a third case, specific to online retail, and it deserves naming: the shipper. When you deliver for a merchant, the information belongs first to that merchant, who decides what to tell their customer. A carrier writing directly to the recipient short-circuits a commercial relationship that is not theirs.
So write three rules rather than one, one per addressee: what goes to the internal manager, what goes to the shipper, what goes to the final recipient. They are not the same, and a tool providing only one will conflate them.
Cash on delivery changes the nature of the anomaly
A motionless parcel carrying a payment is not merely a late parcel: it is money that is not yet money, ageing in a state nobody is accountable for.
The consequence is that the list has to separate those parcels and raise them faster, with a shorter threshold. It is not a customer-service question, it is a cash and risk question: a stuck parcel with a payment attached is a potential dispute between you, the merchant and the recipient.
The second consequence concerns returns. A refused parcel coming back with its payment cancelled has to produce an identifiable event, because that is the one to be reconciled against the merchant’s remittance — and that is the most frequently disputed reconciliation in this trade.
The system has nothing to decide here. It has to make those cases separately visible, and leave the decision to somebody who knows the commercial relationship.
False anomalies, and the cost of crying wolf
A list containing too many normal cases is ignored within two weeks, and the mechanism is the same everywhere: the person working it learns that half the lines ask for nothing, skims, then stops opening it.
False anomalies have three recurring sources, and all three are corrected without a model. Non-working days counted as hours of stillness — a parcel is not in trouble because it is Friday. Low-volume routes, where the "normal" is computed on too few cases. And stages where no scan exists in your network, which produce structural silence rather than an incident.
The correction method is dull and effective: every morning the person working the list marks the lines that asked for nothing, and once a week those marks are used to tighten the thresholds. Within a month a list becomes usable; without that loop it degrades.
This is also the only place in the subject where human feedback is indispensable. A system that never receives the information "this one was normal" has no way to improve, whatever model sits underneath.
The check: fifty parcels, two columns
Take the last fifty parcels that gave rise to a complaint and fill in two columns: the date of the last event recorded before the complaint, and the date of the complaint itself.
The median gap between them is your indicator, and it is blunt. If it is a few hours, your network learns about its incidents at almost the same time as its customers, and a daily list will gain you little. If it is two or three days, the information was in your system long before the call, and nobody went to look for it.
Add a reading that costs ten minutes: count, among those fifty, how many had produced an explicit failure event and how many were simply silent. The share of silent ones is the population only an absence calculation can detect, and it is the project’s real scope.
That sheet is also what you show a supplier. It replaces a conversation about anomaly detection with a conversation about fifty real complaints, and it makes two proposals comparable.
What we do, and what we refuse
We write the normals per route and per stage with you from your own history, produce the daily list of silences, address it by name with its three states, and wire in the feedback loop that tightens the thresholds. We check first that your events carry the time they happened, because nothing holds without that.
We refuse to write to the final recipient in place of your shipper, and to notify a delay before a decision has been taken. We also refuse to deliver a list with no size cap: beyond what one person clears in thirty minutes, the list stops being useful and the answer is to tighten rather than to produce.
We announce no detection rate. It depends entirely on the density of your scans, and a figure given before seeing your data would describe another network. What we measure in front of you is the gap in section 11, before and after.
What you can do without us is the first query and it costs an hour: open parcels whose last event is more than thirty working hours old. Many networks discover there that their list is ten lines, and that the rest is settled in the round.
Frequently asked questions
Do we have to change our tracking system?
Almost never. The list of silences is computed alongside it, reading the same events, and it does not need to write into your system. Changing tracking tools is a separate project, and doing it to obtain a daily list would be paying very dearly for a query.
Our depots enter statuses at the end of the day. Is that blocking?
It is the main difficulty, and it is organisational. As long as a status carries the entry time rather than the event time, stage durations are wrong and the thresholds with them. The correction is an instruction and some habit, not software.
Can delays be predicted in advance?
Partly, and it is rarely what you need. A prediction with no action is noise; the useful question is what is already in trouble now, which is computed exactly rather than estimated. Start with the present.
Who should receive the list in a small operation?
Whoever can make a parcel move, whatever their title. In a fifteen-person depot it is usually the operations lead; the common mistake is sending it to customer service, who will read it without being able to act.
What about parcels delivered by a last-mile partner?
The silence often starts exactly there, because the partner scans into their own system. It is a point to settle in the contract rather than in the tool: what you do not receive you cannot watch, and a partner refusing to pass on their events leaves you blind on the most sensitive part of the journey.
How long before the list is reliable?
About a month, provided the feedback loop exists. The first weeks produce many false positives; they are corrected by marking the lines that asked for nothing. Without that marking the list stays at its first-day level indefinitely.
Where we come in
When the delay between the last trace and the call runs into days, the information was asleep in your system and nobody fetched it.
- First pass goes on timestamps: while an evening entry stands in for the real hour, every stage duration is fiction.
- Your own history yields each route’s normal, read back with you line by line before it is applied.
- The morning print carries a name, three states, and a volume cap held to what clears before noon.
We will never send an alert to a merchant’s buyer: that conversation belongs to them, and taking it away costs more than a late parcel.
Read next
Logistics: you are graded by somebody who is not your customer
The merchant signs the contract. The recipient, who bought nothing from you, writes the review and refuses the parcel.The round: building a driver’s day, and what happens when an address fails
You are paid per parcel and you spend per attempt. A driver’s whole day is decided in that gap.Training a model: the three cases where it is worth it
Training changes the shape of answers, almost never their content. What you must supply, and the three cases where it is the right tool.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.