In recommerce, each item has a unique past, present, and future—condition history, planned availability, and value curve. That’s why inventories must be individualized (aka single-SKU, serialized) and event-driven (rentals, returns, maintenance, refurbishment, resale).
🧬 Single item identity over SKU counts
🧾 Events carry costs & revenue per item
📈 Value changes with history & future use
#recommerce #rental #serialized #inventory
Karri: Let's start with each item is unique.
Tuomo: Yeah, sure. So I think that's probably the easiest to understand or to explain. So in re-commerce you're selling or servitizing items that end up or already have a unique condition, unique creating, thus unique price points. So if you want to sell unique items which are almost collectible in nature, you have to make sure that all of your inventory is recorded and tracked on a single SKU basis, so single item level. That's essentially the simplified version there. So instead of aggregating bunch of stuff behind SKUs, you can still do that for reporting purposes or kind of describing relationships, but then behind that you still need to have that idea of every item is unique. It sounds quite simple, but I guess it actually makes the whole software and twice commerce in this case actually quite different compared to the let's say traditional or linear commerce software. It is quite simple if you just think about it as a let's take a snapshot of a situation and how does the data look like? In that sense it is simple. The complex aspect of that starts to come about when you have to build relationships between your catalog and a single SKU inventory. So how do you productize your single SKU inventory in a dynamic way? Or in order fulfillment if you kind of assign individual items to orders, in order fulfillment do your employees need to find that specific item? Or are there still like some opportunities to switch items? So the complexities start to come about in operational context. If you look into it purely in data modeling, it's quite simple. You just kind of explode those SKUs into single articles, but then the challenges come from aggregating data and knowledge to those single items and how those then affect the operational context of order fulfillment or categorization of that. So there's a lot of then the complexities come kind of afterwards.
Karri: It sounds like in this type of single SKU inventory where you're tracking each item individually you're kind of by default your catalog is not your inventory. It might not be the same in linear businesses either, but it's there maybe more linked to each other.
Tuomo: Yeah, cutting a lot of corners and again probably simplifying the level that earns a couple of hateful comments wherever this is published, but in traditional linear commerce there was a, or there is a relationship between your catalog and your inventory in a way that you could define your catalog and then once you have a product in your catalog you can tell what is the SKU, so the stock keeping unit of this catalog item. And then against that SKU space you could say how many of these items I have. So stock keeping unit it kind of comes from the aspect that how do we keep stock for this catalog item. So it made things a bit simpler. So you could say that keeping stock, keeping track of stock was kind of keeping track of a number, that quantity number that goes up and down depending on how much you sell or buy in. Whereas in single SKU tracking your catalog is a bit more dynamic, especially if you do rentals for example, so individual items can fulfill that order. And then as that relationship becomes a lot more complex, so does the inventory tracking and then all of that.
Karri: And I guess there is also this kind of new need when the items are actually coming back and having multiple cycles that you actually track events on those individual items as well, something that's not usually needed in the linear commerce world.
Tuomo: Yeah, from the perspective of a merchant in linear commerce you hold on to that product for the whole time that you hold on to the product it's kind of static in state. And by state I mean like the condition and price and all of that. You kind of assume it to be, if it wouldn't be it would be a defect defected item or something like that. But in your happy path your assumption is that all of those are the same and they stay the same until you send it out. And then you might have had to kind of like tip your toes into this water if you tried to professionalize your product returns for example and making something out of that. So then you had kind of this item but maybe a little bit different, it maybe has a scratch somewhere or it's once used so you had to start to identify them as maybe a sub-skew of something like it's this skew but a bit different. So, but yeah in linear commerce historically you could say that they were all kind of similar but then when we go to re-commerce items become unique and as you said you need to start tracking these kind of events that connect to that item because they change the nature of that item and the facts about that item and that's probably what we'll discuss when we talk about the temporality.