The problem with SKUs are that they’re too perfect

When we think about it, SKUs are simple in theory. They are nothing but a label, a code which contains everything there is to know about a product. In the real world? They start to crack under pressure.

Imagine a modern day retail chain’s warehouse operations. A customer looking to remodel their office places an order for a “Study Desk” and an “Office Chair”. They make the payment and thus starts the waiting game. Ultimately the order got delayed, the retail chain got a bad review cursing them for poor service, while the customer got an apology mail for the delayed order.

What the customer did not know, and what the system was not able to track throughout the order lifecycle, was that:

1. The study desk had multiple parts which needed to be delivered together as a whole.
2. The office chair packed by the warehouse team belonged to an older manufacturing batch - one so old that it had become brittle and broke before it could be loaded.

Both of these items belonged to a supposedly well defined SKU, but when it came to pick, pack and deliver, the definition fell apart. The SKUs had no visibility into what’s inside, or what’s wrong.

A simple label, a costly mess.

We’ve seen this same issue play out across so many industries, that we could see the chinks in the armour. The SKU as we know it, was designed with the word “ideal” at its core, however the real world is seldom what we thought it would to be.

In pharmaceuticals, medical distributors deal with temperature sensitive medication all the time. A batch going cold because of a cold-chain breakdown had no distinction of its own. That batch of medication reaching a customer is a major compliance failure but there was no way to trace what went where because the SKU was the same across all units with zero emphasis on tracing batches.

A customer ordering cold drinks for a party at their house ended up over-ordering and rejecting a few items at the time of delivery. Cold drinks packed in 6-packs could only have been delivered in multiples of 6, right? Exactly! But when the delivery agent accidentally input 29 instead of 30, the entire team went crazy trying to figure out where that 1 can went.

When delivering fresh groceries to a large food chain, the franchise manager rejected some quantity of meat because of spoilage. They got billed on the basis of weight, but could accept or reject only on the basis of quantity. But surely, all packages of meat can’t be the same weight! There has to be a better way to record this transaction!

Each of these cases is not a failure of people, but of structure.

The SKU was everyone’s problem - so we took it personally.

At Locus, we’re determined to become a full-fledged delivery and supply chain officer. That means our tools have to work in the real world, even with all the chaos, exceptions and imperfections.

That’s what sparked the SKU revamp.

Not a shiny product initiative, but a necessary rebuild.

Well, it was actually a delivery we received at the office which demonstrated in detail how SKU handling fails on ground, but that’s a story for another day. Wink, wink!

Designing for things our systems usually ignore.

While doing our research and getting to talk to dozens of people facing similar problems in their logistics, one thing became crystal clear. Our goal wasn’t to make SKUs more “feature-rich.” Instead, it was to make them more honest and empathetic to the messy truths that make logistics hard.

A few shortcomings, we realised, were translating to real world cost for our clients:

1. Lack of batch level tracking meant inventory mismanagement, regulatory challenges, spoilage and non-compliance penalties.
2. Insufficient part-level visibility meant incomplete deliveries, replacement logistics, poor customer experience.
3. Rigid transaction tracking based only on quantity translated to poor record keeping and billing errors.
4. No mapping maintained for which SKU is kept in which asset in what quantity. This resulted in packing errors and delayed handovers.

So we reimagined our SKUs to have batch and part level details, reflect packaging realities (yes, “2 packages and 1 loose item” is an actual data point now) and be transacted by a combination of quantity, weight or volume. SKUs within Locus can now be tracked at the asset level at every step of the way - from homebase loading to doorstep delivery. This means that whether you’re delivering medical kits or DIY furniture, your system now knows what was packed, where, and how much of it made it — no guesswork required.

The build was hard. That was the point.

As the build cycle progressed, we stuck to one principle. Our job was simple. We weren’t trying to fix the industry, we were designing for its imperfections. After spending a lot of time in research - discussing problems big and small - we knew what we wanted to do.

The first piece of the puzzle was the SKU itself. We remodelled it in such a way that at the time of creation, a user would be able to store information at the most granular level - including batch information, part details, reference images and packaging details.

The next step was to make sure all products within the Locus ecosystem interact with an SKU in a consistent yet flexible way - moulding processes in a way that suit the client best. This meant enhancing the SKU further to allow users to define exactly how they want their products to be transacted on. A user can now configure units of measurement as well as constraints for those units of measurement for each product.

Lastly, we realised that the tool most used by workforce on ground - the Locus on the Road mobile application - was unintuitive and was no match for the plethora of processes implemented on ground. We enhanced it to allow for configurations which can better shadow on ground processes. The application can now effectively replace delivery manifests, not just emulate those!

Riders and even dashboard users can now confirm deliveries fully, partially, or in the worst case, reject them altogether. They can transact across sealed or unsealed assets, and reconcile missing items and track everything down to the last gram.

Why did we put in so much effort for a problem which could have been solved by storing a little more data for each SKU? Simple, because at Locus, we believe logistics software must model the world as it is, not as it should be.

The tech behind the scenes.

This entire project is colloquially referred to as the “SKU Revamp” within the organisation. It was not just a frontend redesign. In the past few months, we have touched nearly every corner of our platform, to make sure the experience is consistent across all products within the Locus ecosystem.

As a result, the following products have seen the largest set of changes:

1. Order IQ - Our order management system (OMS) now supports batch and part awareness across orders supported by new create and edit APIs and updated callbacks. Dashboard users will also get better visibility into order details with the ability to track transaction at different stages across the order lifecycle.
2. Dispatch IQ - Updated dashboard and ability to take package level transaction time into consideration for dispatch planning
3. Track IQ - Live view dashboard now has additional details for each visit detailing out batch, part and asset details
4. LoTR - The mobile application now supports more flexibility in terms of flows, allowed actions and processes.
5. TDMS - Better visibility in terms of what was delivered and what needs to be returned by riders at the end of tours.

Who gains from the new system?

The proudest thing about revamping the entire SKU system is the fact that every user gains something from this enhancement. Be it clients, operations teams, riders or finance teams - the value addition we’ll be able to provide with this development is what keeps all of us at Locus encouraged to constantly go out there and build new things.

1. For clients, we will now provide more control, better traceability and regulation readiness
2. For operations teams, we will be able to ensure fewer errors, clearer packaging and more efficient loading
3. Riders and warehouse staff will now be able to understand what is missing, broken or packed wrongly - instantly!
4. Finance and customer success teams will be able to do RCAs for delivery failures faster and easier.

Are there any lessons to be learnt for product builders?

During this development, one small build often had major cascading effects on other parts of the product which nobody had even thought of. As product builders of today, building products for the future, it is important that we design for partial, broken or delayed data. Simply because we built a system in a certain way, does not mean it will be used like that on ground. The moment we acknowledge that, we can build systems with room for evolution, and not just scale.

Every new data model we create, will always translate to a UX decision downstream, and the more complex our data models become, the worse the UX tends to be. We as product builders often get carried away trying to build for scale, often forgetting the most important principle - a product needs to be simple and intuitive to use.

The final word: a better SKU for a better world.

In fixing SKUs, we didn’t just add metadata. We built a better mirror — one that reflects how things actually move, break, spoil, return, and succeed in the real world. We’ve always believed that logistics software shouldn’t just manage data. It should earn trust. And with the new SKU model, we’re one step closer.

Want a peek at SKU modelling for cold-chain, large-format retail or omni-channel workflows? Book a walkthrough with our product team today!