Why Does Run Free Project Use SKUs?

We’re often asked Why does Run Free use SKUs instead of UPCs to organize products? It’s a great question and this article explains the reasons.

The Challenge of Relationships at Scale

Our platform design philosophy prioritizes automation at every turn.

When it comes to managing inventory online, the best way to maximize automation is to establish a deep, bi-directional POS (point of sale) system integration. The thinking goes… If you’ve already taken the time to enter a product into your POS, why should you have to turn and re-create the same thing in your ecommerce platform?

As a Run Free Project member, when you add a new product into your POS system, it automatically adds itself to your ecommerce store, pulling in pictures and a description from our Metabase, with no delays or human intervention necessary.

Seems pretty simple, right?

Conceptually it is, but in practice it’s a complex puzzle. When you dig into the details, there are difficult scalability and relationship challenges that arise from trying to accomplish this level of automation.

Every POS (we integrate with RICS, Lightspeed, and Heartland Retail) handles product groupings very differently, and none of them pass relationship information (such as grids) to integrated systems like Run Free. Think about this… If you have three colors of the same shoe, how would Run Free automatically know to group them together as one product while being able to present a variety of colors, widths, and sizes as options to the customer, instead of listing them as a bunch of separate products?

Historically, ecommerce systems solved this problem by creating an “item” for every unique UPC code, and forcing the user (you) to manually group those items together as products in the ecommerce platform by hand, a monumentally time-consuming process.

At the opposite extreme, to avoid the massive effort that comes with manually grouping individual UPC-based items into products, other ecommerce platforms simply limit what you can list, allowing only products they approve. If you want to add a new product, you have to contact them and request they list it for you, taking tons of your time and stripping you of control over your inventory and your online storefront.

Neither of these methods is elegant or effective, and when we designed our platform, we knew we needed to build something better. Something that maximizes automation while also giving you the authority to list anything you want, when you want, without the hassle or delay of manual approval processes.

Run Free Project’s solution was to use SKUs as the basis for product listings instead of UPCs.

Don’t freak out just yet… We still store and use UPCs, we just don’t force you to use them as a basis of organization. Our method saves a massive amount of time, uses automation to group items together as products, and is compatible across all POS systems.

This article explains what SKUs are, how we solved the manual item grouping problem with them, and what all of this means to you as a Run Free Project member.

What are SKUs?

In the run specialty retail industry, SKUs are used by manufacturers to identify items at the “product” level. For example, Hoka uses the SKU 1110518 BMMO to identify the Men’s Bondi 7 in Blue Moon/Moonlit Ocean, regardless of size. Even though each of the 16 different sizes of the Men’s Bondi 7 available in Blue Moon/Moonlit Ocean has its own unique UPC, they all share the same SKU, 1110518 BMMO.

Hoka Men’s Bondi 7 in Blue Moon/Moonlit Ocean, SKU 1110518 BMMO

When it comes to shoes, most manufacturers use the style (Men’s Bondi 7) and the color (Blue Moon/Moonlit Ocean) to determine their SKUs. Some include widths in their SKUs too. Ultimately, each manufacturer utilizes a unique combination of characteristics when defining their SKUs, but all of them use SKUs to identify products.

Why does Run Free Project use SKUs?

New stores will often ask, “why use SKU when UPC is, by definition, a universal identifier?”. It’s a surprisingly simple answer: Because a SKU-based system saves you time and effort at orders of magnitude when compared to a UPC-based system.

How?

It boils down to math and scale. The Hoka Men’s Bondi 7 is available in 12 colors, and each color is produced in 16 different sizes with three different widths. This means that there are 576 different UPC codes to account for all the colors, sizes, and widths of the Men’s Bondi 7, which is a single product.

In a UPC-driven ecommerce platform, you would have to manually sort through and group each of the 576 unique “items” that make up the Men’s Bondi 7 product.

It gets uglier when you take product and vendor scale into consideration. If you carry 10 different manufacturers in your store, (assuming each manufacturer releases 10 styles per season), you would be responsible for manually grouping 57,600 items into product listings your customers could navigate within your ecommerce platform at the beginning of each season.

Let’s pause here…

You may be thinking “my other ecommerce platform didn’t make me manage 57,600 items every season and they’re UPC-based. What gives?”.

Put simply, other ecommerce providers have ‘solved’ this problem by compromising the functionality of their platform in either of two ways:

1. They limit their POS integration to be a ‘pull-only’ system, such that their ecommerce product can retrieve inventory counts from your POS, but they cannot push information back to the POS system (or they simply choose not to integrate with the POS at all). This forces you and your employees to manually replicate every single order you receive from your online store in your POS system and adjust inventory by hand as sales come through online. This design also significantly increases the risk of inadvertently ‘overselling’ product if you haven’t hand-adjusted inventory in time for the next customer.
2. They restrict your ability to add products to your own online store, forcing you to submit product listings to them to add for you. If they approve the product listing, they have to create the product manually, creating days (or weeks) of delay. If they choose to deny your listing request, you’re out of luck. You have zero authority over your online inventory.

Unfortunately, these design compromises cripple your ability to present an omni-channel presence to your customers, they create more work for you, limit what you can sell online, and create a clunky separation between the online store experience and your brick and mortar business. In modern retail, these compromises are unacceptable.

Luckily for running stores, SKUs have come to the rescue!

Consider the Hoka Men’s Bondi 7 again. At its most granular, the product consists of 576 UPCs. However, it only consists of 12 SKUs. The UPCs are still there, but the SKUs define how Run Free organizes the product(s). The best part is, all modern POS vendors account for SKU hierarchies with gridding systems. In essence, a SKU-based ecommerce platform reduces the number of items you have to manage by over 98%.

The image below shows the hierarchy-style relationship between SKUs (the ‘parents’) and UPCs (the ‘children’).

To illustrate this concept further, the image below shows how a SKU/UPC hierarchy might look in a bulk import for your POS.

Notice how each entry in the table above has a unique UPC, but they all share the same SKU. 

So What are the Implications?

In most cases, outside of saving a lot of time, not much. The run specialty industry has had SKU-driven product definitions for decades, and all POS vendors provide a method for accounting for them. Each handles gridding and hierarchies differently, but the SKU’s relationship to its underlying UPC is constant.

In some cases, POS vendors don’t require SKUs to be entered and some retailers have chosen not to include them when accounting for inventory. This means that SKUs will need to be added so their natural hierarchy can be expressed on the ecommerce platform. At the Run Free Project, we have quite a few tools at our disposal to assist if you haven’t accounted for SKUs.

First, we’ll simply export a full product inventory from your POS, cross reference the UPCs with their associated SKUs in the Run Free Metabase, then import the inventory with the added SKUs back into your POS. Then, as you bring in new product, just be sure to include the manufacturer’s SKU in your imports (or scans), and you’re good to go!

What should You do?

Run Free Project doesn’t police your use of SKUs, you have complete control over the naming conventions you choose when defining them. However, we highly recommend using the manufacturer’s SKU as published. This significantly increases the chance of a match in the Metabase (which means the platform will automatically add pictures and descriptions for you), it ensures that items from your POS and items from Relay mesh together seamlessly, and makes it easier to manage relationships and new product additions in the future.

To learn more about how the Run Free Project simplifies running store commerce and saves you a ton of time as compared to other platforms, send us a chat message by clicking the little blue icon to the right.