How a Leading B2B Company Added Commerce to Their Digital Ecosystem

We talk a lot on our site about how to approach answering various questions faced by digital marketing and technology leaders today, like selecting a digital experience platform and navigating the myriad of options for commerce platforms in 2020. But we talk about this abstractly. There is also plenty to learn from real-life situations, from a case study approach where we look at a single organization solving a common, complex problem faced by brands today.

Let’s do just that see how a real company approached solving their problem, their considerations, and the ultimate platform recommendation.

The company: I can’t identify the brand by name, but a terrific mid-market product company of about 1,000 people, with both a B2B and B2C line of business, in the creative sector.

The market position: Several strong D2C brands and a B2B brand serving large enterprise customers only (full white glove, bespoke sales process).

The opportunity: There are two: 1) Expand their B2B offerings to mid-market companies. 2) Take advantage of a modern commerce platform for D2C brands to improve conversions and revenue.

The problem: There are two: 1) The lower annual spend of the mid-market customers the company wants to pursue (their average spend is ~$15,000 a year) means you can’t offer the same manual, white-glove sales process you offer to enterprise customers. 2) Development velocity is very slow on the D2C brands because the platform is fully bespoke, so everything has to be built from scratch.

The desired end state: 1) A self-service platform to support the sales effort to mid-market B2B customers, like upsizing, license management, and upsells. 2) A modern commerce platform to increase marketing and development agility on the D2C brands.

The current technology: Acquia Drupal for the brand marketing sites, a custom commerce platform for the D2C brands, and a mostly content experience built on Acquia Drupal for the B2B platform.

The process: OK, this is where it gets interesting.

We led an in-person whiteboarding session (remember when you could do that?). The first step was to map out every single property/brand. Next was to make a shortlist of the major, uncommon integrations. That means we don’t care about stuff like Google Analytics, that works everywhere, but do care about integrations with back-office systems like a custom ERP, identify management, and customer relationship management. There are probably about 10 of these that need to be identified. These are the major functional considerations.

Now the first crucial question: Is the commerce experience browse and buy, or not browse and buy?

Ticketmaster and JCrew are both big digital commerce experiences. But only JCrew is a browse and buy experience (think PDPs, coupons, and landing pages). Sure, Ticketmaster has plenty of commerce but the experience of buying tickets is unique: You almost always buy tickets to just a single event, the configuration of the venue can be different for every single event, you want to preview what sitting in that section will be like, you might be trying to buy tickets near friends, and on and on. Commerce is it, browse and buy it is not.

If you have a browse and buy experience, you need to look at a modern, third-generation platform. (We have a guide for that here.)

If you don’t have a browse and buy experience you probably need an API-driven experience. Why? Because trying to force a modern commerce platform like Shopify Plus or Magento into being a non browse and buy experience is going to take a tremendous amount of custom development, which dramatically reduces the value of going with an out-of-the-box platform.

Think of it this way: Every browse and buy store is more similar than dissimilar every other browse and buy experience. non browse and buy experiences are just the opposite, they are less alike each other than they are alike.

Our brand had both experiences: The D2C channel was absolutely browse and buy, your standard approach. But the B2B platform wasn’t browse and buy. That was going to be about license management, buying more seats for your application, and self serve options. The B2B platform would probably have five SKUs on the launch day, and five SKUs three years from now.

This simple question is this, browse and buy or not, means that our brand needed to find a strong browse and buy platform to power their D2C brands, but that also had strong API capabilities so the B2B commerce use cases could be developed (they were always going to be custom anyway).

The second crucial question is: Should this be side by side or headless?

By this we mean: Should the commerce and content platforms each serve different parts of the experience, or should one server all parts of the experience and the other should simply respond to API calls from the main platform?

To answer this question we have to return again to whether your experience is browse and buy or not. When your experience is browse and buy, headless becomes exceedingly expensive because you have to build every standard commerce experience (PDP, cart, checkout, etc) completely from scratch. Why? Because the dirty little secret of headless is that most customer-facing experiential extensions available on any given commerce platform are not compatible with headless.

The answer is now obvious as what our brand should do: The B2B experience, which is not browse and buy, should be headless, while the D2C experiences, which are browse and buy, should be side by side.

The great news is the brand is using Acquia Drupal today, and that platform works great for anonymous and logged-in content experiences. Acquia Drupal has a strong API framework for building custom experiences, so it would work great as the foundation of the B2B platform. But it doesn’t have commerce. For that, you have to integrate with a commerce solution.

The solution: So Acquia Drupal is a great option for the B2B platform coupled with a commerce platform in a headless configuration. And the D2C brands need a side by side approach, using Acquia Drupal for content experiences and a commerce platform directly powering all of the commerce experiences./p>

By asking two fundamental questions and following a clear process the brand confidently answered the major question of what kind of architecture they needed for their complex needs, to support the business with expansion well into the future.