MODE Global's MODE IQ Named Digital Freight Matching Platform of the Year

The Analysis

Every freight desk is a queue, and nearly every argument I have about software starts with someone describing the queue wrong. Loads arrive. Somebody has to find a carrier, agree a price, get it tendered, get it accepted, and then keep it from falling over on the way to delivery. Arrivals, service, waiting. If you want to know whether a tool helped, you need three numbers that most desks do not have written down anywhere: the arrival rate, the service time per load, and the tail of the distribution where everything goes wrong.

Here is what landed on my screen in June 2026. MODE Global's MODE IQ, described as an intelligent transportation management system, was named Digital Freight Matching Platform of the Year at the 2026 SupplyTech Breakthrough Awards. The description that came with it says the platform uses predictive pricing and machine learning to automate carrier matching, quote tendering and routing guide deployment, and that it is meant to reduce non-value-added activity for brokers and carriers by automating load boards and speeding up freight matching across MODE Global's carrier network. That is the whole of what I know about the product from the announcement.

I am not going to tell you to buy it and I am not going to tell you not to. An award is a marketing event with a judging panel behind it, not a service level agreement. What I care about is narrower and harder than that: which decision step does this actually remove, how many minutes does it take off the clock and from what baseline, who absorbs the loss when the model is wrong, how do you build a control group so you can tell the tool apart from a good quarter, and which metric failing means you stop.

Start with the claim, because the claim is where the money is. Automating carrier matching sounds like one thing and is really at least three: remembering who can run the lane, ranking them, and getting an answer out of them. On a manual desk those three are the same phone call. The matcher scrolls a board, remembers that a certain carrier took a similar load out of the same origin three weeks ago, calls, waits, calls again. That sequence has a service time, and service time is what a queue is made of.

Before I ask for any other number I ask for five timestamps: load created, first tender sent, first carrier response, tender accepted, cover confirmed. Five events, four intervals. Publish the median and the 90th percentile of each, per lane. The median tells you how a normal load behaves. The 90th percentile tells you where your customer's patience runs out. If a platform claims it makes matching faster, it has to move one of those four intervals, and it has to move the 90th percentile and not just the median, because the median is where you were already fine.

Then I ask what shape the problem is. A queue runs slow for three reasons and they do not have the same cure. Service can be too slow: every load takes too long to work. Arrivals can be bunched: the work itself is fine, it all lands at once. Or there can be too few servers: there is no carrier in the lane at any price you can charge. Smarter matching helps the first, barely touches the second, and does nothing for the third. I have watched teams buy software for a Monday-morning arrival spike that a shift change would have fixed, and I have watched teams buy matching software for thin lane coverage where the honest answer was to pay more or book earlier. Where is the bottleneck. Answer that before you sign anything.

The phrase about reducing non-value-added activity I actually agree with, but only once it becomes something you can count. On my ledger non-value-added work is three things: re-keying the same load into a second system, chasing a response that should not have needed chasing, and starting the whole tender over after a fall-off. All three are measurable. Minutes per re-key. Number of chases per quote. Fall-off rate. Until those numbers exist, reducing non-value-added activity is an advertising line. After they exist it is an acceptance criterion you can hold someone to.

Now the arithmetic, with every assumption written down as an assumption. Assume a desk handling 400 spot quotes a week. Assume an average of 22 minutes of human touch per quote across matching, tendering and follow-up. Assume 38 percent of quotes get no carrier response within two hours and have to be reworked. Those are my numbers, not anyone's published figures; measure your own and substitute. Four hundred times 22 minutes is 8,800 minutes, which is 146.7 hours, which at a forty-hour week is 3.7 people. If a platform removes sixty percent of that touch time, and sixty percent is a claim to be tested rather than a fact I was handed, you get 88 hours a week back, or 2.2 full-time equivalents.

Assume a loaded cost of 38 dollars an hour. That is 3,344 dollars a week, roughly 174,000 dollars a year. That is the number the platform has to beat, all-in: licence, implementation, integration, the internal hours to keep it running, and the cost of the mistakes it makes while it learns. If the annual all-in cost lands anywhere near 174,000 dollars, you are not buying efficiency, you are renting the same hours back at a markup.

