When I talk with B2B manufacturers, distributors, and commerce teams, one theme comes up again and again: complexity.
Not just product complexity. Not just pricing complexity. The deeper issue is that many B2B businesses are trying to serve different brands, regions, customer groups, contract rules, catalogs, and buying experiences through systems that were never really designed for that level of operational nuance.
That was the focus of my recent conversation with Tom Flierl, Chief Commercial Officer at Amla Commerce, on the Human Element podcast, Beyond the Cart. We spent the episode talking about Znode’s B2B commerce platform, with a specific focus on its multi-store functionality.
And the more we talked, the more one point became clear: for many B2B companies, multi-store commerce is not a “nice to have.” It is quickly becoming a core requirement.
When a Single Storefront Is No Longer Enough
One of the first questions I asked Tom was simple: how does a business know when it has outgrown a single storefront?
The answer is not always that the storefront itself has failed. More often, the business model has become too complex for a single storefront approach.
That complexity can show up in several ways.
A company may go through merger and acquisition activity and suddenly need to support multiple brands under one parent organization. A manufacturer or distributor may need separate storefronts for different business units, regions, or customer groups. Some companies need customer-specific stores where each experience is branded for a particular account and only includes the approved products, pricing, payment methods, and workflows tied to that customer.
This is especially common in industries like uniforms, safety products, promotional products, branded apparel, and industrial distribution. In those scenarios, a buyer may not simply be browsing a general catalog. They may be logging into a company-specific program with approved SKUs, logos, spend limits, vouchers, and contract terms.
That is where multi-store commerce starts to become extremely important.
B2B Commerce Is Really About Catalog Management
One of the biggest takeaways from my conversation with Tom was that in B2B, catalog management is everything.
A lot of platforms can say they support B2B. They may offer account structures, customer-specific pricing, or some type of company login. Those are important features, but they are only part of the equation.
The real challenge is managing the relationship between products, catalogs, accounts, pricing, storefronts, and contract rules.
For example, if I work for Company A and log into a uniform program, I should only see Company A’s approved products, logos, and purchase options. I should not see Company B’s uniform program. If I am a plumber buying from a large distributor, I may not want to dig through electrical products that are irrelevant to my business. I need the catalog that fits my segment, my account, and my buying relationship.
That level of control is hard to bolt onto a platform that was originally designed around a single catalog and a single storefront.
This is where Znode’s architecture stands out. It was built from the beginning with multi-store B2B commerce in mind. At the core of the platform is a built-in PIM, or product information management system, that allows product data and catalogs to be managed centrally. From there, catalogs can be assigned across storefronts in flexible ways: one-to-many, many-to-one, or many-to-many.
That matters because it avoids unnecessary duplication. Instead of exporting and maintaining separate versions of the same catalog for every storefront, product data can be managed centrally and applied where it needs to go.
For B2B organizations trying to scale without creating more operational mess, that architecture is a major advantage.
Centralized Control With Localized Experiences
One of the ideas Tom and I kept coming back to was centralized control with localized experiences.
That phrase gets used a lot in commerce conversations, but in practical terms, it means this: your team can manage the core data, logic, and operational rules in one place while still creating distinct buying experiences for different audiences.
A regional storefront may need different product availability. A customer-specific store may need vouchers. Another account may need ACH payment options, while another may use credit cards, purchase orders, or a mix of payment methods. Some stores may need special compliance attributes, age verification, unique shipping rules, or custom workflows.
In Znode, those entities can be configured centrally and applied to the appropriate stores, catalogs, accounts, and users.
That is very different from managing several disconnected platforms, each with its own admin, catalog, integration, theme, pricing rules, and development requirements.
From an agency perspective, we see this problem often. A business may have one brand running on BigCommerce, another on Magento Open Source, another on Shopify, and maybe a few custom or legacy systems in the mix. At some point, the business realizes that the platform sprawl is creating cost, complexity, and technical debt.
The goal should not be to keep adding more systems. The goal should be to simplify the architecture while preserving the different experiences the business needs.
Reducing Technical Debt Across Multiple Brands and Stores
Technical debt is not always visible right away. It builds slowly.
A company may start with one site, then add another brand, then acquire another business, then create a customer portal, then launch a regional site. Before long, the team is maintaining multiple platforms, multiple licenses, multiple ERP integrations, multiple front-end codebases, and multiple development skill sets.
That becomes expensive fast.
Tom made a great point during our conversation: one of the biggest sources of waste is duplicated ERP integration work. If six different websites all need to connect to the same ERP, you do not want six separate integrations doing essentially the same job. And if those sites also need to route orders to different ERPs, the complexity can grow into a spider web of middleware and custom code.
A multi-store B2B platform can help simplify that. Znode allows businesses to manage multiple stores centrally and route orders to one or multiple ERPs. It does not magically eliminate ERP complexity, but it can make that complexity much easier to manage.
That can translate into lower maintenance costs, fewer disconnected workflows, and less dependence on multiple specialized development teams.
Launching Stores Faster
One of the most compelling parts of the conversation was our discussion around speed.
I asked Tom what it would look like to launch 50 stores at once. It sounds extreme, but for some B2B companies, especially those running customer-specific programs, that is not far-fetched.
The key is getting the requirements right up front.
In Znode, teams can create a central theme with the attributes and functionality that different stores may need. Then, as new stores are launched, those attributes can be turned on or off depending on the requirements of that specific store.
That might include payment methods, catalog rules, customer-specific content, age verification, vouchers, custom product options, or other business rules.
Tom shared an example of companies that used to take months to launch a new store but can now do it in a day. In some cases, merchandisers or digital managers—not highly technical developers—can stand up a new customer-specific storefront quickly.
That changes the role of the commerce platform. It is no longer just an operational system. It can become a sales tool.
Imagine a sales rep walking into an RFP presentation and showing a prospect their own branded storefront, already populated with relevant products and purchase rules. That is much more powerful than talking abstractly about what the buying experience could look like.
Why Headless and API-First Architecture Helps
Another area we touched on was Znode’s headless, API-first architecture.
In practical terms, this makes it easier to expose data, add attributes, and support different front-end experiences without breaking the upgrade path or creating unnecessary friction. When a global attribute needs to be added across dozens of storefronts, the platform can expose that data through APIs so the front end can consume it.
From a development perspective, that flexibility matters.
Anyone who has worked with complex commerce platforms knows the pain of making a change in the admin and then wondering why it is not showing up on the front end. Sometimes the answer is cache. Sometimes it is an indexing issue. Sometimes it is one of many layers between the back end and the customer experience.
With a well-structured headless approach, the goal is to make data more accessible, more flexible, and easier to act on.
It does not remove every implementation challenge, but it can reduce friction and help teams move faster.
Supporting B2B and B2C in the Same Platform
We also talked about a common scenario: what happens when a company needs both B2B and B2C experiences?
That is increasingly common. A manufacturer or distributor may have contract customers, dealers, or wholesale buyers, but also want a public-facing shopping experience for consumers or smaller buyers.
In Znode, that distinction can be handled through catalogs, price lists, and account rules.
A public shopper may see MSRP pricing and a general catalog. Once a customer logs in, they may see account-specific pricing, a different catalog, different payment terms, or special purchasing rules. A buyer may even be able to move from a public B2C experience into a B2B onboarding workflow.
The important point is that B2C is relatively simple compared to B2B. A B2C experience is often one catalog, one price list, and one storefront. B2B introduces account-specific pricing, contract catalogs, approval workflows, payment terms, and more.
So if a platform can handle complex B2B scenarios well, supporting a simpler B2C journey within that same architecture becomes much more manageable.
Choosing the Right Platform for the Business Model
Toward the end of the episode, Tom made a point that I think is worth emphasizing: companies should not choose a commerce platform based on brand recognition alone.
There are well-known platforms that appear on almost every RFP list. Many of them are excellent platforms for the use cases they were originally built to serve. But if a company has complex B2B requirements, multi-store needs, account-specific catalogs, ERP integration complexity, or customer-specific buying experiences, the platform evaluation needs to go deeper.
The question should not simply be, “Can this platform do B2B?”
With enough time, money, and custom development, many platforms can be made to do a lot of things.
The better question is, “Was this platform designed for the way our business actually operates?”
That distinction matters. Choosing the wrong platform can lead to excessive technical debt, high ownership costs, slow launches, frustrated internal teams, and eventually another replatforming project a few years later.
“Make sure you’re not just buying a brand. You’re buying a product that needs to fit the specific use cases your business depends on, with as many native features and as much flexibility as possible.” — Tom Flierl, Chief Commercial Officer, Amla Commerce
At Human Element, this is exactly the kind of work we help clients think through. Whether a company is starting a new eCommerce journey, consolidating multiple storefronts, or realizing that its current platform is not keeping up with the business, the right discovery and platform selection process can make a huge difference.
Final Thoughts
The biggest thing I took away from my conversation with Tom is that multi-store commerce is not just about having multiple websites.
It is about giving B2B companies a better way to manage complexity.
Different brands. Different regions. Different customer groups. Different catalogs. Different pricing. Different payment rules. Different fulfillment needs. Different ERPs. All of that has to work together without forcing the business into a mess of disconnected platforms and duplicated effort.
For B2B organizations, especially manufacturers and distributors, the future of commerce is not one-size-fits-all. It is centralized where it should be centralized, flexible where it needs to be flexible, and built around the real buying relationships that drive the business.
That is why platforms like Znode are worth a closer look.
And if your team is trying to figure out whether your current commerce architecture can support where your business is headed next, Human Element can help you ask the right questions before you make the next move.
