To understand the complexities of B2B, and more specifically the evolution of the B2B data model, you need look no further than another revolutionary (albeit older) tool that dramatically changed the efficiency of businesses – the telephone.
Let’s start with a simple example. You are a customer service rep on the telephone with your customer. You know your customer’s preferences, such as which products they order from you most often. Also, you know how much you charge them for these products. By conversing with them you can fulfill their new order by playing the “role” of a “seller” and your customer the “role” of the “buyer.”
Now let’s say you hang up the phone with your customer and you call one of your suppliers. You need to fill the order you just received and you know a specific supplier you want to use. As you talk to your supplier on the phone, you are now playing the role of the “buyer” and your supplier is playing the role of the “seller.”
So, via the telephone, you can be both a “buyer” and a “seller.” The role you are playing at any given time is based on your relationship to the party on the other end of the line. In B2B we call this “relationship logic” and it sits at the core of the data models required to deliver on complex ordering scenarios.
Obviously the telephone is just a communication technology and has no intelligence in and of itself. It’s the human on the end of the line that owns the “data model” by knowing their customers and uses “relationship logic” to conduct business. Most small and midsize businesses rely heavily on the tribal knowledge they possess about their customers and suppliers. On the phone I can give different prices and products to different buyers based on who I am talking to. I can also provide them with completely different product sets and prices if I want to. If I get an order, I can source or bid those products based on different supplier relationships I maintain and my knowledge of the supply chain. In essence, I have the “data model” (what I sell, to whom, and for how much) and the “relationship logic” (who I sell to and who I buy from) in my head – or in my Excel spreadsheet, as the case may be.
So what does any of this have to do with B2B eCommerce? Well, everything actually. Relationship Logic is what makes a complex B2B data model simple.
In software, you often hear people say “we can’t use that product because it doesn’t support our requirements,” or “the software doesn’t work the way we work.” That just means the software’s data model cannot replicate the business’s data model and the software’s relationship logic cannot replicate the business’s relationship logic.
To be successful in B2B Commerce, you need to find a platform that allows you to configure YOUR data model and relationship logic onto them – not the other way around.
Here are a few fundamental capabilities of Relationship Logic that are available via OrderCloud.io:
- The ability to create User Groups and Roles. By placing users in groups you can mimic the relationship logic you manage with your customer base and filter what products different groups can see, what prices different groups can see and what order management rules groups are subject to – like approvals, and min/max order quantities, and default shipping locations.
- The ability to decouple price from product. This allows you to manage one source of product content and apply different prices for different clients or different prices to different users within the same client.
- The ability to decouple products from buyers. Like the example above, this allows you to sell the same product to many different buyers that have different ordering rules.
- The ability to associate product relationships to suppliers. In the “buyer” role, you may want to have certain products only sourced from a default supplier. In other cases you may have multiple vendors from which the product can be sourced.
In the end, B2B eCommerce is just plain old commerce. And if your platform has the right data model and relationship logic, it can be as easy as making phone calls used to be – just a whole lot more efficient.