When and why product dimensions matter
Stop me if you have heard this one: a guy walks into a store, shows a salesperson a picture of a shirt he likes, and says “I want this shirt, but I want it in the light blue and sized medium. Do you have it?” Not only does the salesperson have no idea if they have it, but they also have no idea what other colors or sizes it comes in. It is not for lack of trying. Most of the time it is due to their applications. Let me provide a personal example.
I have big feet. I cannot find my shoe size in most places. When I enter a store, rather than looking at different styles like most customers, I just ask the salesperson what styles they carry in my size. They are generally stumped by this question. Most run to the back office to check the inventory, box by box. They don’t even attempt to check their old retail systems to provide an answer. You may think this should be an easy question to answer, but if your systems do not handle product dimensions, it is a daunting task.
If you follow my postings, you would know by now that I am a big advocate for the product data structure. I have written about the differences between product dimensions, attributes and hierarchies, management of product attributes, and the consequences of inserting season codes to style numbers. With this posting, let me go deeper into product dimensions.
Product dimensions segment inventory and help us define Stock Keeping Units (SKUs). Being able to parse this information in a system provides us greater flexibility in data management. Let's take a simple jacket as an example. It has a certain style and comes in different colors and sizes. You will most likely define the sales price at the style level, yet the product cost may change by color and size (due to fabric and consumption costs). You may introduce different colors at different times. In short, you will have data maintained at different levels such as style (sales price, brand, etc.), style-color (design season, delivery start, etc.), and style-color-size level (cost, inventory, etc.).
Most legacy systems could not handle this dimensional logic and store all these data points at the SKU level. You can imagine how hard it would be to maintain sales prices across all color and size combinations under a style. Rather than changing one value at the style level, you would need to update more than a dozen values at the SKU level. This is time-consuming and prone to user error.
To mitigate these issues, some legacy systems-built data management tools to enable mass data updates. This is the reason why you hear legacy system users constantly asking about mass data management tools in new system selections. Fortunately, these would become irrelevant with the right product structure.
Besides data maintenance, product dimensions also help businesses provide visibility quickly across variants for a given style. For example, you can show inventory availability for each color and size combination in a grid when you inquire about a style. Users can quickly respond to customer questions with the best options. This capability can facilitate cross-selling opportunities.
If you are interested in learning more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.