Look at the other side of the ledger too. Assume the desk covers 62 percent of what it tenders today. Assume a covered load contributes 210 dollars of gross margin. Four hundred quotes at 62 percent is 248 covered loads, about 52,080 dollars of margin a week. If automation lifts coverage to 68 percent, again a hypothesis rather than a result, that is 272 loads and 57,120 dollars, a gain of 5,040 dollars a week or roughly 262,000 dollars a year. Set it beside the labour number and you have something like 436,000 dollars a year of theoretical benefit against a price you have not been told. Theoretical, because both legs rest on my assumptions and on a claim nobody has tested on your lanes. Write them into the business case as ranges rather than promises: coverage gain somewhere between two and six points, touch-time reduction somewhere between thirty and sixty percent, and a break-even price computed from the low end of both.

The control group is the part people skip, and it is the only part that produces knowledge. Split by lane, not by customer. Customers are not interchangeable, and mixing them contaminates the result because the good ones go to one group. Hold out thirty percent of lanes, matched on volume and on difficulty, and run them exactly as you run them today for eight weeks. Everything else goes through the platform. Do not move a lane between groups mid-trial. Do not run it in a week you already know is quiet. Eight weeks because one week is noise, and because the sample needs to contain at least one ugly week. If the trial only ever sees easy freight, you have measured the freight, not the tool.

Define the deciding numbers in advance, in writing, before anybody sees a result. Primary metric: minutes from first tender to cover confirmation, treatment versus control, and I want at least a twenty-five percent improvement at the 90th percentile before I call it real. Guardrails: tender acceptance rate must not fall more than three percentage points, fall-off after acceptance must not rise more than two points, cost per covered load must fall at least four percent, and claims plus missed appointments per hundred loads must not rise more than ten percent relative to control. Stop conditions: any two guardrails breached for two consecutive weeks ends the trial and reverts the lanes. One person owns the kill switch, and it is not the person who championed the purchase.

Pricing gets its own paragraph because it is where a wrong answer costs real money. Predictive pricing produces a point estimate whether or not anyone says so, and a point estimate without a spread around it is a guess with a decimal place. Ask what the model's error looks like on lanes like yours, and ask for the answer in a unit you can audit, dollars per load, rather than an accuracy percentage nobody can reproduce. Then decide who eats the error. If the model prices a load eight percent below what that lane has cleared at for thirty days, it may be right, it may be a data artifact, and somebody has to own the difference either way.

My default is blunt: any automated quote more than eight percent below the trailing thirty-day lane median goes to a human before it is tendered. Every override gets logged with a reason code. Review the log weekly. If the override rate is still above fifteen percent after a month, either your lane medians are stale or the model is mis-specified, and in both cases you are paying for automation that you are also doing by hand.

Routing guide deployment is the quiet line item and the one that bites later. Today a human reads the guide and makes exceptions. If the platform deploys the guide, the guide becomes executable configuration, and configuration errors scale at machine speed. One wrong tolerance in a config file will make the same bad decision four hundred times before lunch, where a tired human would have made it twice and noticed on the second one. Version the guide. Log every automated award with the rule that produced it and the inputs it used. Keep a diff you can still read six months later, when a customer asks why a load went to a carrier nobody recognises. If the platform cannot give you that log in a format you can query, you are not buying a system, you are buying a recommendation you are not able to audit.

Which brings me to measurement independence. I do not accept the vendor dashboard as the trial result. I have no reason to think anybody is lying; I have every reason to think a dashboard built to show a product in a good light will show it in a good light. Ask for raw event export, weekly, flat file, with the same five timestamps I opened with. Put it in your own warehouse and compute the metrics yourself. If the vendor will not release row-level events, that refusal is itself a finding, and it is a finding that ends the conversation.

Two things get missed in these evaluations and both of them cap what you can get. Machine learning eats your own history. If your logs are missing timestamps, missing decline reasons, missing fall-off reasons, the ceiling on what any model can learn is set right there and no vendor changes it. Backfilling those fields is unglamorous and it determines the height of every number that follows. Second, matching is a two-sided market. Half of whether a platform performs is whether your carriers will respond on it. If your core carriers still only answer the phone, the network effect belongs to somebody else. Before a pilot, count how many of your usual carriers will actually respond inside the platform; below a certain share, do not talk about algorithms yet.

Where does the award fit in all of this? It tells you a panel of judges thought well of a product in 2026. It does not tell you the platform fits your lanes, your carriers, your data quality or your people. Awards are cheap information and I weight them accordingly. I am also not going to name competitors or hand you a shortlist, because that turns this column into a procurement document and it is not one. The test I have described works on anything that touches matching, tendering or pricing, including the spreadsheet and the phone calls you are running today.

