[Part 2] Delivering a Unified Omnichannel Experience using Headless Commerce
Written by Roberto Thiele — CTO at AMARO
[This is the second part of a 2 part series, you can find part 1 here]
Part 2 — Unified Omnichannel
Unified Experiences with Headless Omnichannel
In true Headless, platforms do not render HTML or process HTML forms — the JSON API is all that the platform provides and any UI must use it — there’s no alternative. This approach, which is also known as API-first or API-only, enforces the need for every single feature to be available via API. In contrast, on hybrid platforms, using the API is *optional* and thus ends up being considered only a nice to have add-on for attaching additional systems or user interfaces to the platform; as a result, it very rarely exposes every single feature that is already present via the main website and over time with the need to add new features to the website, it also becomes outdated.
What does a unified experience mean exactly?
Let’s consider that a B2C business offers various possible transactional actions (T1, T2, …, Tn) to its customers through various different channels, such as placing an order, returning an item or requesting assistance via email. Each transactional actions may be broken down into atomic steps, such as adding an item to the cart, saving something to the wishlist for later, selecting an item to be returned without concluding the process, selecting a payment method, etc. In order to complete any action T, all its steps S must be performed in sequence.
We may say that a unified and seamless experience exists when the customer is able to perform any of all available transactional actions (T1, T2, …, Tn) by completing its atomic steps (S1, S2, …, Sn) through different channels (C1, C2, …, Cn). For instance, a customer may start an action T1 (which has 4 steps) by completing steps 1 and 2 through channel C1 (e.g. website), and conclude the action by completing steps 3 and 4 through channel C2 (e.g mobile app). Here are some examples:
- A customer adds two items via mobile app, and later from home accesses the website via desktop, adds a third item and on the next day completes the purchase via mobile app
- A customer initiates a return process via mobile app, brings the item to a physical store and concludes the process there through the POS system
- A customer adds an item to the wishlist, goes to a physical store, identifies herself via POS system, and is able to easily conclude the purchase of that saved item
Headless on Physical Stores POS systems
At physical stores, the Point of Sale system is usually connected to the on-premise ERP, and if a customer may want to use say, a promotion coupon code (that was received via e-mail after having visited the website) at the store, the ERP would have to contain exactly the same configured promotions as the website, which may be achieved either by a manual process of configuring promotions on both the e-commerce platform and on the ERP, or via a systems integration between both. Also, if a customer may want to buy a product that was seen online but is not available at the physical location, the product catalog in the ERP must be in sync with what is available on the website. These systems integrations can be complex to develop and difficult to maintain (it is said that a simple systems integration is almost always an oxymoron). A simpler solution is to have the POS system connect directly (as in online/real time) to the e-commerce platform, as a thin client user interface, so that all promotions and products seen on the POS are the same as on the e-commerce platform. With a Headless e-commerce platform and a POS made to connect to such platform as a thin client via API, this should be more straightforward than having to develop and monitor a systems integration between the e-commerce platform and ERP/POS.
Headless on Native Mobile Apps
Headless on mobile apps is straightforward because that’s how mobile apps work by default. In any native app, the overall layout of the app is already built into the application, and only data (usually JSON) is exchanged with the server. While it is possible to have apps render HTML or even have a web browser built into the app (with Web Views), the overall resulting responsiveness is not ideal and actually defeats its whole purpose. That said, there are plenty of mobile apps that just load HTML from the server through webviews, not only because it’s much faster and easier to implement, but because oftentimes the platform is not Headless, and the API-based native mobile app approach isn’t even feasible.
Headless on Marketplace Websites
Headless on Marketplace Websites is conceptually possible, but practically nonexistent. It could be possible if the Marketplace were able to connect to the vendor’s e-commerce API in real time and thereby replicate the vendor’s experience (promotions, search, shipping options, etc). However, it’s usually so that the Marketplace only provides a syncing API so that vendor may continuously sync products into the Marketplace, and read placed orders from it. It’s understandable, since that approach is much more scalable to the Marketplace, and it’s of its best interest to provide a unified experience to the end customer, and not a different experience for each listed vendor. In that case, a Marketplace cannot be considered as part of a truly unified omnichannel architecture, but it is nevertheless a very strategic additional channel for any vendor.
Putting it all together: A Unified Headless Architecture
Headless brings the freedom of having multiple heads (front-ends), each being custom made for a specific audience. Because all front-ends use the same API service layer, the result is a consistent and unified user experience across all channels.
An alternative approach: Integrated Distributed On-premise Platforms for Offline Experiences
One obvious drawback of the Headless approach is that all user interface clients (or front-ends, thin clients, etc) must have access to the internet at all times. The communication with the API happens in real time and since the server resides on the cloud, an internet connection is always necessary. This pitfall should become of lesser importance over time as the internet becomes omnipresent and all devices are always connected. But what if we want to reach out to customers where internet is not readily available or not very reliable? One possible solution is to have the front-end running on the client’s device to be a bit more than just a UI — it would have all minimal necessary functionality to close an order. Such front-end platform should have a data store to be able to hold all products, promotions, etc, allowing the person using it to place offline orders. The orders would then be synced with the cloud platform (along with product prices, stock, etc) as soon as an internet connection would become available. If processing payment on-premise is necessary, it could be solved by transacting via cash or via a mobile network connected pinpad. We gain the ability of placing offline orders at the cost of having eventually consistent data, meaning that there’s no guarantee that the order will be able to be fulfilled (since we won’t necessarily have the most up to date stock information at the closing of the order).
Extending Headless Commerce Functionality: Custom Features and SaaS
Headless really shines when it comes to extending functionality, because any new feature just needs to be developed once on the main platform (and of course exposed via API) to become instantly available for all front-ends to use it. In contrast, the traditional full-stack approach requires the new feature to be developed on every single different platform. With Headless, the UI for it needs to be developed, which may not be a trivial task, but it’s still much less complex than having to develop the whole feature from scratch on every full-stack platform.
Extending the platform’s service layer (available APIs for front-ends) may be done via a more monolithic approach (extending the current services behavior), or by spinning up more decoupled and independent services that provide very specific and composable small services, also known as microservices. Before going either route, just be sure to know the pros and cons of each, and for further reading, one cannot go without recommending Martin Fowler’s excellent materials on the topics. Also, when extending systems, be it through object-oriented monolithic extensions, network-dependant microservices or third-party SaaS solutions, it’s always a good idea to keep things as simple as possible (if there are many ways of solving a problem, use the simplest approach first and add complexity after, only if really required), and continuously refactor, review and simplify the extensions and systems integrations (by employing an Enterprise Service Bus for instance), so as to not see yourself in extensions hell and spaghetti integrations land after a while.
Another way of extending a Headless platform is through third-party SaaS solutions. For this to properly work with Headless, the SaaS needs to have a front-end API (preferably, API-only) and in most cases, also a back-end API to sync data between systems. The front-ends in this case need to be adjusted to connect to these third-party APIs in addition to the standard platform’s API. Such extensibility is very useful in cases where the newly provided functionality by the SaaS is very independent from any other functionality in the main API (otherwise, if functionalities are dependent on each other, it’s more difficult for the front-end apps to correctly orchestrate API calls and use the feature correctly), and adopting this approach may save a lot of effort and time.
Headless Commerce at AMARO
At AMARO, we have three customer facing applications: an iOS app written in Swift, a Android app written in Java, and a web app written in JavaScript/React. All are connected to headless platforms, as illustrated below.
