To achieve the ultimate goal of a functioning service delivery ecosystem (one that’s free of manual and redundant work) successfully integrated ticketing tools and processes are essential.
What’s more, organizations should be free to use the tools that they’re used to and to work with the processes they already have in place — instead of changing their way of working to suit the integration methods. When this is achieved, companies can quickly start collaborating instead of wasting time on creating new processes, implementing new tools, or maintaining technical solutions.
Building integrations typically takes around 3-9 months, which leads service providers and their customers to continue to swivel chair or double key — instead of opting for fully fledged enterprise-grade integrations. Some processes have been either too cumbersome, time-consuming, or expensive to create for service providers to onboard a new customer. Automating the most crucial service processes shouldn’t be a project that takes many months (and drives both parties insane!).
In this guide, we’ll outline why communications service providers and their customers benefit from creating a connected service architecture — and in the end, we’ll explain how they can create it with ONEiO. (You can also download this article as PDF here)
Who will integrate and who will adapt?
It’s becoming increasingly tough for telecommunication service providers to differentiate their services enough to set themselves apart from competitors — simply providing fast connectivity and good up-time doesn’t cut it anymore.
Service providers need to work more efficiently than ever to keep up with increasing customer demands, and to ensure they offer their customers the tools that enable seamless collaboration. While service providers are facing an unprecedented and unavoidable skilled resource shortage, the incidental benefit is a more concerted effort by providers to automate.
But there is a catch: the same talent shortages that drive automation are the ones preventing companies from adopting emerging technologies. In fact, a 2021 Gartner survey found that executives “cited talent availability as the main adoption risk factor for the majority of IT automation technologies (75%) and nearly half of digital workplace technologies (41%)”
Let’s dig a little deeper into the traditional mode of operation, the pain points, and how the telecommunications industry can shift towards the new way of handling service integration.
Traditional way:
Traditionally, the supply chain between the end customer, enterprise IT department, service provider, and communications service providers are siloed within each organization's borders. Each party uses their own portal or tool, then hopes the other parties will adopt it. From there, the communication is mainly over email between the parties. In some cases, if the IT department doesn’t have its own portal, the end user will use the service provider's portals or tools to communicate.
For end customers, the expectation is that their problems are solved in a timely manner, and without frustration. On the other hand, the service desks are required to work within the limits of SLAs and OLAs — in other words, they need to be able to deliver the services within agreed timelines and quality.
For example, when an end user submits a trouble or order ticket, the IT department will deliver a notification to the end user confirming that they have received the ticket. If the service desk cannot resolve the ticket themselves, they will simply forward it to the service provider responsible for the particular service. However, the end customer will only have received the first confirmation email, and thus lacks visibility on the ticket status.
Pain for the end customer:
Once the end customer has created the ticket, they naturally want to be informed about the progress. In the traditional way, the end customer needs to visit the portal, email or call the IT department to ask for updates.
Pain for the service desk:
The process is not only frustrating for the end user who needs to contact the IT department and ask about the status of the ticket, but also for each service desk since they need to email or call other vendors for ticket updates. These actions waste company resources on processes that could be automated.
On the other hand, when one of the parties needs to notify other vendors and the end users about a service outage, they need to notify everyone separately. And in the worst scenario, send the notifications to a dedicated email address — where it might get lost in the sea of email notifications.
The new way:
If all the parties throughout the service delivery supply chain would be integrated, the tickets would flow between tools and adapt to the processes of each party. The ticket status would be updated across the chain and enable companies to work efficiently together in a connected service architecture.
This way, all parties would avoid frustration originating from lack of transparency and the endless emailing and calling to figure out the ticket status. Everyone can work with their own processes and choose how the other companies' processes adapt to theirs. A connected service architecture leads to more efficient and satisfied service desk employees, happier end users and enables scalability by not making IT the bottleneck of business growth.
Three specific areas where communications service providers and their customers would benefit from a connected service architecture:
- Customer trouble ticket to the service provider
- Customer order to service provider
- Service provider notification to the customer
Scenario 1: A customer sends a trouble ticket to the service provider
Traditional way:
Let’s say the end user notices their internet connection is down. In most cases, the customer would report the issue by either creating a ticket in their own IT department’s tool or using the service provider portal.
Picture: The traditional mismatch of ticket process updates between the service provider and IT department.
Pain for the end user:
When the end user submits a trouble ticket about the internet connection being down in the service provider’s portal, the IT department is not involved in the process, even though they are still responsible for delivering the service. When asking for an update on the ticket, the customer usually starts from the IT department service desk, which needs to contact the other service provider’s service desk to have the information. On top of that, they will need to use one another portal that is different from their own IT department portal. See where it can start to get complicated?
Pain for the IT department:
Further, the IT department making sense of the SLAs will not have visibility of the process — because the ticket was submitted to the service provider’s portal. This also causes manual work for the service desk the IT department is contacting and thus reduces their productivity.
The new way:
Ideally, the end user could continue using their own portal or any other tool to create the ticket regardless of who is providing the service, instead of using multiple different portals. The incident ticket is automatically created and brokered to every party who is involved as defined by the process flow on time and with the right information. The customer stays informed throughout the process about the ticket status and neither the IT department nor the service provider needs to manually communicate about the ticket status — it would all be updated automatically.
Picture: Ticket status is bi-directionally updated between the end user, IT department and service providers.
Scenario 2: Customer creating an order to the service provider
Traditional way:
When an end customer needs to order, for example, a new iPhone, they usually fill an order ticket or order form on the service provider's own portal. Quite often, the customer also needs to use several other portals to order items from different service providers.
Picture: End user using different portals to get an order in place, thus the process is scattered between different service providers.
Pain for the end user:
In the order process, you will need to have other related products added to the order such as SIM cards and covers, but you also need to have a way to deliver the phone to the employee. All the parties involved in the process need to be informed about the order to trigger a set of other processes on their end. Due to separate systems, customers and service desk agents lose track of the orders.
Pain for the IT department:
For the IT department to manually make the orders with every vendor and stay up to date with the process is a nightmare. If a company is hiring 100 new employees per month, this kind of IT process can become the bottleneck for business growth.
The new way:
In a connected service architecture, transferring the information is transformed from the service provider and customer portal towards the order management system and again to all the related parties. The order process can automatically fill in the related orders for other vendors and update the status of each order on the same order. This way, everyone stays up to date with the process without the need to communicate with the other vendors.
Picture: End user using one portal to make an order and the process is triggering the service provider's own tools and processes.
Scenario 3: Service provider sending a notification to the customer
Traditional way:
When an IT department starts receiving multiple tickets related to similar issues, they are usually concerning one bigger issue. After they have noticed the issue, they need to notify the end users and all the concerned vendors separately. Also, if the service provider notices an issue with their services, they would need to notify all the related customers about it.
Picture: Service provider sending a notification to the customers.
Pain for the service provider:
Once the service provider wants to notify all the customers about the shortage and the process of solving it, they need to answer all the tickets and notify the related vendors separately. Also, when the service provider wants to send out notifications to other vendors, their dedicated email folders are full of other less relevant notifications and in the worst scenario, the notifications go unnoticed. In this mode of operation, the most critical time (the time immediately after the issue is raised) is spent communicating about the issue — and not on solving it.
The new way:
In a connected service architecture, the IT department can create a mother ticket to their own and to the related vendors' IT systems. From there, they can start clustering the child tickets under it. It can also notify all the relevant vendors relating to the issue and automatically create a mother issue to their systems even if the systems are using different tools and processes.
This way all the tickets can be updated about the process at once and remain transparent. The main thing is that everyone can decide the format of the notifications they receive and tailor it to fit best to their process so that everyone avoids notification spam, yet stays flexible towards other vendors.
Picture: Service provider sending a notification in a Connected Services Architecture and triggering relevant processes in the customer's tools.
How to build a connected service architecture with ONEiO
Leading up to Digital Transformation World 2022, ONEiO worked together with Accenture, Ericsson, Telia Company, ServiceNow, AT&T and TIM to create a connected service architecture solution based on TM Forum’s Open APIs.
The solution allows enterprises to more easily complete processes such as product ordering and service assurance such as Incident, Problem and Change. And for service providers, it helps them adapt to the new way of service delivery.
In the next section, we’ll dig into the technical aspects of how service providers and their customers can create and use a connected service architecture with ONEiO.
Picture: Connected Services Architecture as presented in the TM Forum.
One central hub to connect your tools
ONEiO has an out-of-the-box ability to communicate with most IT tools, and we built the platform to understand the various processes and mechanisms that are intrinsic to those individual tools, whether It's ServiceNow, Jira or BMC Remedy or any other tool. This means that much of the work that goes into a traditional ITSM integration has already been pre-built inside of ONEiO.
The difference between ONEiO and many other traditional integration platforms is that with ONEiO you're actually connecting your systems to the central ONEiO hub. This means that there are no point-to-point integrations, but instead, ONEiO acts as a smart integration broker between the different systems.
Picture: ONEiO user interface, which works in any modern browser, illustrating how ONEiO works as the central hub between your ITSM tools.
Easily modify and develop integration rules and mappings
The basic integration configuration in ONEiO consists of endpoint types and routing rules. Endpoint types are connectors that are either built to match the needs of a specific tool or, in the case of service providers, the whole set of exposed services that the service provider wants to offer to their end customers.
Endpoint types are also where different authentication methods to specific tools and APIs are managed using routing rules, and on the other hand, are a representation of the actual use case and logic that determines the rules of integration.
Routing rules are also the place where value transformations and mappings are done. This is the layer that anyone using our solutions will be able to access and easily modify and develop the integration rules and mappings further.
TM Forum Catalyst project-specific endpoint types for Communications Service Providers
For this Catalyst Project, we've worked on creating specialized endpoint types that meet the TMF 621 and TMF 622 API specifications and standards. This means that if you as a service provider have built your APIs according to these TMF specifications, we already have the building capability to consume those APIs within minutes.
If, on the other hand, you don't have APIs based on the TMF specs, we can simply connect directly to your ITSM tool and make use of the same capabilities without any hassle. Next, have a look at the endpoint type configurations for the Catalyst project.
Picture: Three different endpoint type configurations in ONEiO user interface.
Endpoint type 1: Transferring orders and trouble tickets
The first endpoint type represents the large enterprise customers, in this case those who are using ServiceNow. This endpoint type is used to transfer the orders and trouble tickets that the customer would be sending over to the CSP. The authentication and entity types are then configured in the main endpoint view in ONEiO, which you can see in the image below.
Picture: Endpoint type 1 configuration view in ONEiO. Including the URL to the ServiceNow instant that we're using for the customer and the authentication username and password.
Additionally, this view shows the entity types that we've configured for this endpoint type. Altogether, we have change requests, CSM orders, CSM order lines, incidents, problems and Service requests. These are all simple configurations where we essentially tell ONEiO what type of fields they should expect for each of these entity types.
Picture: Configurations for different entity types illustrated on ONEiO user interface.
Endpoint type 2: Handling trouble and proactive tickets
The second endpoint type is one that represents the CSP Service desk. This endpoint is used to handle the trouble tickets sent from the customer, but it can also handle proactive tickets from the CSP and relay those to the customers — the ITSM tool.
For example, if the CSP recognizes that there is a service outage, they can create an incident and push it to the customer for the customer to react and mitigate the issue. And for this endpoint, it's the same setup. We have the URL to the CSP’s ServiceNow instance, as well as the authentication and user credentials, as illustrated in the picture below.
Picture: Endpoint type 2 configuration view in ONEiO.
For the entity types, they're a little different since for the CSP, the entities we're working with are Case Change Request, Incident, Problem and Service Request.
Endpoint type 3: Routing customer device orders to the order handling system
Lastly, we have the CSP order endpoint type, which is used to route the customer device orders to the order handling system developed by, in this case, Ericson. Again, it’s a similar configuration, with a slightly different view due to different authentication methods. Here, the URL, the Owl credentials, and entity types, which in this case are only orders since we're only dealing with orders towards Ericsson.
Picture: Endpoint type 3 configuration view in ONEiO.
No need for traditional configuration work
The power of ONEiO lies in its adaptability. Our platform converts any payloads that we receive into a generic ONEiO data model, which means that we don't care in what format your tool speaks in. This also means that no data model transformations need to be configured, and the actual integration rules can be easily reused since they're not tied to a specific data format.
Conversion of data into the outgoing payload is then similarly as easy —and you can likely understand how much of the traditional configuration work is taken away by this way of handling data. Next, we’ll take a look at the messages view of the ONEiO user interface.
Picture: ONEiO messages view.
On ONEiO messages view, we notice that we have a new order from the customer side. Basically, we get an inbound message from the Customer's ServiceNow, and what is recognized is that we're talking about a new device order issued by the customer. We then automatically parse the incoming field values, and after that, they're readily available as generic input values for ONEiO to use and map forward.
Then, we create the correct outgoing data payload that corresponds to the TMF 622 standard and pushes it forward to the TMF 622 API that Ericsson has set up for their order management system. On the left of the image below, you can see the incoming data payload, and on the right the outgoing data payload.
Picture: New device order in ONEiO messaging view. Incoming data payload on the left and outgoing payload on the right side in the ONEiO messaging view.
When looking at the details, we can see that this is the actual JSON payload that we're sending over to Ericsson, and it matches the TMF 626 standard and specification.
Picture: JSON specification illustrated in ONEiO.
If we then look at the actual mapping behind this rule, you can see that it's very straightforward from one field to the other, and this is all it needs.
Picture: Mappings illustrated in ONEiO.
Going back to the message view again, we can also see that we have an actual incident from a customer. have the incoming payload on the left and the outgoing payload on the right.
Picture: Incident from customer illustrated on ONEiO user interface.
This is now using the TMF 621 API specification, so it looks a little bit different — but the same principles apply here too. If you observe the rule behind the “create” action and navigate to the mappings, we can see that it's still fairly straightforward.
For example, we have state versus status on the outgoing side, and we can do kind of conditional mappings. So if a state from the customer side is, for example, two, then it corresponds to a status in progress on the CSP side and the same thing can be done with severity, impact, priority — anything you like.
Picture: Conditional mappings illustrated on ONEiO user interface.
Keep track of the context with conversation feature
There's one feature in ONEiO which is (in our opinion, at least) very cool, and that is conversations. When navigating from the message view to a conversation, we can see that ONEiO keeps a track of all the messages that are linked to a single conversation. This is especially necessary when we're having case exchanges between two different systems where we need to maintain the context of the exchange. So in turn, we know that this ticket or this incident on one side corresponds to this exact ticket or incident on the other side, and this is built in to within ONEiO.
Picture: Using conversation feature on ONEiO user interface.
Essentially, conversations are kept in place and tracked. This way, updates are never carried out on the wrong entities on either side, as we have through end-to-end logging for individual conversations.
Conclusion
This was a quick rundown of the basic principles that ONEiO operates with. ONEiO is a made for purpose tool for seamless communication and collaboration between customers and communication service providers.
We hope you got an idea of our technology, and if you have any further questions, please don't hesitate to contact us at ONEiO.
