Our system takes an initial seed file and subsequent updates to offload all of the Switch Matching for you and even calculates the Early Termination Charges and issues comms. But there are options for this to be passed back to your billing systems for tight integration as time allows. Our matching algorithm exceeds the best practice and works with legacy and new data formats (LPI, DPA, PAF, etc). We also provide access to Ordinate Survey Data for new Gaining services and support to clean up older stored data. Everything is stored using ASCII Folding techniques, so your company can never be questioned about frustrating the process. Full Switch Match reports and KPIs are also issued daily.

Our team have been active members working on best practices and testing with TOTSCo, and, we have also implemented tightly coupled verticle integration for a major CP operational that had a section 135 served by Ofcom. As a result, we understand the complexity of the unhappy path and have many solutions and advice on how these issues can be overcome and managed. We also have access to many leading advisors in the industry should specialised consultancy be required.

RoaR™ is our platform, and it provides a simple portal (GUI) that can fullly offload the losing (LRCP) process and provide all the necessary servies for gaining (GRCP) workflow with the hub. While the platform offloads as much of the OTS process as possible, it is still necessary for the local RCP to interact with any MAP provider. To help with maturity and future integration, we also offer a series of Sales (BSS) and Order (OSS) APIs that allow any organisation to implement a hybrid MAP which is integrate over time towards a full zero-touch solution. With our own NowYoYo® development teams, we can assist locally or provide the necessary information and swagger API details for your own dev teams to easily implement.

We leverage the power of Mailjets multi-tenancy transactional email services which is fully integrated with RoaR. This allows clients digital marketing teams to modify the OTS templates for brand look and feel and then test these using the RoaR Platform. The emails sent are dynamic in nature and include sections that are relevant to customer. For LRCP, eliments of the services will make a significant difference to the ETC/SI being sent and this cover services and vulnerabilities if the data provided allows. All of the metadata sent is stored in our Audit system everytime an email is triggered in the workflow. This allows Level 1 and 2 Agents to pull up the emails sent and review when dealing with an enquiry.

Early termination Charges, Switching Implications and Express Consent are all critical components for compliance with the general conditions of switching. By using our Magic Link services, a CP can customise and brand their self-service journey to show and gain the necessary consent from their prospects. The system nudges consumers and takes care of centralised record keeping which is all tamper-proof for audit. This allows agents to complete sales quickly and issue a magic link for final consent, as all consumers have up to 31 days to make the necessary consideration and consent.

All CPs using our Fully Managed Service can be assured that every transaction across the TOTSCo HUB, supply chain and local integrations are all fully recorded, time-stamped, and grouped should any Ofcom requests be made or arbitration be required to resolve compensation claims between RCPs. We grant direct access to our clients so that they can search and extract specific audit events for analysis. We also provide a standard set of reports to help with analysis, as competitive patterns will exist with switching.

As NowYoYo® have been working on OTS for some time, it was necessary for us to build our own HUB in the absence of one from TOTSCo. In addition, we are able to spin up multiple Residential Commuinication Provider (RCP) endpoints that can operate as good and bad RCPs. This means we can establish an RCP with poor data quality as a unique set of matching practices which allows our clients to test against these patterns. As we know, 95-98% of households already have broadband, and so this suggests that a high proportion of consumers will use the OTS process. Without a successful match a sale can not be processed if the consumer wishes to use OTS to seemlessly switch services between providers. By building a series of RCPs that mirror some of the characteristics we can ultimately help others and train agents to get first-hand experience in handling more challenging edge cases and build guidance on the next-best-actions. This helps with training and makes agent and digital journeys much more robust to some of the challenges that OTS can through at both the Gaining and Losing Providers.

We have recently introduced our own dedicated RoaR Test RCP (RCWV) which support multiple tenancies and can be used by any other RCP to test their deployment at part of UAT pre-production testing. This test RCP, support both Syncronhous and Asyncronhous message testing, Audit Data, HUB responses and provides the ability to create challenging customer assets with multuple circuits at the same address, common Account numbers and even apply commerical/technical rules for force-cease, option-to-retain and option-to-cease which are often over looked when peforming switch matches if locally you dont support these options.

Industry consistency is key to the sucess and testing with a common baseline and diverse CPs is key to ensuring any issues are spotted and discuss with TOTSCo before going live. We hope that the tools we provide can go some way to supporting this model. Register users: A Group of emails (could be by domain) will be registered under a specific Brand (RCPID). Partitioning of access through sub-account

When used as GRCP: Users can only send messages to the registered brand(s) as these will be the only ones they see in the directory.

This ensures that each CP does not see the other’s messages when testing, both at the interaction level (associated messages related to a switch type) and at the Audit (detailed logging).

Users can see the Full Audit Log at their own CP level and NYY, thus removing the need for TOTSCo and the service desk to be engaged, as both sides can be viewed without dummy RCPIDs.

When used as LRCP: A. Synchronous Message Responses: Using predefined surnames, e.g. “FourHundredAndTwo”, NYY will respond with that specific HTTP Code and attempt to pass specific payloads back to the HUB. Current Change request submitted to TOTSCo: The passing of the payload is significant so that CPs can signal to each other why they have rejected a specific message and self-heal. Having the HUB strip this and replace it with a generic 9006 or 9008 message means the intelligence has been lost. If we can pass the body, then the Service Desk would not have to be engaged in understanding the rejections, which would drive down the cost-to-service for TOTSCo/industry.

B. Force AuditData Responses: By sending appended surnames, AuditData can be inserted into the envelope.This helps with testing HUB validation and the ability to handle these messages.

C. Canned Responses: As standard, we can match a specific UPRN to an Asynchronous Response Code. This allows CP to check and ensure they can handle all Response codes with the next best actions.

D. Switch Match Delays: To make the LRCP challenge slightly more complicated, we can insert delays into the response so that GRCP can test latency. This can be done at a common level (fixed and random) and fixed latency based on specific UPRNs. This helps with Digital journey development to check presentation layers, agents and end consumer screens can handle delays.

E. Customer Assets: A set of Customer Assets can be created to mirror good and bad stored customer details. This allows a high degree of flexibility in storing good & bad address data, e.g. having multiple accounts with the same surname in the same house and testing different entity models. Data can include UPRN, errors in UPRNs, and conflicting address details.

We can even add different commercial rules to each customer, which allows the algorithm to return different SOR options based on the technical/commercial setup of that company (forced Cease vs. OptionToCease/ OptionToRetain) and thus enable a CP test outside of their own commercial rules to check they can handle this.

When resolving complex matching, OTS response codes will be returned per the matching algorithm to help guide agents and the system with the next actions. This means that CPs will experience unhappy Switch Matches and ensure that their training and systems can handle the matching of data stored (shown on the invoice) and not what OS data might say when you look at a postcode.

F. Switch Orders: As new Orders come in from the CPs acting as a GRCP, the NYY system can manually confirm or reject with a specific response code to all orders, updates, cancels and triggers so that CPs can test when confirmations are not returned within the SLA or response are returned that they were not expecting. These features allow CPs to do some negative testing when a CP is a bad actor and ensure they can handle this at system, agent, and digital journey levels. We currently operate this over two environments.

SIT – System Integration Testing - which operates over the NowYoYo HUB and is used to iterate, and this could be extended, if required, directly to other CPs if at the early stage of development.

UAT – User Acceptance Testing – This utilises the pre-production TOTSCo Hub and is thus ideally suited and is also available 24/7.