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 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 is called Stacks. Stacks 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 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.

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.

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 (learn more about manufacturer's SKU formats here), but all of them use SKUs to identify products.

New stores will often ask, "why use SKU when UPC is, by definition, a universal identifier?". It's a perfectly reasonable question with 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:

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 run specialty, Stacks have come to save the day!

Consider the Hoka Men's Bondi 7. 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').

Please note, we ignore punctuation and spaces in SKUs, so to the platform 120338 084, 120338-084, and 120338.084 are all the same SKU.

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

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!

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 how to manage your SKU-based inventory in the Run Free Platform, click the button below: