How To Choose Your Inventory Software

Introduction

What's up, guys? This is Jared. I'm the founder and CEO of Luminous, supply chain and inventory management for the modern e-commerce brand. We help modern e-commerce companies get past their first critical mass event. I have plenty of content on that if you want to see it, and if you want to follow Luminous's journey as we become the top inventory management solution for e-commerce, follow along.

Today I want to guide you through a framework for choosing a software or tool for your supply chain. I routinely run into prospects with the same story: "Hey, I'm using ShipStation and Google Sheets," or "I'm using order management tool X, Google Sheets and maybe an inventory solution, and it's not working for me. I'm experiencing pain points X, Y and Z." In other words, it's not solving their supply chain problems, from purchasing to forecasting to pick and pack and more advanced WMS features. It's not serving them, and they don't know why, or they think they know why.

It's about fit, not good or bad software

So I want to introduce the framework we walk prospects through so they can decide on the best tool or feature for their business. Out of all the systems on the market, like NetSuite, Dynamics 365, and tools that are further down market like SkuVault, Katana, Skubana, Extensiv and Linnworks, it's my belief that it's not about whether a tool is good or bad. It's whether it's a good or bad fit for your business. You also need to answer the question: how much process and friction are you willing to accept in order to implement a tool?

This framework will help you identify where you are on that curve, and hopefully prevent you from either over-implementing, and feeling the pain of over-implementing and overpaying, or under-implementing and paying the cost of that.

The complexity curve

To set up the framework, I have a super simple line graph. Complexity and processes are on the y-axis, and time in business is on the x-axis. The assumption is pretty obvious: as your business grows over time, it gets more and more complex. These markers represent events in your history that led to more complexity, or a need for another solution or feature.

On this curve, there's an ideal amount of complexity introduced at a certain time. Ideally, you only initiate more complexity, processes and software as you grow. That matters because if your software and processes are under-implemented, below your complexity, you feel pain from a lack of processes and a lack of solutions. The inverse is also true: if you over-implement processes and software, that's equally painful and could spiral you out of business.

So how do you identify just the right amount of process and software, and which software is right for you? Timing matters, the solution you choose matters, and the price point matters. You'll feel the pain if you over-implement or under-implement. So how do we identify where we are on this curve and make the best decision for our supply chain?

Under-implementing: a bridal retail example

I'll walk you through a prospect I did this with today. I thought she was a great example of the modern e-commerce brand, and of some of the mistakes that lead to under-implementing, the pain she's now feeling, and how we guided her to a decision about what to do next.

I did a demo with a company that thought they were a bridal retail store. There was nothing wrong with their early decisions, but it led them to implement a neat, smaller ERP built for the bridal industry called BridalLive. Their tech stack was BridalLive and BigCommerce.

These were their assumptions when they implemented BridalLive. They were feeling the pain points of what they thought was a bridal store, and they got pitched and sold BridalLive. On the same chart, these were the projected markers of a bridal business when they started, maybe 10 years ago: first we open a retail store, then we need inventory tracking, then a second retail store, then custom booking because we're a bridal business, then an advanced CRM that merges bridal appointments and sizing into an invoice, then five-plus storefronts, and so on. A lot of assumptions about the type of business they were.

What actually happened with BridalLive and BigCommerce is that they only implemented a small part of the system. They got to about their second store and didn't really use custom bookings. Why were they under-utilizing the BridalLive platform?

When she came to me, she said, "Man, does BridalLive suck, or do I suck at operations?" Well, no. BridalLive doesn't suck if you're a bridal retail store. It's actually really good and pretty cheap. Maybe the support isn't great, but it does a lot for that industry. Here's the problem. She came to me with real issues: "My channel syncs with e-commerce don't work." BridalLive wasn't built to interface with e-commerce very well. "I'm overselling inventory. I'm under-purchasing because the forecasting isn't correct. My inventory numbers aren't accurate. I can't route orders between my two stores," because she was using those two stores like fulfillment centers. Big issues.

Those pain points come from being under-implemented. Why was she under-implemented? She had a false understanding of what complexity was going to be added over time. She more closely resembled a multichannel e-commerce company, the evolution of a modern e-commerce brand, than a niche bridal store.

Her actual markers looked like this, and she wasn't reacting to them. Selling to retail stores was really the first marker. Then she opened direct-to-consumer sales, which needed more WMS, order routing and pick and pack settings. Then channel syncs, as she went multichannel. Then she expanded into specialty wholesale, which introduced issues with inventory allocation. That's what caused her under-implementation. The systems she had in place, BridalLive and BigCommerce, weren't addressing those markers of complexity, which led to her pain points.

The cost of under-implementing

So what's the cost of under-implementation? Typically, you're not scaling as fast as you could. It almost always represents room for growth. If I can stop overselling or under-purchasing, route orders more effectively, or get more visibility, nine times out of ten that leads to more growth. She could put her time into expanding wholesale or other revenue streams, or doubling down on Shopify and Amazon, instead of manually updating inventory numbers in BigCommerce. It represents an inability to scale, or to get past that first critical mass event. That's what she's experiencing right now.

Honestly, you could replace that tech stack with Google Sheets and ShipStation. That's super common. I see it all the time: you're doing $1 million to $2 million a year, you're on Google Sheets and ShipStation, you start experiencing similar pain points, and you're wondering why. It's probably because ShipStation isn't made to do all of those things effectively.

Over-implementing: the big ERP trap

Now let's move to the other example. The inverse is also true. That's what it feels like to be under-implemented and underserved by your software and processes. Here's what it feels like to be over-implemented.

