NowYoYo® is a UK Managed Access Provider for Switching

Our system takes an initial seed file and subsequent updates to offload all Switch Matching for you, and even calculates the Early Termination Charges and issues comms. But there are options to pass this back to your billing systems for tight integration as time allows. Our matching algorithm exceeds best practices and supports legacy and new data formats (LPI, DPA, PAF, etc.). We also provide access to Ordnance Survey Data for new Gaining services and support for cleaning 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. We have also implemented tightly coupled vertical integration for a major CP operator 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 to overcome and manage these issues. 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 fully offload the losing (LRCP) process and provide all the necessary services for the gaining (GRCP) workflow with the hub. While the platform offloads as much of the process as possible, the local RCP must still interact with any MAP provider. To support maturity and future integration, we also offer a series of Sales (BSS) and Order (OSS) APIs that enable any organisation to implement a hybrid MAP, which is integrated 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 dev teams to implement easily.

We leverage Mailjet's multi-tenant transactional email services, which are fully integrated with RoaR. This allows clients' digital marketing teams to modify the OTS templates to match the brand's look and feel and then test them using the RoaR Platform. The emails sent are dynamic and include sections relevant to the customer. For LRCP, elements of the services will make a significant difference to the ETC/SI being sent, including services and vulnerabilities, if the data provided allows. All metadata sent is stored in our Audit system whenever an email is triggered in the workflow. This allows Level 1 and 2 Agents to pull up the emails sent and review them 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 handles centralised record-keeping, all of which is tamper-proof for audit purposes. 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 is fully recorded, time-stamped, and grouped should any Ofcom requests be made or arbitration be required to resolve compensation claims between RCPs. We grant our clients direct access so they can search for and extract specific audit events for analysis. We also provide a standard set of reports to support analysis, as competitive patterns will exist when switching.

As NowYoYo® have been working on OTS for some time, we needed to build our own HUB in the absence of one from TOTSCo. In addition, we can spin up multiple Residential Communication Provider (RCP) endpoints that can operate as both good and bad RCPs. This means we can establish an RCP for poor data quality as a unique set of matching practices, allowing our clients to test against these patterns. As we know, 95-98% of households already have broadband, suggesting 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 switch services between providers seamlessly. By building a series of RCPs that mirror certain characteristics, we can ultimately help others, train agents to gain first-hand experience handling more challenging edge cases, and develop 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 throw at both the Gaining and Losing Providers.

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

Industry consistency is key to success, and testing with a common baseline and diverse CPs helps ensure that any issues are spotted and discussed 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 are the only ones they will see in the directory.

This ensures that each CP does not see the other’s messages during testing, both at the interaction level (messages associated with a switch type) and at the Audit level (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: Passing 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, the Service Desk would not have to be engaged in understanding the rejections, which would reduce 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 handling these messages.

C. Canned Responses: As standard, we can match a specific UPRN to an Asynchronous Response Code. This allows CP to verify they can handle all Response codes using 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 by checking whether 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 for each customer, allowing the algorithm to return different SOR options based on that company’s technical/commercial setup (forced Cease vs OptionToCease/OptionToRetain), and thus enable a CP test outside their own commercial rules to check they can handle this.

When resolving complex matches, OTS response codes will be returned per the matching algorithm to help guide agents and the system on next actions. This means that CPs will experience unhappy Switch Matches and ensure that their training and systems can handle matching the stored data (as shown on the invoice), 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 all orders, updates, cancels, and triggers with a specific response code, so that CPs can test when confirmations are not returned within the SLA or when responses are returned that they were not expecting. These features allow CPs to conduct negative testing when a CP is a bad actor and ensure they can handle this at the 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 an 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.