
Disruptive Minds · 2025-05-08 · 39 min
Key moments - from our scoring
Substance score
51 / 100
Five dimensions, 20 points each
Casey Winans, founder of Fullstride and a 20-year veteran of the WMS space (including roles at Blue Yonder and consulting firms), explains why most fulfillment providers and 3PLs struggle with WMS implementations. The core problem isn't the software itself - it's that organizations lack the foundational readiness: documented processes, data clarity, cross-functional alignment, and understanding of downstream impacts on customers and employees. Winans describes his "clarity first" consulting model, which focuses on three areas before touching any vendor: ensuring the business is actually ready to buy (not just pursuing technology out of urgency), identifying gaps in foundational work like process documentation and team alignment, and understanding the total cost and timeline of ownership. He critiques the all-or-nothing approach most companies take - choosing either spreadsheets or massive enterprise systems like SAP or Blue Yonder, when mid-market solutions exist. Key issues include lack of data to support fancy features, poor change management, inadequate employee training, and failure to communicate downstream impacts to customers. Winans emphasizes the importance of crawl-walk-run implementation, starting with barcode scanning and putaway logic rather than jumping to automation and robotics, and treating WMS deployment as continuous improvement rather than a one-time implementation.
The biggest mistakes are implementing a WMS before the organization has foundational readiness - documented processes, clean data, cross-functional alignment, and clear business goals. Companies also often choose systems that are too large or too small for their needs, fail to manage change with employees and customers, and pursue fancy features without the data infrastructure to support them.
You're ready if you have documented and agreed-upon processes across teams, clean data to feed into the system, cross-functional alignment on business goals and success metrics, and honest clarity about your current pain points and future growth trajectory. If you're not ready, a 90-day action plan focusing on process clarity and team alignment can prepare you.
No. These mega-vendor systems like SAP and Blue Yonder are designed for large enterprises with teams of people in specialized roles, not growing businesses where employees wear multiple hats. Implementing them at an early stage creates friction, slows operations, and often fails - mid-market WMS solutions are better suited for scaling businesses.
Putaway logic defines rules for how and where inventory is stored after receiving based on product characteristics, order profiles, and downstream needs. Strong putaway logic streamlines picking, packing, and sorting operations because it ensures orders naturally organize themselves through the warehouse - reducing complexity and enabling even new employees to work efficiently.
Customers and employees often aren't informed why the change is happening or how it affects them. Resistance decreases when you involve all stakeholders (leadership to front-line workers), communicate the business rationale transparently, provide thorough training, and explain how they contribute to success - especially when new processes temporarily make their jobs harder but deliver greater efficiency downstream.
Our reviewer’s read on each dimension, with quotes from the episode.
There are a handful of genuinely useful ideas (put-away logic as a sophistication proxy, WMS amplifying rather than fixing pain, the 'demo doom loop') but they're surrounded by substantial meandering, clichéd phrasing, and long biographical throat-clearing. The insight-per-minute rate is low for a 39-minute episode.
typically that's not true. What it'll do is it'll amplify some of your pain because you don't have the right foundational pieces in the mix yet
those decision points only live in people's heads. So there's nothing in any given system anywhere or any kind of hard data where they can put in a system
A couple of genuinely fresh framings ('demo doom loop', put-away logic as a vendor-maturity proxy, 'clarity first' as a pre-sales discipline) stand out, but the bulk of the conversation relies on familiar consulting clichés - 'crawl walk run', 'eating an elephant', change management platitudes - that circulate widely in ops circles.
what one I call is a demo doom loop
It can't lead. It supports. I think it's a big misnomer out there.
Casey Winans has genuine, multi-sided practitioner depth: 20+ years in WMS, tier-1 vendor experience at Red Prairie/Blue Yonder, 3PL operator exposure, and scaled a consulting firm to 60+ people and eight figures before pivoting to independent advisory. This is real practitioner experience, not a career conference speaker.
I grew that to 60 plus people, you know, eight figures in revenue
Started out working for some small, small companies building software internally that moved into working for a company called Redferry, that's now Blue Yonder
Named vendors (SAP, Blue Yonder/JDA/Red Prairie, Skubana) and one concrete anecdote with real numbers (packer throughput drop from 40 to 25 orders/hour) add some grounding, but most case examples are anonymous, no ROI figures or implementation cost data are provided, and the SAP failure story stays entirely vague.
she was doing like 35, 40 orders an hour by herself...that packing went from 40 bucks an hour to more like 25
This was a company that was, uh, growing pretty rapidly. They wanted to double in size quickly. They had a year before they had tried to implement SAP and they failed.
The host is engaged and surfaces decent topics (downstream effects on customers and employees, the three-factor question) but talks at least as much as the guest, often finishing the guest's point for him or pivoting to his own anecdotes rather than probing deeper. There is essentially no pushback or challenge to any claim made.
So if there were three factors you would consider most of all when looking at a 3, when looking at a WMS, what would they be?
I thought it was really interesting that we came in for a 40 minute discussion about systems and technology and what we actually ended up talking about was people, business practices, quality of data
Computed from the transcript - who did the talking, and the words that came up most.
On this episode of Disruptive Minds , host Bill Carlin sits down with Casey Winans, founder of Fullstride, to explore the real technology needs of modern fulfillment operations. With over 20 years of experience in warehouse management systems (WMS), logistics consulting, and software implementation, Casey brings a brutally honest look at what it really takes to choose, implement, and scale warehouse technology. “The system can't lead - it supports. If your people and processes aren't ready, the tech will only amplify your problems.” Whether you're a 3PL, a growing e-commerce seller, or an ops leader trying to modernize your warehouse, this conversation dives deep into the operational blind spots most teams miss - like aligning your staff, documenting your real workflows, and avoiding flashy tech that doesn’t fit your business.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Hey guys, welcome back to another episode of Disruptive Minds. Today I'm with Casey Winans M. And we're going to be talking about the technology you need to run your fulfillment operations. So whether you're an E commerce seller, whether you're a fulfillment company at 3PL, we're going to be talking about like the technology that you use and how that's going to scale with you and your business. You are listening to the Disruptive Minds podcast, home of the entrepreneur. Hey Casey, thanks for joining us.
Speaker B: Hey Bill, thanks for having me on.
Speaker A: Yeah. So could you give the listeners a little bit about your background? I know you've been dealing with technology for a while now.
Speaker B: Yeah, I've been in, uh, what you call like the warehouse management system space for over 20 years. Started out working for some small, small companies building software internally that moved into working for a company called Redferry, that's now Blue Yonder. Did that, uh, for several years. I, I think massive implementations for massive customers. Lots of complexity. I moved on from there to working for a 3 PL out of Canada. So, uh, that was on the other side of the fence. I was still doing software implementations, but I was outside the software ecosystem or outside the vendor ecosystem to the extent. So I didn't necessarily have to take the jabs to the face based on defects or design decisions. I did that for a year and a half and then there was this perfect time timing piece for me anyways, maybe not the vendors, but Redferry and JDA merged before they became Blue Yonder. And the messaging was we don't do customizations. And in the, the tier one space, the big boys out there, customization is the name of the game. It's massively, uh, tweaked and there's, there's big, big budgets on the line. So lots of, lots of folks were upset. Perfect time for myself and two partners to hang a shingle out there and start a consulting firm. Uh, thought we were going to be mercenaries for a few months until they figured out their messaging issues and then squashed us. But they, they turned out to, they embraced the partner ecosystem that was building up. So we became partners. I did that for somewhere around five years or so. I grew that to 60 plus people, you know, eight figures in revenue. And it was, it was a big, uh, lesson in terms of what to do, what not to do. And I made a million mistakes along the way. Some of my partners, you know, we just grew and we were lucky enough to keep outgrowing those, those issues. But I see them I reference them all the time now. I moved on from there, sold my stake and then Covid hit non compete class, keeping me out of it for a couple years. And then I took a job working for a bigger consulting firm in that same space. So one of the things I got to do there was get into advisory work which is talking about the need for systems up front, figuring out if there's business cases there, what are the other options. Because a lot of, a lot of the folks I worked with back then, big companies even, even like the, the mid market ones, they liked the name recognition these really big brand, these big vendors had but they were just, it was just too much. It's one of those things where they would, they would, they were trying to eat an elephant right all at once and it's just too much system for them and they would have issues. So it was a way of walking folks back and finding other solutions for them that made more sense at that point in time. And then just, just in general, just getting to talk about people on the business side of things versus just technology and software that really opened my eyes. I've worked with some mid tier vendors that wanted to have partnerships but they just, they couldn't figure out how to get them with the uh, big consulting firms. So that was effectively why I started Fullstride. I moved on from that consulting firm, started Fullstride, my first business model and that was I'm going to work with Tier 2 vendors, permit and mid sized customers and I'm going to connect the dots there on purpose. I'm not going to outgrow them. The advice and the work we're going to do is going to be right sized so it makes sense for them and it didn't, it didn't really exist. The reason I did that is because I saw this big gap and I'm like, this is frustrating. I like working with mid sized businesses. The mid tier vendors out there, they wanted some more, some ability to get in front of people to help, you know, sell their software but also help businesses grow. And I did that for about a year and a half through full stride. And one of the things that I saw over and over again was I was stuck in the middle. I would be helping people implement the software. But a lot of these vendors, no fault they're on necessarily, just the nature of the game is they just didn't have the, the back office to really in a structured way to help those, those, those uh, customers implement. And the other half of that really was these customers just didn't have. They weren't ready to buy. I guess that's probably how I can sum it up. They weren't ready to buy. No one was really talking about all the things you need to do before you actually start talking to a vendor. That's business maturity stuff, especially when it's your first system. So at the end of 2023, beginning of 24, I cut ties with vendors and I went fully on my own. The business model sense where we're independent, no tie ups. And uh, what we do now is what I call clarity first. And that's all we really do. And that's effectively talking about do you really to buy a system at this point? What are some of the business schools you have out there? What are your current systems? Whether I use quotes a lot because it might be a bunch of different software cobbled together, or you're doing manual data entry or you have spreadsheets galore. What's that look like? Can we do something now to get you some more mileage? But also when should you invest? What does that look like timing wise? And I try not to let it get to the point where urgency is driving the bus because that's when you cut corners. So that's one of the, one of the questions we answer. But there's another one, there's a couple more. The other one is where am I not ready? And that, that's a question I don't see enough folks actually ask before they start jumping towards, towards technology in general. Right. There's this misnomer out there that I'm having. I'm having some growing challenges here and I think warehouse management systems will, will fix it, but typically that's not true. What it'll do is it'll amplify some of your pain because you don't have the right foundational pieces in the mix yet. So I do a lot of focus, I focus a lot on there and I usually what I do is I come up with a 90 day action plan in terms of what do we need to do to get the business ready so you can have productive conversations with a vendor. And a lot of that work really comes down to my team's aligned. Where's that functional, that up there, that, that no one's really addressing like they work around it. Let's get that aired. Let's figure that out. Let's talk to people, figure out where they're helping, where they're hindering. And that's an awesome place to start putting in some guardrails so everyone kind of knows how other they contribute to success or some of the other frustrations they're having. And then we get into process, clarity, what I call it. Do you have your, your, your processes documented? Are they buttoned up, where everyone's agreeing to them, not just on paper, but actually living them out every day? Other SOPs. And then in the system world, a lot of folks get tied up with the fancy features. When they get in there and they've bought and they start to implement, they realize they don't necessarily have the data to drive that. So what they do is they end up settling for some subset of what they thought they were getting. And that's usually where ROI kind of goes to die. No one wants to talk about it anymore because it didn't exist in the end of it. Right? So. Or they'll pause because they realize just the stuff's not there. So we work through all those pieces to explain to them. If you want to get people out of the middle and everyone operating at a very high level, we need to understand those decisions they're making and allow the software to take that. Um, so those are conversations we have that don't typically happen if you go straight to a vendor, there's a lot of assumptions that get to live rent free. And then there's a lot of education around. What do you want from a vendor relationship? What, what does the total cost look like over the next five, ten years? Just getting everyone prepared so we can take a step back and say, here's all this information. You guys are equipped to do it yourself. But if you want us to, we could come alongside you and work with you to get this, this through and talk to the vendor with you and on your behalf. Because we speak business and we speak the vendor, the vendor language, right? To kind of connect all the dots there. That's, that's really what I started focusing on, um, about a year and a half ago. And that's. It's been awesome. It's a great journey. I've been learning a lot. But it's also. It was just a huge part of the market that was underserved. And a lot of it is an uphill battle in terms of getting folks to really think about the pursuit that way versus just going towards technology and having, know, getting stuck on a struggle bus effectively.
Speaker A: Yeah, yeah. So one of the things that I, you know, really pick up on when you're talking about systems and you're talking about any kind of technology, uh, especially in like, the warehousing space, is that in a lot of ways this is similar to, like buying a car, right? So when you go out, you buy a car, you might buy 1, 2, 3 cars in your entire lifetime, right? There's very few people that are at the dealership every year on the dot, right. It's this, like, infrequent purchase where you don't do a whole of comparison shopping. You don't go through the process every day. But the person selling you that car does, right? The person selling you that wms, he's had eight calls today to sell that wms, and he's adept at it. So what happens is there's an asymmetry of information at play when you're making this purchasing decision. And what it sounds like to me, Casey, is that, uh, one of the things you do is you help to take away some of this asymmetry and, and level that playing field. Because, you know, you may have gone the bat a hundred times when, you know, a individual e commerce merchant or fulfillment provider may have gone to bat once, twice, three times if they're lucky.
Speaker B: Yeah, that's a great way to put it. And that's very true asymmetry of information. And that's a big part of it right there. Uh, just to kind of harp on that same problem is most of the folks in there, they either haven't done it or they might have had one at that. Maybe at a different business, maybe even a completely different industry. So the, the experience doesn't necessarily translate well, or there's just, uh, a lot of room for degradation, uh, degradation on terms of how you went through or what you went through the first time. So that's where you're kind of at a loss. And the vendors there, they do this every day. It goes beyond the sales folks. It goes into implementation. It's the, um, cursive information there too. They're too close to it, so they can't necessarily relate. Or what I've seen a lot of times on the vendor side is they know the software. They don't necessarily know how the software is used operationally.
Speaker A: Right.
Speaker B: They haven't worked in fulfillment center. They haven't worked for a 3 PL. That part of it is beyond them. They know how the software works, and bridging that gap is a hard one to do. And if you don't have someone there advocating on your behalf, that's where a lot of stuff gets missed. Right. And then you get to go live and things just don't line up or you're making compromises. And that hurts adoption massively. At that point too.
Speaker A: Yeah, that's one of the big things that I see is you kind of alluded to it in the beginning. There is the idea of eating an elephant. Right. It seems like companies are kind of either all in or all out. Right. They're either on the spreadsheet or they're sitting there looking at some hundred million, $200million, you know, behemoth of a technology provider. Right. And thinking about implementing that into their small business. Right. So it seems like everybody always wants the cream of the crop or they're running a spreadsheet and there's all these intermediate steps because you have to have something that not just works, but it works for you. And you kind of alluded to this, right? The way the thing's supposed to work based on how it was built and the way it's supposed to be used versus how it's used in practice are sometimes very different. And a lot of times that relies on the know how, uh, of the operator, the clarity of the data. Right. All these different things. So the question is, you know, what bells and whistles do you need? And which bells and whistles are, you know, nice to haves or even things that might over complicate what you're doing?
Speaker B: Right. I have that conversation quite often. I can give you an example of one. I, the company I interacted with last summer and, you know, we did not see eye to eye. So this kind of gives you an idea of what's out there and where folks come at with misconceptions. This was a company that was, uh, growing pretty rapidly. They wanted to double in size quickly. They had a year before they had tried to implement SAP and they failed. SAP is a big erp, but it's massive, right? It's their first. But one of the things I like to tell po tell folks anyways, is when you get into like those, those mega vendors, the software is designed for teams of people doing individual functions where somebody wears a hat or a fraction of a hat, and then they do the role where if you're at a smaller business, you have one person potentially wearing many hats. So when you get into a piece of software like that, you're taking one off, putting one on back and forth, and it slows down your whole process because everything's so granular and rigid that way. So that'll eat you alive. So that's what they went through with with an S P and it failed miserably. They backed off. A year later they came in to me talking to me about pursuing warehouse management Systems. And first thing out of their mouth was, well, why wouldn't I go with the blue yonder right out of the gate? This is right after the gentleman had just got done telling me the story of SAP. And I'm like, well, it's the same thing all over again. That's, that's a mega vendor built for very big enterprises. The same issues apply. It's not meant to be something used by a small growing business out there where people are wearing multiple hats. So that's, that's one avenue there. But like, like you're saying, like the fancy features, I get questions a lot about, well, how do I get towards automation and robotics. I'm like, well, first of all, you need to, you need to crawl, then walk, then run. We're setting you up for the foundation of all those pieces. You're not going to do them all at once. And if you try to do them all at once, you're not going to be happy with results and it's going to take way longer and it costs so much more money. So it's, it's figuring out what are the fundamentals to get you going. And one of the places that I like to talk about is, uh, and I don't know how many other people do this is, it's the concept of put away. So you're receiving something in the logic inside of a system. The more you can tell it and the more rules you can define sets you up for staging inventory and managing and putting inventory away in certain places so that all the downstream activities that you execute in the warehouse are that much more streamlined. Like for instance, you have order profiles that, you know, certain, certain different products go together routinely. You can bake in rules in a system that supports that. So that's, that's a, uh, deciding factor right there. And now your picking operation is so much more streamlined, if that makes sense for your business. Those kinds of decisions there, if you can figure out and distill what works downstream, you can pull that upstream to the putaway process and then all your stuff flows nicely from there. So that's one, that's one avenue I'd like to get towards. And that will sell a demo. I've seen companies buy based on that. And then when we get into, start talking about, well, how would you make that work? It turns out that those decision points only live in people's heads. So there's nothing in any given system anywhere or any kind of hard data where they can put in a system. So that system can now look at that and then make those decisions so everyone can execute at a really high level. Like the guy that's been there for 10 years and then you know, the person who's been there for 10 weeks suddenly is a rock star too because they can do the same thing that doesn't exist. So again, it's a level setting thing where you got to walk back like, we'll get there. But like, let's figure out what you need to do today. Today you don't, you don't do anything barcode wise. That's a huge first step. That's going to be a challenge for your folks on the floor anyways, if you're not doing that, you get them used to it, figure out where, where they might be able to make mistakes and build in guardrails over time so everyone's operating smoothly. And then it's, it's this notion of continuous improvement. It's not this, you implement a system and it's great from day one. Like, no, you're going to be refining that your business is growing, your client profiles are changing. If you're a 3PL, uh, your brand as it's growing, you might have new SKUs coming in and it's depending on consumer taste, all those things change, which means you need a system that can adapt for it, which means you need flexibility. And that's, that's part of this, this whole process of going from WMS curious to having a system is what, what's important to you now, where you think you're going based on your business goals. And then we'll, we'll, we'll look for systems that make sense for you because there are a lot of systems out there that are easy to start with, all in ones, but then they have, you had a ceiling very quickly, which means now I have to replace that again way before maybe I thought I was going to. And that's a different beast there, going from one system to another versus nothing to one. So uh, those are all conditions and considerations that the folks need to be aware of so they can map it out so you know what you're spending and you have a realistic timeline and the resources you'll need to actually make that happen.
Speaker A: So I want to talk about something that's, I think the most overlooked part of WMS is and that is the downstream effects. Right? So everybody knows, oh, I get this new system. Maybe it's more accurate, maybe has certain features that we really need, maybe it speeds up my workflow. But there's two parties that are affected by a system Change that I don't think a lot of people talk about. And that is if you're a 3PL, it's your customer. Right. Your customer is going to have to learn the new system, new procedures, the way things work. And a lot of times they're resistant to change. Right. So this is something I run into a lot of times where people are like, hey, I'm going to make this big change. It's going to be great. He's going to get a better experience and then they lose a bunch of customers because they don't like change. Another thing I see is the training of employees. Right. So now you're going to put a new system in place that has new procedures. You're going to have to put in hundreds of hours into training your staff and you're going to have to make sure that there's a base level of competence in place before you roll this thing out live. Um, and I think these are two things that a lot of people overlook because they're so worried about what the WMS does and not actually how it's implemented and how the end users are going to actually interact with them.
Speaker B: Right, right. You get into the big companies and they love throwing around change management. That's like the term that all encompassing there. Yeah, it's very important. If you don't get people engaged and tied into it, especially if you're going from one system to another, you can't go backwards, you can't lose functionality. Not unless you're okay with your mix of customers changing. Right. You might, you might alienate some and be able to gain others. But that's a, that's a business strategy decision that you make. But you can't go backwards. And then if there's going to be a material change, you need to communicate it. And a lot of times it's, it's the, it's the transparency piece that's missing of why do we need to change? And this goes to training as well. And some ways, a lot of the experience I had, even with the big companies in small companies, it's a human nature issue, is getting everyone in the same room. And that's more of like in air quotes really. It's basically giving everyone a voice from leadership down to the folks that use it every day on the front line, they're like the last people to touch an order before it makes its way to the customer. Right. There's things that they might know about that, uh, leadership doesn't, vice versa. So connecting the dots. So everyone feels like they're part of something, it's not being pushed on them. They know how they contribute. That goes a long way towards getting people to buy into it. The training piece makes more sense because there might be, there might some rule out there that their job's going to get harder for whatever reason, but they understand the greater scheme of things. Yeah, but we got better here. So now I understand it. I'm not going to fight it so bad. Right. You know, there's, there's a lot of that stuff that can happen. And through 20 years of doing this for all kinds of different M size companies, I've seen it done well, but most of the time I've seen it not done very well. Right. It's, it's after the fact, it's that reactive nature that it's hard to get back out in front of again because once you start losing trust, you know, the folks are less likely to give it back to you.
Speaker A: Yeah, I, I kind of giggled a little bit ago when you were mentioning about like, you know, if it's your first scan system, right. First time you're verifying barcodes and uh, it kind of comes back to this whole idea of like conveying the information, why the change is necessary, right. Making sure people are trained correctly. Because if you're going from I'm not scanning barcodes to all of a sudden I'm dealing with pre cartonization, I'm scanning barcodes, I'm taking pictures of the things I'm packing, right? And I'm putting them into a sort system and I'm an employee. I'm sitting there going, well, uh, before I just click one button, the label comes out, put it on the box. It took me 10 seconds. Now I'm doing all this stuff and a lot of times they're the last ones to get the information on. You know why this is better? Like you and me as people who deal with systems who interact with this kind of technology regularly, you understand the value of putting those checks and balances in place. You understand why you'd want a pack shot, you understand why you want a barcode scan. You understand why you want to sort of by carrier earlier on in the process to the packer who's trying to, you know, see how many they can pack this hour. It's uh, you know, not quite so obvious. So you know, that communication piece is a really big part of any kind of implementation and I think it's a large part of the discussion when you're choosing a, uh, BMS or other tech platform is you know, how's the effect going to happen on my employees? Or are we going to be able to adapt to this? Are we capturing the data we need to be able to capture and you know, making sure you're ready for that change?
Speaker B: Yeah, oh, uh, very much so. Moving to, moving to a system could be a massive, massive change. Like you alluded to right there. Just giving out the examples of all these different verifications that are now there and present. They weren't before. You know, the person's like, why did this change? Especially if they're being compensated or rewarded based on number of, uh, packages per hour or something like that. Like, whoa, you, you just crushed me. Why? You know that? So there's maybe there's a compensation model that needs to change there too. So factoring all those pieces in and then that's, that's part of the conversation that needs to be there. It's understanding how something will bring, it won't always be a net, a net positive. There will be some, some things that take us, you know, take you backwards, but you're, you're, you're looking for the greater good.
Speaker A: Yeah, I had that, I had that exact thing play out, I want to say, eight years ago, right. So I was selling on E Commerce, right, selling on Amazon, Walmart, you know, a couple different channels. And we had one packer packed all the orders. She was just going to Skubana at the time and just print the label and put it on the package and she was doing like 35, 40 orders an hour by herself, you know, Fantastic. Well, when we upgraded our system, that packing went from 40 bucks an hour to more like 25. And there was a disconnect between, well, why did your production go so low, uh, go down so much? Meanwhile, she was using an entirely different system with multiple checks and balances with, you know, all these other requirements. And it was affecting her quote, unquote performance on paper, which affected her compensation.
Speaker B: Yeah, there's, there's, there's something to that.
Speaker A: Yeah.
Speaker B: Uh, the other side of it really though is when you have one person doing, when you're small, they can get very good at it. You add a second one in there, chances are you're going to see that dip anyways. And then you're introducing more potential for errors. So you're introducing like a scaling issue right there because the more, more people you add to it, the more propensity goes up and you're not going to get a great throughput there in terms of air free orders. Now with the, uh, Validations in there. Yeah, you're going to take a hit on that individual piece there. But as you scale, you're going to avoid all those, those other complications and returns and miss picks and orders. Those are vastly expensive because you might not get another chance from a customer. You might have just lost them there. And boom. Um, if you're a brand and you're, you're all about like uh, cost of acquisition and lifetime value, suddenly that lifetime value just went way down for that customer. You don't want too many of those. Negative feedback is way more powerful than positive feedback.
Speaker A: So if there were three factors you would consider most of all when looking at a 3, when looking at a WMS, what would they be?
Speaker B: Three factors. First one would be is it right size for me where I'm at and where I'm going next? So that means, um, the complexity of your operation right now, what kind of business you're in. There's the E commerce, direct to consumer, then there's three PL and there's an inside of three po. You might have a mix of that, you might have B2B. So a hybrid. There's, there's scenarios that you need to be watching for because a system might do one or the other very well trying to mix those, it might fall flat. Case in point, going back to the, the mega vendors, the system's too big for you. You're going to have issues just keeping up with it. If, uh, I've had this story before, you might be able to afford the subscription, the fairy tale implementation that goes along with it because they're usually never real. It's just the estimate when you get in there and you get into day to day and the ongoing pieces of it and the cost to your operation and number of people that just to maintain it might eat you alive knowing that and backing off of it. So the right system at that point. Other things that you're looking for is, is the vendor side of things. Not every vendor is the same. The partnerships that you have, the operation, the operating model, the maturity of the vendor plays a big part in as well. Because you want someone that's going to stick around. That's a big factor in terms of who do you pick? Do you pick the one that's just starting up, that has promising technology, but it's three guys and uh, they might not make it or as they grow, will you get the same kind of tension versus the massive ones where you're a number as well? Right. So it's paying attention to those pieces and some Vendors are better at specializing in what they do. So support is uh, another component of that relationship piece you call in. If they're more focused on your type of business in terms of the way you pick and the profile orders, they might be very more, they might be more helpful to answering your questions and you back on the rails if you do fall off them versus some out there that like we support a massive um, cross section of industries. We're looking for you to come to us with a defect and the steps to reproduce it. Not the question of like hey, I'm trying to get this out by 5, how do I do it? And suddenly they need to be an expert in your SOPs. Those don't line up. The smaller ones might have something better towards that, but that's also another one of those places too. Like what do I need to do for support in general? Because I might need to invest in a team that I don't have. Or I mean I need to make someone an expert. How long does that take? So those are other considerations. So the first one is the right sizing piece for this, the scale of the vendor. The other one is the vendor themselves and then I guess ad, uh living here. Uh, the other ones really come down to is what are some of the features that are in there you might not be able to take on today. But you know they're coming down the pipe at some point. And that's like you were talking about before. Does it have some type of robust, put away logic in there? A lot of the lower end warehouse management systems don't necessarily. They operate in this concept of you tell us where the SKU goes and we have a static assignment that's one end and then you have the other end of the spectrum where there's, there's a lot of logic in there that can do things on the fly and really adapt with you. If you have a very complex, drastically changing system or need anyways, you get into that. So usually that's a pretty good proxy in terms of the sophistication and adaptability of the system is what's it look like at the putaway side? Uh, you'll see pretty quickly just how mature they are or what their ambitions are. They might never get there because they don't need to from their audience. I could probably keep going, but I. Those are three, I guess another one just like a bonus would be how well it integrates with parcel carriers. So I mean this is kind of going back 15 years when I worked at Red Prairie we had a uh, we had a dedicated parcel product. This is all installed software. So this is going way back. Nothing cloud based at that point, but it had to be recertified with every carrier that we worked with every year because every carrier had rule changes, price changes. You had to incorporate into the software keeping that going. And then you had to integrate it with the warehouse management system. And that's only part of the, part of the puzzle there. I think you talked about pre manifesting earlier, knowing what you can do early on based on some information. The system is huge too, but there's limitations there in terms of what they can support. So a lot of the modern ones now if they are integrating directly with parcel carrier, it's going to be the APIs. But even further on one thing I like to look for, and this is more of a preference realistically, do they work with some type of multi carrier shipping system that could be something that's actually interfaced with dedicated workstation app or it's some kind of API behind the scenes that talks to all the major carriers, which can be huge because you can get some pretty good uh, rates that way and kind of get the whole economies of scale in a different way than it is going out and getting your own accounts. So there's, there's lots of little factors that can go in there.
Speaker A: Yeah. And just want to point out how important the customer support side of this is. Right. Because this is something that I think a lot of people overlook. And uh, that is this is the person that basically you're handing them the keys to your business. They're controlling all your data, your ability to get product out the door. Right. The ability to keep your workers productive. Right. Basically everything that controls your business, you just gave them the keys to it. And if they're not responsive, if they don't handle customer service the right way, they treat you like a number. You can't talk to the guy who runs the company, you can't talk to an account manager in a reasonable amount of time. There's gonna be issues, right. And those are gonna emerge way after you got done talking to the salesman six times a day and he sent you a birthday card and got you on, you know, 45 phone calls to sell you on a one year subscription. Right. So just remember that the guy selling you stuff is not the person doing support. So one of the things I recommend is that if possible send their support email, a couple emails and see how long it takes them.
Speaker B: There you go.
Speaker A: If you can't do that, maybe find somebody that uses their software and talk to them about it and get an idea of what it's like working with that company. Are they responsive? Right. Uh, you'll start to learn a whole lot more by talking to the users and actually interacting with the customer support team. Then you're going to learn from a salesman who's going to read off how quickly they respond via email based on some dashboard metric.
Speaker B: Yeah, that's for sure. There's a, um, there's a guy I follow. It's an ERSP space. So different than what we're talking about here. But there's one of the things he calls out and I like this. He's dealing with a totally different mix of industries and scale of companies. But on the implementation side he's like. Or the, I guess the training piece because training is so important. He said work with them early on. Like instead of like getting a sales demo that you normally would get in front of them and have them do some aspect of it. And he's like, don't be afraid to pay. Again, this is working with bigger companies. The premise there really is those trainers do a good job of showing and demonstrating the system early on before you buy the whole software. Maybe you pay it for the time. Then you have a better understanding of what you'd be getting into. If you use the vendors, trainers down the road, they actually know what they're doing, right?
Speaker A: Yeah.
Speaker B: Wants to walk early on versus being told they're great and then you don't know. Right now you're locked into a contract and your mileage may vary drastically.
Speaker A: Yeah, I mean I think that's the big one is like I said, the interpersonal types of things with this. Right. I brought up how your employees use it. Right. How your end customers use it. I've now talked about the customer support aspect of this. You're marrying a system. But that system's a lot more than just the physical piece of tech.
Speaker B: Right. For sure.
Speaker A: So do you have any, uh, closing thoughts or any takeaways that you think the listeners should take away from this call?
Speaker B: Right. Uh, yeah, I have some things I like to share. Typically one of the things that I see is these are, these are common, common issues effectively. So what one I call is a demo doom loop. Really what that is is a lot of companies will go out and they'll start talking to vendors and it's this, this, this fuzzy notion of, um, I'll know it when I see it. But typically that doesn't necessarily happen.
Speaker A: Right.
Speaker B: There's a lot of time spent looking at demos There's a lot of shiny objects and you don't quite. If you don't know what you're looking for, you're never really going to get past that. But also these are very polished demos. They're there to attract you based on something shiny. It's very shallow. And so one of the things I like to do is step back from that and say you need to do some things before you reach out to a vendor. And some of the general aspects are these assumptions that get to live rent free. Most of the time is, are my teams really aligned? And the question usually gets a yes, but guarantee you I've been in uh, implementations. We start doing the design, the configuration after the sale, I'll come into it and I'll ask a question that seems pretty simple. Everyone agrees and then you get multiple answers and people look around shocked that they're not aligned. And that's, that's where in the past that was the ugly conversation that I'm like, guess what guys? That timeline, that budget you thought was real is not real. We need to invest time right here. This one question and there's a bunch more so that trying to invest in those things up front, the other piece really is, yeah, everyone agrees their processes are buttoned up, but guarantee you that they're probably not documented if they are. Everyone's usually pretty quick about like, yeah, well, they don't really represent what we do now. Or it's only a part of it is investing in some type of process flow diagramming early on. I'm a fan of that, that style, ironing out what you're doing and if you get different teams in there and there's this notion of swim lanes so you can see where the handoffs are, getting people to agree and acknowledge where things go. It will open up doors and opportunities to talk about what do we need there. So we can spell that out because the better you are at showing how you operate at a physical level and where handoffs are between departments and what they're expecting will go a long way. When you do start looking at vendors and getting demos and then definitely on the other side of that when you get into implementation, because these are things that just don't exist. Even the big companies I work with, it was, it was mostly missing for the most part, or it was way out of date. It's a lot of pulling information from people at the time, which again goes back to blowing up budgets and timelines. So visually documenting what you do and the reason I'm a big fan of Visuals is because it's easy to pick up quickly. Someone can come in real quick and look at that and we just intuitively know how things connect. Or you can explain to them what that diagram means and they get it fast. Maybe if you have a document you got to sit there and sift through 10, 20, 100 pages, you're not going to get a whole lot from it. My reading comprehension sucks, so I imagine I'm probably not alone. The visual piece is huge and like, like I said again, it helps all the things downstream. And then the other part really is asking questions when you're doing those two different things with the team alignment and the processes is capturing where people are making decisions today. And this goes back to the putaway topic there is if someone's making a decision or they know just instinctually where things go based on size, dimensions, whatever. If you don't have that data, you're not going to get the same mileage from a system. You're more or less going to have a fancy system that's slowed down by a person making that decision and then you get all kinds of various ways of doing it. When you get more people, because everyone starts doing their, they have their preferences and they might not always be correct. And depending on what your product mix is, if you get into regulatory, regulated inventories or system, regular regulatory or regulated industries, there you go. Sorry. You're going to have things that might not mix well and bad things can happen.
Speaker A: Yeah. I thought it was really interesting that we came in for a 40 minute discussion about systems and technology and what we actually ended up talking about was people, business practices, quality of data and not a whole lot about systems. And I think that's really an important message here is that the system's a tool. It's built to help you and your business. And what actually matters is you, your processes, the things you need to be successful. Right. And if that tool aligns, uh, with those things exactly.
Speaker B: It can't lead. It supports. I think it's a big misnomer out there.
Speaker A: Awesome. Well, guys, thank you so much for checking out this episode of Disruptive Minds. We're putting out new content all the time, so check back often. Thank you so much for joining us and have a great day.
Speaker B: Man had a blaster.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.