What we learned from designing a multi-channel sales platform in the telecommunications industry

While omnichannel premise as a concept seems quite straightforward, many tough business questions arise with new possibilities. It’s better to have an answer to them before starting implementation, as modifying established business structure and backend processes (for example, logistics or finance) is a non-trivial matter and usually takes longer than planned. Below are typical key business topics related to omnichannel sales that should be resolved early in the project.

Who in the organization will be responsible for centralized omnichannel platform configuration and development as previously separate channel departments will have to agree now on common policies? Regardless of the specific answer, a single platform is more difficult to manage by a team of multiple channel managers. From the technical side, there should be strong architecture governance to avoid growing redundant functions but still making it possible to develop and deploy the system according to each touchpoint specific needs and a roadmap. Otherwise, the new solution will be treated as a roadblock instead of an enabler.

A convergent multi-product cart usually raises several interesting design questions. A common case is ability to order a bundle of services and products where some might need installation services, while others require a visit to a physical shop for pickup. Such orders start as a single cart, with possible special aggregate discount pricing but need to be split into separate suborders and finalized in different ways, usually in different backend order management systems. This complicates the logic of customer order processing - as any problem with partial suborder could create technical headaches. How to deal with the total discount already given to the customer in one billing system, when one of the suborders was cancelled? The cost of manual resolving such cases should be considered, or automated process designed. Another example of complication when ordering multiple types of products together would be allowing even different payment methods, which complicates order capture logic even further.

The cost of implementing such a full-fledged multiproduct cart must be considered, as the unavoidable system complexity could outweigh the benefits. The advice here would be to validate first if customers actually need and will use all of those options in one flow and if this will bring real value.

Another good example of the omnichannel-related complexity is commissions from sales - especially those orders that are started in one channel but finished in another. Such rules can be difficult to understand for sales staff and translate into technical question of how to trace the flow of cart that was suspended, resumed, and products added in different channels, to provide meaningful reports for commission calculation rules. Again, before starting to develop a custom system and logic, it’s better to validate the number of such cases and consider whether simpler rules could be implemented to avoid some problems altogether.

All of the above seems obvious in the hindsight, however, when starting a major, ambitious programme, many such questions arise, and without a strong architecture oversight, hasty decisions taken at the concept stage turn out to be very costly later. The value of all omnichannel features should be validated and discussed by Product Owners before starting the implementation.

The product catalog is probably the single most important factor for any successful eCommerce transformation, as it provides the foundation for all commerce features built on top of it. There are usually several design aspects that need to be addressed:

• Multiple product lines with different configuration models

• Integration and mapping of existing billing services and products from separate systems into one single sales catalog

• Different pricing algorithms per product line and a wide range of price types and discount types

• Complexity of configuration vs fast time to market and final solution performance.

Providing multiple product lines on a single platform consisting of complex bundles of telco subscriptions, devices, VOD packages, and other VAS services, requires usually going beyond existing baseline commerce platform capabilities, and may require implementing a dedicated product catalog solution. The customizations have to be designed in such a way as to not block the system's future upgrade path. Companies that simplify their offering – by moving away from complex, perplexing offers to the simple ones, will have a much easier life.

The integration of a sales product catalog with sources of configuration – like existing CRM or billing systems, means a clash of two completely different worlds, marketing vs. billing. Mapping different models to a common one that will be further enhanced with marketing information is a delicate task. Cable TV providers, in particular, usually grow by acquiring smaller competitors and grow a messy architecture with technical debt, with each catalog and product defined differently. Having many different models and complex pricing algorithms increases overall complexity and impacts final performance when trying to present a list containing different types of products, for example.
One way of mitigating this legacy complexity problem is on the business side to try to cut down on the number of possible offer models and effectively push for migrating customers to new, simplified offers, thus reducing the overall system complexity. This can be, of course, difficult for the marketing team to accept.

Frontend architecture

Despite marketing claims, it’s hard to find an e-commerce solution on the market that provides ready, out-of-the-box interfaces of all sales channels in an integrated manner. Most of the existing solutions are actually targeted for one or the other and require a major customization effort. What should be taken into consideration when building common frontend architecture is how many interfaces of employee-facing channels like POS, call center, and customer (eSHOP) will be similar.

Smart components design

To create a central platform supporting numerous processes, we started by identifying parts of customer journeys that are common to all channels – for example, product search, cart or consents gathering are almost identical in all touchpoints. In the next step, we designed the new flows around those interaction points. The goal was to create reusable interaction parts consistent for a customer while still enabling flexibility of having specific forms and actions required by each product line.

In the beginning, the idea to reuse common elements everywhere and use a common frontend codebase may seem reasonable. However, it turns out that customer-facing touchpoints change much faster than the sales-facing ones, and this means a somewhat different and more balanced approach. In the long term, it’s better to treat the development of those touchpoints separately and benefit from the headless approach, which allows for better, clean, separated frontends development, although still based on common underlying API.

For a true omnichannel commerce platform, a well-thought-out API design is critical, which then can be reused by future sales and self-service interfaces like mobile apps, conversational chat clients, signage, voice etc. An API based on industry standards like TM Forum should be used - not only will it decrease the design and integration effort, but provide a good architecture foundation.

Scaling UX design

Too often, development needs to wait until the whole UX design is completed, verified, and approved, or the created UX design is not technically feasible, performant or compliant with legal rules or accessibility requirements. In large-scale projects (upwards of thousands of wireframes), a systematic approach is required, as sheer complexity, size and communication challenges can derail the whole project. The pure agile approach, where each channel would be designed separately by a small team, will also be difficult in practice since such a gradual design would mean that each channel would become completely different, with no cost reductions.

To streamline the design process, in our case the team started with an agreement on key assumptions and design rules, from which further detailed system design followed, to allow for parallel implementation works to start, without fear of making changes later. The first design product was a prototype of selected omnichannel flows, which was extensively verified with users.

As the next step, interactions were analyzed for product lines across all channels and processes to prepare a flexible design system based on reusable atomic components. This reduced the implementation effort, and kept the overall consistent user experience across touchpoints while still allowing for individual brand differences. The challenge was to design a consistent visual language, as a customer could order several different items - a mobile handset with insurance, an internet subscription or an energy tariff in one cart while being presented with the benefits of such a bundle. Such products needed to be presented in a unified fashion in the order capture process.

What I see as crucial in such large projects is to keep the core design team not too large and include experts that possess broader skillsets – have both knowledge of the technical system, and understand equally well CX and telco business aspects. Knowing multiple domains – like telco offerings, e-commerce legal aspects, and accessibility compliance – translates directly into better product quality and faster progress with less knowledge transfer overhead. It’s always better to avoid a disconnected design team that is separated from delivery and product configuration teams – this creates miscommunication and costly mistakes, where ideas that seemed great on wireframes need to be revised later and redesigned, as they become too complex for end-users to understand or manage.

Last but not least, a key success factor is the experienced product manager who is motivated foremost to deliver a working solution first. He must be willing to accept the fact that the initial iteration of the product might be incomplete and require gradual implementation, as opposed to pushing at all costs for all possible options available at the system start.

Designing a truly omnichannel platform in telecom requires a substantial effort by an experienced, interdisciplinary team. Benefits can be huge, but getting all aspects right from the beginning is actually pretty difficult, that is why it is better to expect and embrace changes, rather than hold on to the initial vision. Achieving great customer and employee experience requires hard decisions from various business stakeholders, as it is not just another IT system implementation, but a business transformation, where the actual technology used has a secondary role compared to design decisions.