Welcome to the 46th newsletter for 2025!
Whether you're new here or a long-time subscriber, I am excited to have you on this journey. With Whserobotics, my mission is simple yet powerful: to enable more robots in the warehouse - responsibly, sustainably, and successfully. Whether you’re exploring automation or building a warehouse robot, I am here to provide the resources and insights you need to make informed decisions. Start exploring today!
A Quick Note: Many of you have been reading these stories for a while. Thank you for that. Over the past few weeks, I’ve been evolving the format to include more frameworks, lessons, and field-tested takeaways. My aim is to make this a newsletter that earns its spot in your inbox every time. I’d love your thoughts on what’s been most valuable so far. Just hit reply to this email, your note comes to me directly.
Robot-Forward Warehousing When Your WMS Is Stuck in 2009
Why integration should be one of the top 3 items in your procurement checklist.
I’ve lost count of how many robotics conversations start the same way.
Throughput. Labor stability. “We need a robotics story for 2026.”
Everyone is energized. The decks look sharp. The vendor list is exciting.
And integration?
It shows up as a single bullet toward the end:
Standard REST API, well-documented.
By the time IT is fully pulled in, a lot of concrete has already dried:
There’s a preferred vendor.
The API docs “look clean.”
A business case is circulating with dates and savings attached.
On slides, that looks coordinated.
In a building that still has to ship every day, it can turn into:
Robots that technically “work,” but don’t see inventory the way operators do.
IT juggling day-to-day support plus a complex new integration.
A business case that never really accounted for integration effort, timeline, or risk.
I’m not anti-robot. If anything, I’m robot-aligned
I’m just saying this clearly:
A polished API PDF does not mean your WMS and IT landscape are ready.
The question I care about is much simpler:
Can we integrate with our systems, by this date, with this team?
If that answer is fuzzy, the project is carrying more risk than the deck admits, whether anyone says it out loud or not.
When IT Joins on Slide 27
Here’s the pattern I keep seeing across different companies and buildings:
Operations wants a more stable, predictable way to hit volume.
Leadership wants a robotics roadmap and a story for the board.
Procurement is pushing on commercials, references, and implementation fees.
Integration gets summarized:
“We’ve got a standard REST API.”
“We’ve integrated with your WMS before.”
“We’ll iron out the details in design.”
Everyone nods. The meeting moves on.
Nobody’s being careless; this is just how these projects have evolved.
Then IT gets pulled in deeper:
“Can you validate their APIs?”
“Can you confirm this will work with what we have?”
“We need effort and timeline estimates, but the target go-live is already out there.”
At that point:
The date is on a roadmap slide.
Savings are already baked into a financial plan.
The conversation shifts from “What do we really need?” to “How do we make this fit inside what’s already promised?”
If integration isn’t one of the top three topics, right next to process design and safety, you’re starting the project in the wrong order.
The Procurement Blind Spot
Most robotics evaluations are strong where you’d expect:
Demos and site visits
Throughput and storage-density comparisons
Safety, risk, and facilities impact
Pricing, terms, references
Where things get softer is in translating “we have an API” into “we know exactly how this will behave in our environment.”
What usually doesn’t happen early enough:
Mapping vendor APIs to your actual WMS events and status codes, not just “we support X, Y, Z WMS.”
Bringing your WMS provider into that discussion:
What do they need to expose or change?
How long will it take?
What will it cost?
Checking all of that against your real IT roadmap and constraints, not the idealized version we wish we had.
Underneath the excitement, a few quiet assumptions creep in:
“Our WMS already publishes what robots need.”
“We’ll clean up exceptions later.”
“IT will figure it out like they always do.”
Those assumptions are where complexity shows up later, especially in brownfield buildings that already run hot and don’t have much patience for “we’re still integrating.”
What Changed for One Client
On one consulting engagement, we walked through this exact gap.
Procurement was doing a lot of things right, strong commercial discipline, tight RFPs, clear safety expectations, but integration was still living in a paragraph on page 37.
After we unpacked what “integration risk” had cost them on previous projects (slipped go-lives, surprise SOWs from the WMS vendor, a tired IT team running on fumes), they made one simple policy change:
No vendor advances to final round without a live 2-hour integration workshop with our WMS team and our lead integration engineer - on site, no slides.
Not a demo. Not another sales pitch.
Two hours of sitting down with the actual WMS and IT folks, whiteboarding:
Real events and status codes
Real exception flows
Real constraints and backlog
That one policy did two things immediately:
Vendors who weren’t serious about integration self-selected out.
The short list was built around who could live with the existing WMS reality, not just who had the shiniest robot.
You don’t have to copy that exact rule.
But you do need your own version of: “Integration has to pass a real-world test before we fall in love with the commercial.”
A Short Integration Playbook (That Doesn’t Need a 40-Page Deck)
If you strip away all the noise, I keep coming back to three moves that separate the painful projects from the boring, stable ones.
You don’t need a perfect architecture. You need to do these three things on purpose.
1) Make Integration a Gate in Procurement
Use procurement to force integration into the conversation early.
That client policy is one example:
No vendor advances to final round without a live 2-hour integration workshop with our WMS team and our lead integration engineer - on site, no slides.
You can tweak the details, but the principle holds:
Integration is not a slide.
Integration is something you watch vendors work through with your actual WMS people in the room.
If a vendor can’t sit with your team and reason through events, statuses, and exceptions for two hours, they probably shouldn’t be in your final round.
2) Run a Lightweight Readiness Check (3 Questions, Not 30)
You don’t need a full-blown maturity model. You need honest answers to three buckets:
Data and states
Can robots see the same inventory truth operators are acting on?
Or are key states still hiding in spreadsheets, tribal knowledge, or overnight batches?
Exceptions and workarounds
Do you actually know how short picks, damages, rush orders, and slot moves are handled today?
Which of those do you expect robots to handle, and which should go straight to humans?
Ownership
Who owns integration on the WMS/IT side?
When something breaks at 2 pm on a Tuesday, who is on point?
If you can’t answer those three buckets clearly, you’re not “behind”, you just haven’t sized the integration work yet.
That’s all the readiness check is: sizing reality before you lock in dates and savings.
I’ve turned this into a simple Excel model that scores each of these buckets and gives you a “Ready now / Ready with adjustments / Needs deeper change” view in one tab. It’s built to be filled out in a single working session with ops + IT.
3) Give Integration Its Own Line in the Business Case
This is the boring-but-critical part.
Integration deserves to show up as:
Its own workstream on the plan
Its own line(s) in the budget
Its own assumptions in the ROI
At minimum, that means:
Internal IT effort (analysis, build, testing, support)
WMS vendor change requests / SOWs
Any middleware / iPaaS work
A realistic view of what happens if integration pushes go-live out by 3–6 months
You’re not trying to make the project look worse.
You’re trying to make the plan match the physics of the building and the team you actually have.
When integration is a gate, a small readiness check, and a visible line in the model, everything else gets easier:
Vendors behave differently.
WMS conversations get real earlier.
Operators don’t get stuck living with a half-integrated science experiment.
One Question You Can Use Tomorrow
If you want a simple way to test where your current project stands, try this:
Where do we explicitly capture integration cost, timeline, and risk in this plan and who has actually looked at it?
If the answer is, “We’ll firm that up later,” that’s your cue:
Add a gate (integration workshop).
Run a lightweight readiness check.
Give integration its own line in the business case.
If you’re already live with robots, use the same question as a quick retrospective for the next building.
If you’d like the lightweight integration readiness Excel model I use with the three buckets and a simple scoring view you can run in one working session reply with “integration model” and I’ll send it over.
News
Thoughts? Questions? Feedback? Reply to this email.