Automation is key to reducing costs, enhancing efficiency and eliminating siloed, serial processes. It will take a long time, but the key is identifying building blocks – and one key building block is at the heart of both network and service automation. Let’s focus on customer service handling.
One of the key issues driving operator transformation is the shift towards more automated processes. Of course, to achieve this, different systems need to be integrated, so that activities and processes can trigger actions and activities in other, related processes, ensuring a seamless flow.As STL Partners , a consultancy firm, notes, progress towards automation is being driven incrementally, via what it terms the “building block strategy”. We’ll explore various aspects of this in future posts, but let’s echo this message and start from the beginning.
Put simply, the building block strategy basically means that different processes need to be viewed and examined as candidates for automation. As each step is taken, newly automated processes can be further linked to others, and so on. This will take time, but the report notes there are two key areas that are attracting considerable attention: network and service operations:
Of these, it is network operations that is attracting the most attention, as Figure 2 from the report indicates:
We’ll return to network operations in the future, but while service operations are reckoned to offer less value in the near term, we think it’s really rather important. That’s because customer acquisition and retention are critical activities for any operator – so enhancing the processes that support them must be a focus for action.
So, with that in mind, let’s think a little about the customer journey. First, let’s take an existing customer that qualifies for an update or whose contract is reaching its end. In both cases, a trigger should be generated in the CRM, indicating that some actions need to be taken. The nature of that action will depend on the policies of the operator concerned, but may include:
The response (or lack of) to the resulting actions should also trigger responses – in a workflow. Already, we have a logical flow, with checkpoints and event-driven activities, while null responses will also generate new actions. So far, so familiar. This is the beginnings of automation and most operators have some sort of enhanced CRM or BSS solutions that can support it.
To bring this in line with the direction suggested by STL, we need to go further and request information from other systems. It’s fine to offer an upgrade, but can that upgrade be delivered to this specific customer? At this point, the BSS needs to request and obtain information from OSS components. And – you can see where we’re going – this means that accurate data regarding the available resources must be available, so that it can be furnished to the requesting process.
The same is true if a contract is reaching its end. The operator may use propensity modelling to determine the likelihood of churn, but however cleverly these processes are designed, they still result in the same need for information regarding the products and services consumed, their status, and the availability of new alternatives.
In other words, the CRM and customer provisioning systems must be seamlessly integrated with the relevant OSS assets that can provide the information they need to manage subscriber services and to generate new orders. These know who has what, but it is the OSS that really knows where – not just in terms of the customer location, but the location of every element involved in the service chain.
To ensure that this works seamlessly – and that future automation building blocks can be joined together – the OSS needs to maintain a single source of data regarding network resources and services, their location and availability, that is available to any process from the BSS or from other OSS solutions – and, in the context of service operations, this means the CRM and customer provisioning systems.
But, we’d go further. Even very basic automation cannot deliver the expected benefits without this resource – and more ambitious programs are doomed to failure if this issue is not addressed, because automation will become increasingly complex.
STL is right to break things down into manageable steps and to advocate a building block approach. And, API integration between processes will deliver much. But for efficient automation, the least number of API requests should be made and, as such, there is a fundamental building block that is foundational for all future automation activities, whether for network or service operations.
This building block is the single, comprehensive network inventory that can serve all requesting processes (from the CRM and elsewhere) and provide the data they need to understand resource availability, location and capacity.
CROSS fulfils this role in a growing number of networks, bringing together business and operational systems to accelerate automation and enhance service delivery. So, before you accelerate automation efforts, talk to our team and we’ll show you the key building block you need to drive your program.
STL Partners: “Prioritising automation – creating a successful building block strategy”, March 2021