Supply Chain Action Points
Read this first — the conclusion, and the moves to make:
- Pull your last 60 days of quote logs and tally arrival rate, median turnaround, and the size of the exception tail before any vendor conversation, within two weeks.
- Set a service target of under two hours on routine quotes and a hard cap of one business day on the exception tail, with a named owner on every exception.
- Run a 30-day pilot on the tracking exception queue only, watching exception close time per shipment as the single metric that decides go or no-go.
- Treat a manual quote-prep load above 20 hours a month as the tripwire to buy automation; below that, spend the same weeks fixing the upstream feed gap instead.
- Map the preferential regimes that actually fire on your lanes and ignore vendor coverage counts beyond your own low double digits.
At its 2026 Innovation Forum in Chicago on 6-8 October, Descartes put metrics on its logistics AI. MacroPoint OpsForce, which chases drivers and restores dropped tracking, has delivered a 30% average gain in no-touch tracking automation and 1.5x tracking-team productivity. Fleet Data Intelligence lifted route density by up to 30% in early deployments, and Fleet Safety draws on more than 40 billion miles of telemetry and 500,000 accident records. Free Trade Intelligence covers over 250 preferential tariff regimes.
The Analysis
At Descartes' Innovation Forum in Chicago this week, 6-8 October, the logistics-software vendor did something vendors rarely do: it put numbers on its AI instead of adjectives. Free Trade Intelligence now covers more than 250 preferential tariff regimes. Its quoting tool returns 90% of quotes in under thirty seconds. MacroPoint OpsForce, the module that chases drivers and stitches back dropped tracking pings, is showing a 30% average lift in no-touch automation and 1.5x productivity for the tracking team. Fleet Data Intelligence is pushing route density up by as much as 30% in early deployments, and Fleet Safety is chewing on 40 billion miles of telemetry and 500,000 accident records.
I read that list the way an engineer reads a spec sheet, not the way a trade magazine reads a press release. The numbers are real in the sense that Descartes measured them, but they are the vendor's own measurements, taken at its own event, on deployments it picked. That distinction is the whole ballgame for anyone deciding whether to spend money on this stuff. Think of it as a queue: the vendor is telling you the service rate at the front of the line, and quietly saying nothing about the back of the line where the hard jobs wait.
This piece does not endorse the vendor and does not recap the news. I take each claimed metric, drop it back into a stretch of the actual workflow, find the one variable that moves the whole system when it budges, and then hand you a set of thresholds for whether to buy. Measure first, optimize later. That is the only sentence from this week's news that should change what you do on the floor.
Begin by modeling the quotation workflow as a queue, because that is literally what it is. Quote requests show up at some arrival rate, and each one sits in a line until an analyst can service it and push an answer back to the customer. Descartes is claiming that for 90% of those arrivals, service time fell under thirty seconds. The tempting part of that sentence is the 90%. The useful part is the other 10%. A queue never hurts at its average; it hurts at its tail. The hard origin determinations, the shipment whose bill of materials crosses three trade agreements, the buyer who wants a landed-cost figure before the sales call ends - those are the jobs that wait, and they wait precisely because the easy 90% got automated away while the remaining 10% still needs a person who is now also doing the other 90%'s overflow. Where is the bottleneck? In the exception class, not the routine class.
A queue has exactly three numbers that explain everything, and they are locked together. Arrival rate is how fast jobs walk in. Wait time is how long each one sits. Work-in-process is how many are in the system at once. Little's Law says those three multiply into each other: the count in the system equals arrival rate times wait time. So if you cut service time with automation but arrival keeps climbing, the count in the system does not fall - the line just moves faster while staying just as long. That is why a 30% automation gain can feel like nothing in a year your shipment volume also grew 30%. The variable you actually control is arrival, not service, and arrival is a commercial decision, not a software one. This is the first thing I would tell any importer staring at this press release: stop reading the average, go find the tail, and then ask whether the tail is even yours to automate.
Next, take the 250-plus preferential tariff regimes and shrink them before you admire them. That figure is a funnel, not a trophy. At the wide mouth sits every trade agreement Descartes chose to encode. At the narrow spout sits the handful - for most mid-size importers, low double digits - that actually sit between your suppliers and your customers. A Shenzhen-to-Rotterdam electronics forwarder needs a different slice of those 250 than a Latin-American frozen-food importer bringing product into the US Gulf. Coverage breadth is a sales slide; coverage relevance is an operations number, and they are not the same variable.
Measure first, optimize later: before the 250 impresses you, count how many of those regimes fire on your own lanes in a normal quarter. My experience says the answer is small, and that smallness is the point. A tool that covers 250 regimes you never touch is a tool covering zero regimes you care about. The vendor will never volunteer which slice is yours, because naming the slice shrinks the headline. The 250 is a count of possibility; what you run is a count of reality, and the two should never be confused when a procurement committee reads the deck.
Then look at the tracking claim, because this is where the queue metaphor earns its keep. MacroPoint OpsForce automates the chore of chasing a driver when a location ping drops and stitching the track back together. A 30% lift in no-touch automation means three in ten exception events that used to need a human now close by themselves. A 1.5x productivity figure means the team handling the leftovers does the same work in about two-thirds of the time. That reads as a win until you ask the causal question the press release skips: why did those exceptions exist in the first place?
A dropped ping is a symptom of a carrier telemetry gap or a dead device battery, not of human slowness. Automating the chase treats the fever, not the infection. The bottleneck variable is the exception arrival rate, and if that rate is climbing because your carrier mix is getting noisier, then 30% automation buys you a buffer, not a cure. All told, you are putting a faster pump on a queue that is still being filled from upstream.
Another number worth a second pass is the route density gain of up to 30% from Fleet Data Intelligence. Read that as a loading funnel: more shipments packed onto the same lane before you send a truck, which lifts the utilization of each vehicle. The ceiling on that gain is physical, not algorithmic - you can only densify a lane until the boxes stop fitting or the delivery windows stop allowing it. The 30% is an 'up to,' which in vendor language means the best customer in the best lane, not the median. For an importer, the leverage here is in the dispatch decision, not the AI: if your lanes are already running near full, densification has nowhere to go, and the tool's number is noise.
If your lanes are half empty because no one ever looked, then yes, a density model helps - but a spreadsheet and a curious dispatcher would have found most of that too. The algorithm is a magnifier, not a source. A magnifier makes what is already there easier to see; it does not put anything new on the table, and a team that cannot read its own lanes will only see the same empty lanes, just faster.
Turn to Fleet Safety, the module built on 40 billion miles of telemetry and 500,000 accident records. Model a fleet's risk as a queue of near-misses waiting to become claims. The training data is enormous, which is genuinely useful for a large carrier whose driving patterns resemble the fleet that produced it. For a small operator running ten trucks on city routes, that 40-billion-mile model is a funnel whose narrow end may barely overlap your world - the relevance gap is the bottleneck, not the data size. A model is only as good as the distance between its training distribution and your actual one, and no press release prints that distance. Coverage and confidence are different axes, and the second is the one your insurance premium actually responds to.
The impact lands unevenly, and that unevenness is exactly what the headline glosses over. A large forwarder pushing thousands of quotes a week feels the thirty-second number as real capacity: its arrival rate is high enough that shaving service time off the routine 90% frees whole analyst shifts. A small importer issuing forty quotes a month feels almost nothing, because its queue is short and rarely backs up - the average already clears fast, so automating the average changes nothing anyone noticed. The winners are the mid-size shops stuck in the messy middle: enough volume that exceptions pile up, not enough scale that they already run a control tower. Grace Yang, our sourcing editor, would land the same point from the buyer's chair - the saving only shows up if the buyer's own demand signal is noisy enough to throw off exceptions worth automating.
The 10% tail is where the money sits, and it is the one part no keynote leads with. The vendor's one-size number fits the big player best and fits the small player not at all, which is the quiet reason the headline leads with the average instead of the spread. The median customer the vendor shows on stage is not the median customer sitting in your room, and the gap between those two medians is exactly where expensive buying mistakes are born.
On timing, these are not promises about the future. The modules are live, and the percentages describe deployments that already happened inside 2026, so the clock for an adopter is the integration clock, not the invention clock. Budget six to ten weeks from signature to a dashboard you actually trust, and longer if your data is scattered across two or three TMS instances plus a spreadsheet nobody owns. For everyone who sits it out, the effect arrives as slow competitive pressure over the next one to two quarters - a rival quoting faster and quietly taking the shipment you would have caught. That is a squeeze, not a cliff, which is its own danger: a squeeze is easy to ignore until the quarter is gone, and by then the share you lost does not come back just because you finally bought the tool.
Here is the part the trade press did not print, and it is the part I would put on a slide in red. Descartes' figures are self-reported, at its own forum, on deployments it selected, with no independent baseline published next to them. The 30% and the 1.5x have no audited 'before' pinned beside them. More to the point, those percentages describe the vendor's measured gain on someone else's operation - never on yours. The genuinely useful move for an importer or exporter is not to cheer 250 regimes or thirty seconds; it is to build the measurement the vendor skipped.
Stand up a single page that counts your own quote queue: arrival rate, median service time, the size of the exception tail, and the regimes that actually fire on your lanes. Do that first. The buy decision gets easy the moment you can see your own arrival rate and service rate. The media sells you the vendor's dashboard; the job is to build your own and stop reading someone else's. A dashboard you do not own is a story someone else wrote about your business, and you would be surprised how often that story quietly lands in the vendor's favor.
The second half of the missed point is about the tail itself. Every one of these metrics is an average with a silent tail behind it. Ninety percent under thirty seconds means ten percent take longer - and the ten percent are the messy, multi-regime, multi-origin jobs that eat your senior people. Fleet Safety's 40 billion miles and 500,000 accident records sound like proof, but they are a training set, not a service-level guarantee; the model's value shows up only where your own driving patterns resemble the fleet it learned from. Coverage and confidence are different axes, and the press release prints the first and hides the second. The number that should travel with every one of these claims is the size of the tail and the width of the confidence band, and neither appeared in Chicago.
The counterfactual keeps the whole thing honest. Flip one variable and the recommendation reverses. If your exception arrival rate is low - under 5% of shipments, say - then a 30% automation gain saves you almost nothing, because there was barely anything to automate, and the integration bill (six to ten weeks of your team, a connector build, a data-cleanup project) dwarfs the saving. If the 30% figure is optimistic by half once it meets your lanes, the payback stretches past a year and the business case falls over. The condition that flips the conclusion is your baseline density: high and noisy, buy the tool; low and clean, stay manual and spend those same weeks fixing the upstream feed gap instead. That boundary is the real deliverable, and no vendor keynote will draw it for you, because drawing it tells half the room they do not need the product. Measure first, optimize later is not a slogan here; it is the only way the numbers mean anything.
Let me put actual numbers on it the way Descartes should have put numbers on itself. Assume a mid-size importer running 800 quote requests a month, of which 30% - that is 240 - require a preferential-origin check spanning more than one regime. Assume a manual analyst spends 15 minutes on each such check. That is 240 times 15, or 3,600 minutes, which is 60 analyst-hours every month, spent only on origin. Now drop the tool in at its claimed 90% under-thirty-seconds rate. The 90% - 216 quotes - come back on their own, leaving 24 that still need a human at 15 minutes each: 360 minutes, or 6 hours.
Net analyst time on that task falls from 60 hours to 6, roughly a 90% cut. But read the threshold, not the headline: this math only holds because the arrival rate, 240 complex quotes a month, is high. Set a tripwire - if your manual quote-prep runs past 20 hours a month, the automation pays for itself; below that, the connector build costs more than the saving. The 90% headline is not your saving; your own arrival rate is.
Run the same arithmetic on the tracking side so the threshold is not hand-wavy. Assume 1,200 active shipments a month with an exception rate of 8%, which is 96 dropped-ping events that each need a human chase at 25 minutes: 2,400 minutes, or 40 hours a month of pure exception handling. A 30% no-touch gain takes that to 28 hours saved - about 12 hours back in the month. Now set the tripwire the other way: if your exception rate sits below 5%, those 12 hours are not worth a six-week integration; if it is above 8% and climbing, the 12 hours are the floor, not the ceiling, because volume is what feeds the queue. The single number that should gate the pilot is the exception rate itself, measured for sixty days before you sign anything. A tool is a pump; you only buy the pump after you have measured how fast the line is filling.
So where do you point this on Monday morning? Build the baseline before anything else. Pull the last sixty days of quote logs and tally arrival rate, median turnaround, and the size of the exception tail. Set a service target of under two hours on the routine 90% and a hard cap on the tail - no job older than one business day, no exceptions left unowned. Then, only then, run a thirty-day pilot on the tracking exception queue, not the whole platform, because the tail is where the leverage lives. Watch exactly one metric: exception close time per shipment. If it drops by a third and your team's overtime drops with it, expand to the next queue. If it does not move, the bottleneck was upstream of the tool, and you just bought a faster buffer for a line that should not have been that long in the first place.
Think of the whole decision as a queue you are already standing in. The vendor is offering to speed up the front. Your job is to measure the line, find which segment is actually backed up, and only then decide whether the speed-up lands where your backup is. Measure first, optimize later - that is the only part of this week's news that should change what you do on the floor.
↑ Back to the key points