UK Communication Providers should ask switching providers about supported switching services, onboarding, pre-go-live testing, failed-message handling, monitoring and reporting, data protection, technical change management, service resilience, post-go-live support, and responsibility ownership before signing. Clear answers to these ten questions help determine whether a provider is technically and operationally ready to support reliable switching under Ofcom’s One Touch Switching framework. Most providers will tell you they are ready. Few will be able to prove it. The difference between a switching provider who is genuinely operationally ready and one who is not rarely shows up in a sales conversation. It shows up in production when a message fails, a switch stalls, or a customer calls because their service has not moved when it should have. By the time that happens, the contract is signed and the integration is live.
The ten questions in this guide are designed to surface that difference before you commit not after. They are not technical gotcha questions. They are the practical, reasonable questions that any operationally mature switching provider should be able to answer clearly, specifically, and with evidence.
If a provider struggles with any of them that is the answer.
Why Choosing the Right Switching Provider Matters
Choosing a switching provider should involve more than comparing cost, implementation timelines, or whether the provider can exchange switching messages. For UK Communication Providers, switching touches customer information, operational workflows, testing, technical integrations, service continuity and ongoing support. TOTSCo’s business-switching guidance follows a structured journey from preparation and connection through onboarding, testing and live switching. That means the right provider should be evaluated on how well it supports the whole switching lifecycle, not just the technical connection. Switching is ultimately a customer-impacting operational process. If a transaction fails, a message is rejected or service information cannot be matched correctly; the problem may quickly move beyond the technical team and affect customer support, provioning or service activation. This is why switching provider selection should consider reliability, operational visibility, support, and long-term readiness, not just whether the first connection can be established.
This is why choosing a switching provider should go beyond whether the initial connection works. CPs should also consider reliability, operational visibility, support, security, and long-term readiness before deciding. For CPs looking to understand the wider switching environment, our existing guide, What Is TOTSCo?, provides an overview of TOTSCo, the Hub, and their role in UK switching.A successful connection to the TOTSCo Hub proves that systems can communicate, but it does not necessarily mean a Communication Provider is ready to manage real-world switching operations.
Migration TOTSCo involves much more than establishing connectivity or exchanging messages. Providers need to align their technology, customer data, operational workflows, internal teams, monitoring capabilities and exception-handling processes to support the complete switching journey. The operational scale makes this distinction particularly important. TOTSCo confirmed in June 2026 that the residential One Touch Switch process had crossed the 3 million completed switches mark. Although residential OTS and business switching remain separate journeys, this milestone shows just how much volume standardized switching infrastructure is now capable of handling.
It also highlights why providers need robust processes around their technical integrations rather than relying solely on a successful connection. Working integration is only the starting point. Once switching activity moves into production, providers must be prepared to handle both expected and unexpected scenarios. Customer information may be incomplete or inconsistent, services may not match the information held in internal systems, messages may be rejected, or downstream platforms may be temporarily unavailable. In these situations, the ability to identify the problem, understand its impact and resolve it quickly becomes just as important as the underlying connectivity.
10 Questions to Ask Any Switching Provider
1. Which Switching Services and Processes Do You Support?
Start by understanding exactly what the provider supports. Ask which residential or business switching processes are covered and whether the service aligns with the switching journeys your organization needs today. Do not rely on broad claims such as “we support UK switching.”
Instead ask:
- Which switching processes are supported?
- Which message types are handled?
- Are there limitations by service type?
- How are new switching requirements added?
The provider should be able to describe the scope clearly enough for both technical and operational teams to understand. A provider who cannot define their scope with specificity is one who has not yet been tested against it.
2. What Does the Onboarding Process Look Like?
A well-defined onboarding process can reveal a lot about how organized the provider will be once the service is live. TOTSCo’s business-switching guidance includes account setup, brand management, contacts, testing and operational support as part of preparation for live switching.
Ask the provider:
- What information is required from us?
- How long does onboarding normally take?
- Who coordinates each stage?
- What dependencies could delay implementation?
- What documentation will we receive?
A strong provider should have a repeatable onboarding process rather than relying on ad hoc coordination. If a provider cannot walk you through their onboarding steps clearly and in sequence, that uncertainty will follow you into implementation.
3. How Do You Test Before Go-Live?
Testing should be one of the most detailed parts of the conversation.
TOTSCo’s business-switching testing guidance includes several phases designed to validate connectivity, message structure, integration, and production readiness. Ask whether testing covers both successful and unsuccessful scenarios.
Examples include:
- Correct switching requests
- Invalid or incomplete data
- Failed message delivery
- Matching failures
- Unexpected responses
- Downstream system outages
- Recovery after temporary failures
The key question is not simply “Can the system complete a switch?” It is: Can the service recover correctly when the switch does not follow the expected path? A provider who has only tested success scenarios has only tested half of the system.
4. How Are Failed Messages and Exceptions Handled?
This is one of the most important questions to ask any switching provider in the entire evaluation.
Real switching operations will eventually encounter errors. Ask what happens when:
- A message fails validation
- A message cannot be delivered
- Customer information cannot be matched
- A downstream system is unavailable
- A workflow requires manual review
You should understand how the provider identifies, records, escalates, and resolves each type of exception. A vague answer such as “the platform retries automatically” is not enough. UK Communication Providers need visibility into what failed, why it failed, and what needs to happen next. Without that visibility, your operational team discovers failures through customer complaints, which is always the most expensive way to find out.
5. What Monitoring and Reporting Are Available?
Once live switching begins, operational visibility becomes essential. Ask whether the provider gives your teams access to information such as:
- Message status
- Successful and failed transactions
- Rejection reasons
- Matching outcomes
- Processing times
- Retry activity
- Open exceptions
- Service availability
A dashboard that only confirms the platform is “online” and offers limited operational value. Your team should be able to understand where a switch journey is failing and whether the issue relates to connectivity, data, message processing, or an internal system. Monitoring is not a luxury feature it is the mechanism through which you protect your customers and your compliance position day to day.
6. How Do You Protect Switching Data?
Switching involves customer and service information, so security should be discussed before implementation rather than after it.
Ask about:
- Authentication controls
- Access management
- Data protection standards
- Logging and audit trails
- Credentials or certificates where applicable
- Security incident handling procedures
You should also understand how access is granted, reviewed, and removed when team members or responsibilities change. A switching provider should be able to explain their security controls clearly and specifically without relying on broad statements such as “industry-standard security.” Under UK GDPR, a switching provider for processing customer data on your behalf, is acting as a data processor. That means a data processing agreement must be in place before a single switching message is exchanged.
7. How Do You Manage Technical and Industry Changes?
Switching platforms do not remain static. Specifications, processes, and operational requirements change over time. TOTSCo’s Business Document Centre currently lists TOTSCo API Specification v2, published on 1 April 2026, alongside updated business-switching process and message documentation. Providers who do not actively monitor specification changes risk sending non-compliant messages after updates creating switching failures that affect live customers.
Ask:
- How are industry changes monitored?
- How are platform updates tested?
- How much notice will customers receive?
- Will our systems require changes?
- Is regression testing included?
TOTSCo released API Specification v2 on 1 April 2026 as part of preparations for the launch of the production environment for the business switching solution TOTSCo Bulletin 107, API Specification v2. Providers who do not actively monitor specification changes risk sending non-compliant messages after updates creating switching failures that affect live customers.
8. How Resilient Is the Switching Service?
Reliability is about more than uptime. Ask what happens if the provider’s platform or one of its dependencies becomes unavailable.
Important questions include:
- Is there redundancy built into the service?
- How are failed transactions recovered?
- Are messages queued safely during outages?
- What happens during planned maintenance?
- Is there a documented recovery process?
- How will we be informed about incidents?
Resilience should be evaluated from the perspective of the switching journey not simply infrastructure availability. A system can technically remain online while transactions are still failing. A provider who cannot distinguish between these two states has not thought carefully enough about operational resilience.
9. What Happens After Go-Live?
Some providers are highly involved during implementation and much less visible once the platform is live. Ask about ongoing operations before signing.
You should know:
- Who provides support post go-live?
- What support hours apply?
- How incidents are raised and tracked
- How escalations work
- Who investigates recurring issues
- How platform changes are communicated
- Whether operational reviews are available
Ofcom reported in September 2025 that more than 1.6 million customers used One Touch Switch during its first year, with more than 300 providers participating in the Ofcom One Touch Switch Report, September 2025. At that scale, post-go-live operational consistency is what separates providers who deliver reliable switching from those who struggle with recurring failures.
10. What Responsibilities Will Still Remain with Us?
This is one of the best questions to ask any switching provider to uncover hidden assumptions. Ask the provider to explain clearly which responsibilities remain with the CP. That might include:
- Customer data quality
- Internal integrations
- Operational decision-making
- Customer communication
- Support escalation
- Compliance obligations
- Internal incident management
The important point is clarity. If both organizations assume the other party owns a task, the problem will usually surface during an incident, not during a planning meeting. A responsibility matrix agreed before implementation can prevent the kind of confusion that becomes a compliance issue under Ofcom’s General Condition C7.
Key Concerns When Comparing Switching Providers
Not every concern a provider raises will be obvious during a sales conversation. Some providers may demonstrate a working connection or polished dashboard without showing how the service performs under real operational conditions. CPs should look beyond demonstrations and ask for evidence of how the provider handles the complete switching lifecycle. Watch for providers that give vague answers about onboarding, testing, failure handling, monitoring, security, or post-go-live support. Limited visibility into failed transactions, unclear escalation routes, or no defined ownership model can create significant operational challenges once switching volumes increase. Another warning sign is a provider that cannot explain how it manages specification of changes, regression testing, service outages, or recovery procedures.
Be cautious if resilience is presented only as an uptime percentage without explaining how failed switching transactions are recovered. Similarly, if most technical issues depend on a small number of specialists, support may become a bottleneck during incidents. The strongest providers should be able to explain their processes clearly, demonstrate evidence, and define responsibilities before implementation begins.
Vague Answers About Switching Operations: Be cautious if a provider talks mainly about connectivity but struggles to explain switching operations in practice. A technically connected provider who cannot describe how their service handles day-to-day operations is a provider whose operational readiness has not been tested.
No Structured Testing Process: A provider without a structured testing programmed one that covers failure scenarios, edge cases and recovery has not validated their service against the conditions that matter most. Passing a standard connectivity test is not the same as being operationally ready for live switching.
Limited Visibility into Exceptions: If a provider cannot explain what operational visibility you will have into failed transactions, rejection reasons and exception management, your team will be operating blind once switching goes live. That is an operational risk and a compliance risk simultaneously.
Unclear Post-Go-Live Support: A provider who cannot define their post-go-live support model before signing has not thought carefully about the relationship beyond implementation. Ask specifically about support hours, escalation paths, incident management and contacts. Vague answers at this stage become operational problems later.
Cannot Define CP Responsibilities: If a provider cannot clearly articulate where their responsibilities end and yours begin, the boundary will be discovered during an incident rather than agreed during planning. That is always the most expensive way to find out.
Final Thoughts
The most important questions to ask any switching provider go beyond price, features and implementation speed.UK Communication Providers should understand how onboarding, testing, exceptions, monitoring, security, resilience, technical change and support will be handled before deciding. They should also know exactly where the switching provider’s responsibilities end, and their own begins.
The strongest provider should be able to explain these areas clearly, demonstrate how problems are handled, and show how the service will continue operating after go-live. Providers who can do this have built their service to last. Providers who struggle to answer these questions clearly do not. For a deeper explanation of the business-switching journey itself, see GPLB Switching: A Practical Guide for UK CPs.