Let's say an imaginary brand is using Finale Inventory and ShipStation. Here's their evolution as a brand. Early on, they outsource to a 3PL, which introduces some complexity. Then they expand to Amazon. Then they become a multichannel distribution brand, and they need min/max levels and forecasting for all those distribution centers and all those inputs and outputs. Then they start specialty wholesale, then big-box retail, which introduces EDI. Maybe there's a potential future event, like taking on funding, so they'll need better financials and better integration with QuickBooks. You get the general idea.

Their actual curve probably started with not much, just Google Sheets, and then, boom, they implemented Finale Inventory, a more down-market inventory tool, and maybe ShipStation at the same time. Then they start getting more complex, and it starts not serving them, especially when they introduce wholesale. Boom, they're experiencing under-implementation. And they really want to skip to the next level, because they can see the benefit of expanding into big-box retail and wholesale, and they're getting good revenue. "Shoot, we need another system."

This is where you see brands over-implement. At this crucial point, a lot of brands choose a big, hairy ERP. I'll put NetSuite here, because NetSuite tries to go down market and fit a square peg into a round hole all the time. "Hey, we're NetSuite," or Acumatica or Dynamics 365, or insert massive ERP here, "and we're going to come in and over-implement you."

Brands get sold on massive ERPs: "You're doing big-box retail and some wholesale, and you need better financials if you're going to fundraise. Well, we're NetSuite. We're the biggest in the market and we can do everything." They start throwing out EDI form numbers, and operators get talked over. They don't really understand exactly which complexities need to be solved, and they end up going with NetSuite.

The real cost of over-implementing

Not only is there the pain of price. For this brand, NetSuite would probably quote something like a $200,000 implementation and $7,000 a month all in. I'm pretty familiar with big ERP prices. So they go from their old cost to this cost, and it introduces unnecessary friction. You might not feel it immediately, but you will eventually, and you'll eventually stop using the big system.

Not only that, but when your contract renewal is up, they'll say, "Your cost is now $8,000 a month." And the brand is sitting there going, "Dude, my actual use of your software is right here. You're raising my price to $8,000 a month, and you weren't even servicing me the way I needed. I'm not even using all your features." That's why the year-two NetSuite contract negotiation feels the way it does after you've made this mistake.

So what does over-implemented actually feel like? Too much friction and too many processes. Initially they were thinking, "I started selling to Target and Scheels, so I need EDI. I also started specialty wholesale, and I was doing invoicing in QuickBooks, and it wasn't syncing with my inventory system or with ShipStation." They felt that pain because of new complexity, and on top of that there's a possible future event, like taking on funding and needing more complex financial reporting.

This is the fallacy. If you're trying to solve those things, you don't need NetSuite. You don't need Acumatica or Dynamics 365. You might, but you'd have to be a pretty complex, pretty big company to actually need them. This is why plotting out the y-axis of your company is so important. If you're feeling pain, ask why. What event in your history caused it? Identify it, and look for solutions that solve it without adding so much friction and process. Because if you go to NetSuite and you're stuck in a $7,000 or $8,000 a month contract, it's going to feel like too much friction and too much process.

Example: a transfer order before and after a big ERP

Here's an example I see all the time. You go multichannel distribution, and you just want more visibility as you send goods to and from your 3PL or Amazon. You wish you had more visibility into transfers.

Here's the process before you implement something like NetSuite or SAP, and it has zero friction: you tell someone you're sending 100 units to Amazon, you update 100 units in your Amazon store, you take it out of your Google Sheet, and you're done. Now, there's a cost to that. If you want really good forecasting and inventory visibility, and you want every input and output to be correct so you can purchase correctly and scale optimally, that visibility is important. Having it in your actual inventory software, tied into your forecasting, instead of a Google Sheet, is important.

But if you think you need NetSuite to solve that, you might regret it later. Let me show you what a transfer order might look like in SAP, after you paid $200,000 to $300,000 to implement it and changed a lot of other processes. Instead of taking 100 units out of Google Sheets and adding them to Amazon, look at what you just introduced. You create a transfer order and add all these different things. You choose the warehouse, set warehouse rules and route an actual path for the order. There might be approval processes. You might have to take it through pick and pack if that warehouse requires it: initiate the picking, stop the picking, finish it, add a delivery note, go to the display of the transfer order, and so on. You get it.

"I wish I could see incoming on my transfer orders" doesn't mean you need SAP. Do you feel the unnecessary friction and processes, and how that could cost you as a business? You thought NetSuite would get you up here, but really you just over-implemented, and it's really uncomfortable. When your contract bumps up the next year, it's a tough conversation and a hard place to be as an operator.

Where Luminous fits

I'll do a more updated model in another video. I have different archetypes of modern e-commerce brands. I feel like most e-commerce companies fit certain archetypes, and based on that, I can reasonably plot out your path of complexity and what a good system could be for you. In this video, I just wanted to introduce the framework, and maybe explain why it feels like you overextended into NetSuite, or why you're under-implemented on your current solution and feeling a lot of pain.

Here's where Luminous fits. I don't want to force you onto our system. If Luminous is overkill for you, it's not a good fit. If you're a brand selling on Shopify with one warehouse and two products, don't use Luminous. We're too complicated for you.

With that said, the whole goal of Luminous, my why behind it, shows up in how we monetize and how we service you. We come in and say, "Let's implement this transfer order and give you the visibility you want with the least amount of friction possible." Or, "Let's give you the value of a forecast, or aggregate your wholesale data, with the least friction possible." Then we do the next feature, and the next feature, and we only monetize when we're actually helping you scale. That's the goal of Luminous, and that's how we're disrupting.

If this is interesting to you, follow for more content. I'm going to break this framework down in more depth for modern e-commerce brands, with different archetypes you can identify with. I'll even have a chart where you can assess the cost of implementing a new process, tool or feature. So look out for that. Thanks, guys. Peace.