Headless commerce is rapidly gaining steam in retail, but there's still a lot of confusion around the concept. It seems everyone has a different definition.
At its core, headless is about separating the customer-facing experience from the backend systems, making them “headless.” But this can be a misleading term because there still needs to be a head — it just needs to be separated.
To help understand “what” headless commerce is, let’s come back to the “why” behind it, which really comes down to the customer. Customer expectations are evolving faster than ever. To move fast enough to keep up, the web storefront and all other front-end touchpoints need to be separated from backend systems so that they can evolve at different paces.
See also: 3 Digital Trends That Will Stick in the New Post-Pandemic Retail Landscape
Customer-facing front-ends need to keep pace with new trends in front-end frameworks, new interaction types, and nuances across regions and brands. Meanwhile, back-end systems need to evolve at their own pace to meet the needs of complex organizations looking to centralize systems and data for organizational efficiency.
Does it really unlock agility?
Some approaches that are defined as headless don’t actually achieve this goal of increased agility and customer-centricity. For example, a heavy digital experience platform (DXP) as the “head” to a headless commerce system won’t allow the front-end to evolve faster because the “head” isn’t lighter or more agile than the headless “body.”
Another scenario that often doesn’t produce the agility benefits that headless commerce promises is building the “head” from scratch. This approach doesn’t include the low-effort maintenance, resilience, support and compliance necessary for the team to focus on CX experimentation instead of web storefront or native app operations.
So how do you ensure an agile, customer-centric approach to headless?
A customer-centric approach to headless
The agility of headless commerce is predominantly realized by the benefits gained in the “head” — hence the confusion around the topic of “headless.”
To ensure a customer-focused approach, headless strategies should start at the head and work in. For most retailers who are still predominantly centered on web traffic, this means starting with a decoupled web storefront that addresses the customer’s needs first, and then adding headless back-end services to further enhance the experience. Because of the decoupled nature of the new architecture, you can iterate or migrate back-end systems with minimal impact on the new customer experience.
See also: The Most Reputable Companies of 2020 List is Sprinkled with Retailers
Here are 3 questions to assess if your headless approach is customer-focused:
Is there any cross-channel or shared functionality tightly coupled to the web storefront? If there’s any commerce or content management logic coupled to the front-end that would be difficult to reuse in another channel, then you won’t get the agility and flexibility benefits of headless commerce.
Is the presentation layer calling web APIs such as REST or GraphQL? The answer should be yes. A monolithic application can call APIs as well, but these will be internal APIs within the same application that aren’t easily accessible to other systems. In a headless environment, APIs would be called from external systems.
If you were to enhance a back-end system, would it require an immediate change to the customer experience? The answer should be no if it’s truly decoupled. For example, if you enhanced performance or added additional scalability to handle more concurrent orders, no front-end change should be necessary.