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.