So, the calendar. This week, ahead of everything else, the operations lead exports ninety days of tender events and publishes the four intervals per lane. If that export cannot be produced by Friday 10 July 2026, the trial does not start, because without a baseline there is no result. In the week of 13 July, operations and IT agree the lane split, write the guardrails down, and name whoever holds the kill switch; procurement prices the thing all-in including internal hours and writes the break-even number next to it. From the week of 20 July through the week of 14 September, run the eight weeks with a metric review every Monday morning. In the week of 21 September, decide against the thresholds you wrote in July, not against how anybody feels in September. If it passes, expand by twenty percent of lanes per month and re-measure each month. If it fails, revert the lanes and keep the baseline, because the baseline is worth more than the demo ever was.

Alternatives belong on the table too, because automation is not the only lever. If arrivals are bunched, change the arrivals: ask your largest shippers to tender by 15:00 the day before and measure how much of the Monday spike that removes. If coverage is thin, lengthen the response window and pay for it, because a two-hour window that gets forty percent response can easily be worse than a six-hour window that gets eighty. If the constraint is a handful of hard lanes, automate only those and leave the rest alone, since a narrow deployment is easier to measure and far easier to undo. And if the real problem is that your best matcher is thinking about leaving, no platform fixes that and you should be spending the money on that person instead.

The traps are mostly about measurement. Activity metrics first: tenders sent, calls made, emails answered. All of them go up the moment a system automates something and none of them mean anything. Outcome metrics only, minutes to cover, coverage rate, cost per covered load, fall-off rate, claims per hundred loads. Seasonal confound next: a trial that runs into a peak will look worse and one that runs out of a peak will look better, and neither reading is about the tool. Mix: never blend spot and contracted freight into one coverage figure. Timing of the trial period: a free trial that expires right before your peak means you decide under time pressure, which is exactly when people sign things they should not. And the largest one, measuring with the vendor's instrument while the vendor's contract is still being negotiated.

I will close where I opened, with the queue. Add servers, shorten service, or smooth arrivals. Software can shorten service, and sometimes service is the constraint and the money is genuinely there. It cannot add servers where none exist, and it will not smooth arrivals unless somebody changes how work comes in the door. Measure the four intervals before you buy anything, hold the trial to thresholds written before you saw a single result, and put the kill switch with somebody who has no stake in being proved right. That is not cynicism about vendors. It is the only way I know to find out whether the queue actually got shorter.

One more thing about plumbing, because this is where pilots quietly fail. Your transportation management system is the system of record, and whatever sits on top of it has to write back inside a delay you have measured rather than assumed. If the platform's view of a load runs ninety seconds behind your system's view, a person and a machine will both act on the same load and you will generate double tenders, which carriers hate and which will cost you more in goodwill than the automation saved. Ask for the synchronisation interval in writing, measure it during the pilot, and set the guardrail at whatever your tolerance is. Mine is simple: no automated action may fire on a load whose record is more than sixty seconds old.

The people question deserves a straight answer as well. Automation here removes the lookup, not the relationship. Your carriers take your calls because a person has been fair with them on the bad days, when the load was heavier than the paperwork said and the receiver kept them waiting four hours. If a platform intermediates every interaction, that relationship has nowhere to live, and you discover the loss the week capacity tightens and nobody returns your tender. Keep a human on your top twenty carriers by volume whatever the automation does with the rest. That is not sentiment, it is redundancy: when the system is down or wrong you still need a channel that works.

Then the tail, which is the part I actually lie awake about. Every desk has loads that never cover. They sit, they get re-tendered, they go to a spot board at a loss, or they end in a phone call admitting failure. Measure that population separately: count per week, age at the moment you abandon them, and the average loss on the ones that did cover late. In my experience this is where the money is, not in the median. A tool that moves the median by ten percent and leaves the abandonment tail where it was has made your easy freight easier and done nothing about the expensive problem. So I set a separate threshold for it: the weekly count of loads abandoned after six hours has to fall by at least a third, and the average loss on late-covered loads has to fall by at least fifteen percent. If those do not move, I am not interested in what happened to the median.

And somebody has to own it after go-live, because nobody writes that down. The model needs an owner the way a forklift has an operator: a named person, a named backup, a weekly check, and a written definition of what broken looks like. If matching quality drifts because your carrier mix changed or your lane mix moved, nothing inside the software will tell you. The only thing that tells you is your own weekly report on those four intervals, run forever and not just during the trial. Build that report once and keep it after the purchase, because it is the only instrument that outlives whoever sold you the system.

↑ Back to the key points

— By Ravi Chandran