The Digitalization Complexities For Telecommunication Companies

The Situation

Software is eating the world and the trends for the global Telco business point towards software business models, aided by advances in AI. In fact, telecommunication services are more and more subject to global IT players, defining new standards for B2C and B2B communication on a global scale.

I will go into what general complications exist, take a special look at E-Commerce, Customer Service, Data Platforms. All of which are not the only concerns for any Telco company out there, however certainly important ones.

The Complication

Quicker turnarounds in Software Land

Time to market needs to shorten significantly with the aspiration to become a software company. That is true for the Automotive sector as I depicted in this TDWI Talk and is just as true for Telcos. Network technology roll-outs are a multi-year ordeal from 5–15 years and that’s what defined the pace of the industry in the past. Software cycles are much shorter, innovation in the software space in general faster. This is now true as well for the B2B space, where one or max two updates a year to the ERP were deemed acceptable. No more — driven by the need to support new products, services without standing in the way of Business with rigid deployment windows. The agile way of working revealed as well that companies releasing frequently build more robust, secure solutions, further diminishing the acceptance for old-way annual deployment plans. There is just not much upside to speak of.

Going faster requires different sort of guardrails

That said, releasing software faster and with certainty requires an organization to support it — and it needs to be rather self-sufficient as in applying DevOps paradigms and making coherent use of Continuous Integration/Development and its automation. Long-lived Network Tech roll-outs did not require any of that, so there is some significant change to be managed, adding to the complication.

Commoditization and the margins that go with that

Everything mentioned is reinforced by the facts as follow.

Telecommunication services are perceived as commodities. Customers will not change for the fun of it, but once they are lost it is prohibitively expensive to win them back. All the while customer expectations are increasing. Retention therefore is a costly concern.

One of the concerns in an industry space where margins among “classic” Telco players with asset heavy footprint are rather low. Spurred by the rise of new competition which is not limited to FANG but includes as well “Light-asset carriers”.

Light-asset carriers which provide services only digitally and have no stores, fewer field technicians and smaller call center functions. Utilizing AI for these (virtual) call centers as well for better automated (digital) marketing results in better cuts.

While asset-heavy Telcos reap lower margins, they still need to introduce new capabilities all the while transforming complex existing organizations on a global scale.

Another source of complexity stems from the fact mergers & acquisitions are common in the Telco space. Complexity, because all these independent organizations come with varying baseline architectures, founded on different decisions made in different contexts. Including business model variations. Which parts need to be brought to corporate “standard”, is it really worth doing so (and justifiable given the mentioned margin constraints)? These types of challenges do not offer any short-term top, bottom line benefits, still need to be dealt with in a sensible way.

Digitalization

For orientation, let’s have a look at what is meant by the term “Digitalization”.

Therefore, Digitalization is about efficiency, access and transparency — and a great leeway into coming up with new business models, taking advantage of “digitized information”.

To make Digitalization work, one has to acknowledge that the overall set of capabilities of the Enterprise is shared among different functions and groups, some on the Business end and some on the IT end, the latter empowering the business requirements. To that end, every capability and every domain you might consider entails stakeholders which need to be managed, from understanding the business needs to setting expectations right and driving informed decisions by leading with possible options, distilling data and make architecture options and their implications transparent. Enterprise Architects look at the Business Architecture and business scenarios help with getting a grip on the context, the intended outcomes. Modern architects stray away from the classic business scenario notion however and work in terms the Business is already used to as part of the transformation towards Agile (SCRUM, Lean, SAFE etc.), namely journeys split into customer stories.

Looking at customer stories is one of the methods of understanding business processes and therefore business requirements, along with already documented business processes of course and process mining.

Starting with the Business Architecture and the end in mind, involving stakeholders on various levels is critical for any Digitalization effort. Last but not least does Digitalization imply change and managing change properly is paramount for its success.

E-Commerce

