What to Look for at MODEX (If You’re Actually Trying to Improve Execution)
Everything at MODEX looks impressive. Lights flash. Robots glide. Screens animate. Every booth is a controlled environment designed to make technology look perfect. But your operation isn’t a demo. The question isn’t what works there — it’s what works for you.
This piece is a filter. A way to walk the show floor with sharper questions and fewer distractions, so you leave with clarity instead of brochures.
The Demo Problem
A trade show booth is the most forgiving environment a technology will ever operate in. The lighting is perfect. The products are arranged for the demo. The person running it has done the same sequence hundreds of times. The SKUs don’t change. The layout doesn’t change. Nothing unexpected happens.
Your warehouse is the opposite. SKUs rotate weekly. Layouts shift seasonally. New clients onboard with different requirements. The team changes with every shift. The things that make a demo look flawless — stability, predictability, repetition — are exactly the things your operation doesn’t have.
This creates a specific evaluation trap. The technologies that look best in a booth are often the ones that are most tightly optimized for a single, unchanging scenario. The more impressive the demo, the more you should ask: what happens when the conditions change?
A conveyor running at maximum throughput is impressive until you need to handle a product that doesn’t fit the belt. A goods-to-person robot navigating a perfect grid is impressive until the grid needs to be rearranged. An automated storage system cycling through perfectly indexed bins is impressive until you need to add 300 new SKUs next week.
The demo shows peak performance. Your evaluation needs to identify sustained performance — the kind that holds up when the conditions are imperfect, changing, and specific to your operation. Those are different things, and MODEX rewards the former while your P&L depends on the latter.
Three Questions That Cut Through Everything
You can walk the entire show floor and evaluate dozens of vendors, or you can carry three questions and let those questions do the filtering. The second approach is faster, more honest, and will tell you more about whether a system belongs in your operation than any product demo.
How does this adapt?
When the floor changes — new SKUs, new clients, reslotting, seasonal shifts — what happens to the system? Does it absorb the change, or does the change require a project?
How hard is it to change?
Who owns the change? Can the operations team make adjustments, or does every modification require IT, a vendor, or a scheduled downtime window?
Can we test this first?
Can the system be deployed in one zone, with measurable outcomes, before you commit to a full rollout? Or does the business model require a facility-wide commitment upfront?
If a vendor can answer all three clearly and specifically — with examples from real deployments, not hypotheticals — you’re talking to someone who has solved problems similar to yours. If any of the three produces a vague answer, a redirect, or a suggestion to “discuss during a follow-up call,” you’ve learned something important about the gap between the booth and the floor.
If you’ve been thinking through these ideas already — how systems adapt to change, what happens when execution actually improves, how to adopt without disruption — these questions will feel familiar. They’re the same framework, applied to a vendor conversation.
How Does This Adapt?
This is the question most vendors aren’t prepared for, because the demo is designed around stability. Ask it anyway.
Specifically: what happens when a 3PL onboards a new client with 400 SKUs that need to be slotted by Friday? What happens when peak season doubles the order volume and the current layout can’t handle the throughput? What happens when a product goes viral and a C-velocity item becomes an A overnight?
The answers will fall into two categories. Some systems adapt by configuration — the operations team makes changes in software, and the floor reflects those changes immediately or within hours. Other systems adapt by project — a vendor engagement, an installation crew, a downtime window, a retraining cycle.
Configuration-level adaptation means the system was designed for change. It anticipated that the floor would move and built the ability to move with it into the architecture. Project-level adaptation means the system was designed for a specific scenario and requires professional services to move to a different one.
Both can work. But they have radically different cost profiles over time. The first costs you time. The second costs you time, money, and the disruption tax that comes with every vendor-managed change. If you’ve read about why fixed automation struggles in a moving operation, you already understand why this distinction matters.
At MODEX, the signal to look for isn’t the speed of the demo. It’s the speed of the change. Ask the vendor to show you a reconfiguration, not a pick. Ask them to add a new product to the system, change a location assignment, or modify a workflow. With wireless pick-to-light, for example, reconfiguring a location means moving a magnetic device and updating a software assignment — a process that takes minutes, not days. The ease of that process tells you more about what life will be like in month 12 than the throughput number on the spec sheet.
How Hard Is It to Change?
This question is about ownership, not difficulty. Specifically: when the floor needs to change, who makes it happen?
In some systems, the operations team owns the change. A supervisor can reslot a product, add a location, modify a workflow, or reconfigure a zone without calling anyone. The system is designed so that the people closest to the work are the people empowered to improve it.
In other systems, the vendor owns the change. A support ticket is filed, a remote session is scheduled, a technician makes the adjustment, and the team waits. Sometimes it’s hours. Sometimes it’s days. Sometimes the change requires a site visit. Every modification creates a dependency on someone who doesn’t work in the building.
At the booth, this distinction is invisible. Both systems look the same running a pick sequence. The difference shows up six months later, when you need to reslot 50 products because a new client’s SKU mix doesn’t fit the original layout, and the question is whether that takes an afternoon or three weeks.
The question to ask at MODEX: “If my supervisor needs to move a product from location A to location B and update the system, what does that process look like? How long does it take? Does she need credentials, a support call, or a vendor login?”
If the answer is that the supervisor opens a browser, drags a product to a new location, and the devices update in seconds — the system was built for ops. If the answer involves filing a request, waiting for a callback, or scheduling downtime — the system was built for the vendor.
Can We Test This First?
This question separates vendors who are confident in their product from vendors who are confident in their sales process.
A system that works will work in one zone before it works across the floor. A vendor who knows their system works will be comfortable deploying a small, measurable pilot — one zone, one workflow, 30 to 60 days — and letting the results make the case for expansion.
A vendor who needs a facility-wide commitment upfront is telling you something important: the business model depends on the sale happening before the proof. That doesn’t mean the technology is bad. But it means the risk is on your side, not theirs. And in a market with this many options, you shouldn’t have to carry that risk.
At MODEX, the question is straightforward: “Can we deploy this in one zone and measure the results before committing to anything larger?” Listen for specifics. How many devices? How long is the evaluation period? Who defines success? What happens if the results don’t meet expectations?
The best answers will sound like the structure described in Automation That Doesn’t Interrupt Production — a defined zone, baseline metrics, clear success criteria, and a decision point. The answer shouldn’t require a 200-page SOW. It should fit on a napkin.
If a vendor won’t do a pilot, ask why. Sometimes the answer is architectural — the system genuinely requires full-floor installation to function. That’s a legitimate constraint, but it’s also a risk profile you should understand before signing. Sometimes the answer is commercial — the deal size doesn’t justify a small deployment. That’s a misalignment of incentives, and it won’t get better after the contract is signed.
What to Ignore (and Why)
MODEX is designed to overwhelm. That’s not an accident — it’s the format. Thousands of vendors, hundreds of thousands of square feet, three days of information density that no human can fully process. The vendors know this, and the best ones use it. The spectacle is the strategy.
Here’s what you can safely filter out:
A system running 1,200 picks per hour on six identical SKUs in a purpose-built booth tells you nothing about what it will do in your facility with 4,000 SKUs, mixed velocity, and temp labor. Ask for sustained throughput numbers from real deployments.
Some of the most impactful technologies at the show are in 10x10 booths. Some of the largest booths are selling capital equipment with 18-month lead times. Don’t let square footage influence your evaluation.
Every vendor claims this. Very few have production-proven integrations with the specific WMS version you’re running. Ask for the name and phone number of a customer running your WMS. If they can’t provide one, the integration is theoretical.
Real ROI depends on your labor costs, error rates, training cycles, and change frequency. A calculator that produces a payback period from three inputs is selling a narrative, not doing analysis.
Trade show awards are marketing. Customer logos without case studies are marketing. Neither tells you whether the technology works for operations that look like yours.
What you should pay attention to: how the vendor talks about failure. How they describe a deployment that didn’t go as planned. How they handle the question “What’s the hardest part of deploying this?” Honest answers to those questions are worth more than any demo.
What Matters Isn’t What Performs in a Booth
MODEX is three days. Your operation runs 250 shifts a year. The technology you choose will live in your building long after the booth is dismantled and the show floor is empty. The question you’re answering isn’t “what looks best this week?” It’s “what will still be working for us in month 18?”
Month 18 is when the SKU mix has rotated twice. When the team has turned over 40%. When the layout has been rearranged for a new client. When the WMS has been upgraded. When the holiday peak has come and gone and the system either adapted or didn’t.
The systems that hold up in month 18 aren’t always the ones that were most impressive in the booth. They’re the ones that answered the three questions honestly: they adapt without a project, they can be changed by the people who use them, and they can be tested before they’re committed to.
Walk the floor with those questions. Ignore the spectacle. Focus on the substance. Because what matters isn’t what performs in a booth — it’s what performs on your floor.
Ready to See It on Your Floor?
Skip the booth. Start with a conversation about your operation, your challenges, and what better execution actually looks like for your team.