Left headless?

Everybody is talking about “headless commerce”, the phrase used to describe the separation of front end and back end. It involves removing the head, i.e. the front end. However, we’re not talking about leaving the retailer headless, as the back end (e.g. ERP, CMS, CRM or a combination of these) remains in place. But this is complemented with flexible interaction opportunities by creating API interfaces.

An API (application programming interface) is a standardized interface via which certain content can be obtained. There are a number of prominent examples of API interfaces today, such as Google Maps, which are used to retrieve location-related information. An API can be used to transport individual data fields, texts or even images.

In “headless commerce”, the back end serves as an information base comprising a variety of data. With an online shop, this could be product master data, images and prices. Logistics information such as addresses, shipping options and collection points are also feasible.

The information contained in the back end does not necessarily need to be available internally to the customer. External API interfaces with information from business partners can also be part of the back end. Swiss Post, for example, offers corresponding API interfaces with the Digital Commerce API.

With headless architecture, front-end designers (i.e. all the elements the customer sees in a shop) don’t need to worry about database adjustments or rigid functionalities between back end and front end. All the information is available via the standardized API interfaces.

And this is where the major advantage to “headless commerce” lies. Based on all the information available from the back end, individual front ends can now be developed. These then meet a specific purpose or serve a particular touchpoint.

This could be a classic webshop. Or an app for the Apple Watch. The information used for a chatbot or the basis for a “smart button”. There are no limits to what can be done here.
This greater flexibility allows designers to take an approach consistent with customer requirements, on which the focus remains. Only the information required for meeting the respective customer requirement is used from the back end.

“Headless commerce” does involve greater IT effort though. The front end needs to be newly built for every purpose. There’s no finished shop website available, nor a smartphone app. This initially appears to be a disadvantage, but you actually get as-yet unmatched flexibility in digital commerce.

Companies who consistently focus on a headless architecture can respond very quickly to changing market conditions and new technologies. What’s more, customer data from all touchpoints can be bundled in the back end. This makes true customer centricity concepts a real possibility. The front end remains flexible, while the back end provides the necessary foundation and stability.