The Enterprise capabilities aforementioned are not only useful for, simply put, providing a view on functions and concerns — they deliver as well a common taxonomy. Common among technical and business peers alike. This should be taken advantage of when communicating what E-Commerce is comprised of and what cross-dependencies there are. E-Commerce will tap into Business Capabilities the stakeholders are very well familiar with, no matter whether they have any experience with technical E-Commerce solutions.

Think of Procurement, Financial Processing, all sorts of ERP domains from Warehousing to supply chain management and so on. E-Commerce platforms, consisting of various tools and integrations, never exist in isolation.

When thinking E-Commerce platforms, rather think of a distributed portfolio of applications and functionalities and not necessarily of a singular application. These building blocks of the platform are not static, either — but progress over time. Are newly introduced, modified and overhauled, partially decommissioned. These building blocks are never on the same maturity level.

Which is at the core of impactful E-Commerce: Experimenting with functionalities, adding features and measuring their success, replicating what works and cutting out what does not. Technically, this would work by keeping those building blocks bounded and loosely coupled — with the help of an API 1st architecture. Microservices take this one step further by reducing the boundaries and decompose the architecture further, re-usable but not hampered by tight dependencies — allowing to achieve a much faster time to market compared to a (staged, maybe even only bi-annual or so) “deploy everything at once” approach.

This whole prelude on how to think about e-commerce platforms now does address some of the challenges mentioned earlier, compare the chapter about the complications.

• Decomposed, re-usable building blocks allow for better separation of concerns (compared to a rather monolithic architecture style), therefore less dependencies, therefore faster feature deployments, experimentation with new features
• Respond to new market / global economic climate developments faster by adding or removing services, products, etc.
• All of this works across any given channel, be it Web or Mobile or in the future virtual assistants like chatbots or smart devices — as the architecture style laid out is agnostic of the communication channel per design, which helps to keep the potential reach of the E-Com offering as wide and deep as utterly technically possible
• Meet and exceed growing customer expectations

For details on what an API driven platform blueprint may look like, please have a look at my open sourced API Assertion Map.

Some general questions apply for every solution and never go away.

For example, BUY or BUILD? The answer is not straight-forward. If you think about platforms, it’s not about whether you build one application from the grounds up yourself or buy it, but more about creating an ecosystem of technical services that constitute a digital platform. Even the current “off the shelf” e-commerce tool provider no longer pretend they would cover everything required for functional, effective e-commerce in a single application, as it might have been propagated many years back with Magento et al.

AWS describes the four fundamental architecture choices as far as E-Commerce goes as follow in their whitepaper on “E-Commerce Architecture for Retail”, which do apply for any other vertical industry as well however.

There is no right or wrong in terms of architecture, only “fit for purpose” — or not. However, given all I mentioned in terms of aspired benefits, API driven solutions look promising, so Microservices and Headless. COTS E-Commerce Suites would have to be designed API 1st, truly modular and easily extensible to fit the bill. At least I do not now of a single solution on the market I would attribute all of this without severe restrictions. Monolithic is almost 100% a no-go for a dynamic domain such as E-Commerce in 2021+, unless striking constraints exist — like the missing ability to handle the complexity and overhead that comes with a microservices based architecture, for example. Other than that, E-Commerce — no matter if B2C or B2B — is customer facing, directly value generating and literally impacting the top line. Therefore, it is hard to imagine a stale and static architecture style, which might be perfectly fine in other contexts.

And another consideration that does not go out of fashion — how do you evaluate one potential (E-Commerce) solution against another one?

Again, do not think of single application here but more of an ecosystem of applications as in a “platform” solution.

For that, what has proven working well is a mix of (1) weighted matrix with aligned key criteria, aligned among business and tech peers to be exact. And (2) applying a set of always relevant considerations I wrote an article about, including on IT security and data protection, how the solution would be operated and serviced and more.

As to the first point — those criteria would likely contain cost of ownership, upfront investments (CAPEX), how the different solution options fit the incumbent basic architecture principles and governance and more.

Note: I deliberately left out discussing how to deal with existing e-commerce solutions and consolidating these, how they would influence decision criteria for one solution option or another. There are too many different scenarios that might make compromises and tailor-made interim “transition architectures” necessary to paint in broad strokes. Imagine for example different E-Commerce tools co-existing as a result of M&As. Roadmapping towards a common target state would get complex.

Customer Service

Customer Service is part of every Customer Relationship Management (CRM), together with Sales and Marketing. It’s crucial for meeting the customer expectations and bad customer service is a reason to change and turn (churn). Why that’s a problem was already explained in the chapter about the complication.

What was explained there as well was that asset-light carriers do not carry the same burden for upholding customer service as more “traditional” Telcos do. The Covid pandemic made keeping up an acceptable service level harder, all contact restrictions and additional security requirements in full swing.

Self-service offerings were and certainly are valued by Telcos as well the customers who are not keen to call up hotlines in the first place most of the time. For these self-service platforms, ease of access across any channel, functional coverage and complete data coverage are make or break in terms of user acceptance.

Customer Service and Sales are closely affiliated, as every service touchpoint bears the chance of a service / contract upgrade. Welcome and rather rare opportunities to increase the low margins.

At the same time, every service touchpoint is a chance to prevent customer churn.

Therefore, the delicate truth is, that Customer Service is a cost driver just as well it is a vehicle to retain customers and potentially upsell offers. Ergo, the ideal target state is one that allows to “achieve more” with “less”. Less overhead, better personalized and relevant offers, at the right time. This is where AI will make more and more all the difference.

Use of AI

Both in E-Commerce as well as in Customer Service, AI can aid in various ways.

• Next Best Offers: Presented on-site or in service touchpoints
• Appeasement: Suitable offers to come to a positive resolution in cases of service or product issues
• Predicting Needs: Using signals from all sort of channels, owned and not owned like social, to anticipate need for services, products or rise of customer service cases
• Reduce time to resolution in customer service cases by offering AI induced self-service offerings like chatbots on site, phone bots that can simulate a person on the other end of the line and recognize speech, synthesize speech; cognitive search that is able to extract relevant information from all sorts of document types and relate them to each other (semantics)
• Reduce manual labour in business processes that require media breaks, for example from paper to digital and from PDF or image to database record, by implementing Document Understanding

And many more.

Finding out how exactly AI can help streamline business processes and unlock new potential altogether is not easy, but a method I studied and am a trained facilitator for is. It is called 33A Opportunity Mapping. Rest assured more potential can be uncovered using this approach, across different parts of the organization. Even catering for an agreement on priorities along the way, which is in itself a first great step towards a working Change Management.

Data Platforms

For machine learnings models to perform and live up to expectations, data needs to be available in the right volume, structure and quality.

That’s easier said than done, given the different concerns that need to be addressed by data processing solution building blocks. From purely transactional to dispositive and data ranging from historic to only milliseconds old, all depending on context and scenario.

As far as embedding customer related data into Marketing Technology and providing relevant, meaningful interactions with customers at any step along any customer journey goes, I wrote an article about the purpose of a Customer Data Platform (CDP) — which I will leave it at with this link. This document you are reading is getting lengthy enough as it were.

From Digitalization to Digital Transformation

As a closing remark, I would like to add that the API 1st architecture I mentioned throughout the different chapters opens up the chance for future co-creation and having third parties participate in the generation of new business models and offerings. To be more concrete, the already well-defined, well-documented APIs — could and should be layered into APIs of Engagement which would be open and system APIs which serve integration in the backend.

If well-designed and marketed, all kinds of value-add solutions could be built on top of those APIs, as I describe in my article series platformeconomies.com.

There is much more left to be written, however I hope this gives you a first impression of what the industry is facing. What do you think, what does the future bring for Telcos? What’s the role of E-Commerce, CRM and Data for Telcos from your point of view?

Stay safe.