1 Introduction
To aid various readers with different levels of background knowledge, there are several documents covering the Gaining Provider Led (GPL) Switching for Business process. This document may refer to the Switching for Business process as ’SforB’ from here onwards:
- Switching Principles: documents the main principles associated with the Switching for Business process.
- The One Touch Switch (OTS) process document and best practice guides. This provides an explanation of key concepts and industry background. The OTS process provided the initial starting point for the GPL Switching for Business design to reduce complexity for Retail Communications Providers offering services to both Businesses and Consumers.
- (This document) GPL Switching for Business Industry Process: this document focuses only on the detail of the Industry Process and assumes that readers are familiar with relevant terminology and concepts.
- Industry Process Flows: diagrams with swim-lanes for customer, GRCP, Hub(s), LRCP and supply chain. Readers who prefer a visual view of the process will find these diagrams useful.
- Each step in the in the process flow is numbered with a “BSW” prefix, followed by process flow number and step number, e.g. “BSW1.2” – the same numbering is used in this this Word document.
FCS (federation of communication services) helpfully host the latest version of all documents relevant to the Switching for Business process at https://www.fcs.org.uk/gaining-provider-led-business-switching
This purpose of this document is to provide a summary of the industry process.
1.1 Scope of GPL Switching for Business
This document covers GPL business switching for all sizes of business customers.
The business switching process outlined within this document covers the process steps to follow where the end user is moving from and to a business service/contract. We recognise that there may be instances where, the end user may wish to switch providers and from a consumer to a business contract, or vice versa. The process is not defined within this document.
1.1.1 Dual running of services
It is recognised that unlike residential switching, there will be a number of scenarios where a customer may need a period of dual running of ‘old’ and ‘new’ services for a period of time, subject to the customer’s request. This may be for example, to support testing. This raises the question of whether this represents a customer switch or a provide and cease. Where a customer recognises at the outset, that they require a period of parallel running greater than 90 days, it is recommended that these requests are not treated as a switch. It is accepted that unexpected delays may occur within the process, which create delays in practice to extend beyond the 90 days. The concept of dual running only applies where this is technically feasible. The Switching for Business process does not seek to create any new requirements upon industry.
1.1.2 Version 3.0
This is version 3.0 of the GPL Switching for Business Industry Process updated following initial industry feedback and consequential design development or clarifications.
The GPLB-SG (GPL Business switching Steering Group) established a Design Drafting Group (with some members from the original consumer OTS-DDG), who have produced this document with input from the Steering Group and OTA2.
1.2 Change Log
| Version
Date Changed By |
Reason for change |
| Initial working drafts
Jan – Mar 2023 GPLB-DDG |
Initial series of working draft only circulated within the GPLB-DDG. |
| v1.0 First Draft
31/03/2023 GPLB-DDG |
First draft from the GPLB-DDG established by OTA2 and GPLB-SG. This draft will be circulated to industry reps for review and feedback. |
| V1.1
18/05/2023 |
Updated documentation following review by industry representatives. Issued to Design group and GPLB Steering Group only |
| V1.2 &1.3
05/09/23 |
Switching dispute information added. SLAs updated and matching elaborated. Issued to Design group |
| V2.0 | Updated service matching guide. |
| V2.1 | Updated following reviews on SLAs and matching ‘lessons learned’ from OTS implementation. |
| V2.2
|
Updates made to matching details, removal of LOA and linked reference. Clarity provided on SLAs. |
| V3.0 12.08.2025
06.11.2025
|
Updates:
– Process name change to Switching for Business – Removal of Disputed Ownership process – Removal of the action from Services on Match Requests – Clarification on expected behaviour for fully automated matching with respect to LRCP response times in SLA appendix. Removed ‘working draft’ and hanging sentence. – Removed ‘working draft’ and hanging sentence. |
2 Overview of GPL business switching process
This section provides an overview of the GPL business switching process, especially for those who may not have read Ofcom’s Consultation and Statement documents, or their General Conditions. Readers are very strongly encouraged to also read those documents[1].
The GPL business switching process includes the following high-level steps between the Gaining Retail Communications Provider (GRCP) and the Losing Retail Communications Provider (LRCP).
| Step 1 | Customer Engagement and Initial Data Capture
|
| Step 2 | Customer and Service Matching
|
| Step 3 | Switching Information and Consent
|
| Step 4 | Switch Order Placement
|
| Step 5 | Order Fulfilment and Completion
|
| Step 6 | Switch Cancellation (Cancel Own)
|
3 Match requests and responses
When reading this document you will see reference to GRCP (Gaining Retail Communications Provider) and LRCP (Losing Retail Communications Provider). Retail CPs are those directly contracting with the customer (now or in future). Each retail CP will need to register and obtain an ID, known as an RCPID, which will allow messages to be directed correctly across the hub(s).
Retail CPs will interact typically via a Managed Access Provider (MAP) using one or more match requests and corresponding match responses. Each match request has several logical elements:
- Details to match a business customer recognised by the LRCP. This also helps to ensure that a switch is being legitimately requested by the end user. ‘Customer Identifiers’ include business name, a unique customer reference (such as an account number) and may include service details.
- Customer address. The address provided at the match stage is used to support a customer match. The address information provided at this stage, will be used for two other purposes. Firstly, if the customer has a single Internet Access Service at a location, but does not know the asset ID, then the address is taken as the match address when IAS service match is requested. Secondly where an asset list is requested relating to a specific address, the address will be assumed to be the one provided within the match stage.
- An optional request for the LRCP to send an asset list directly to the customer (where a customer does not have this information).
- An optional set of one or more services that the customer wishes to switch from the LRCP to GRCP (some services may be ceased with the LRCP in support of a switch of a related service).
- An optional previously generated SOR, to which any newly matched services or requests can be associated with.
The option to request that an asset list is sent by the LRCP directly to the customer is likely to be of use for customers with multiple sites and/or multiple services at a single site. If the GRCP is aware they are dealing with such a customer, they may choose to send a match request for an asset list at the pre-sales stage. It is also feasible that a customer may have a pre-existing asset list (e.g. from an earlier match request via a different GRCP, or as part of the documentation produced by the LRCP during a tender process triggered by the customer).
Customers at the SOHO end of the business market tend to have simple, often single, services, and are much less likely to need an asset list. GRCPs should avoid unnecessary requests for an asset list, as they impose work on the LRCP, and will slow down the sales process for the GRCP.
This document uses the term “customer match” in relation to the LRCP matching a unique business customer.
When requesting a customer match the current retail provider’s details, the business name and business address must be provided. If these details are not provided, then the request will be rejected prior to any validation. In order to perform a successful customer match, the LRCP should be satisfied that there are sufficient points of matching. Best practice matching guidance has been considered to support LRCPs and should be read in connection with this section.
Note whilst customer match may occur a service match may still fail.
This document uses the term “service match” in relation to matching services which the customer wishes to switch. The services can be matched by inference (e.g. the customer match was to a SOHO customer with a single IAS service) or explicitly (i.e. with a matching unique service identifier, e.g. taken from an asset list). The same service identifier may be used within both the customer match and service match data. The LRCP needs to be able to determine which services their customer wants to switch in order to take the correct action and which are only being used for customer matching purposes. In the scenario where Customer and Service identifiers are the same, the GRCP will repeat the service details under Customer “Identity” and “Services” within the messaging to the LRCP.
The GRCP is permitted to send multiple service match requests, e.g. one per site for a multi-site customer. The LRCP will generate a SOR for the first successful customer match request. If the GRCP includes the SOR in subsequent service match requests, the LRCP will add any successful service matches to their record of which services are associated with that SOR.
A customer may need to raise more than one customer match requests where there are multiple services without an asset ID, and where multiple addresses are needed to identify the circuits. GRCPs should consider how they will manage all associated requests for their customer, this is because if an SOR is not used, then the matches will not be associated and will be treated independently.
Detailed industry guidance has been created which outlines which combination of data elements will result in a successful match and which response codes should be used in the event of an unsuccessful match. Please refer to ‘Switching For Business Customer Matching Guidance’ and ‘Switching For Business Response Codes’.
3.1 BSW1.2 Customer contacts GRCP via sales channel
Capturing the information needed for a match request should not be the first step for a gaining retail provider. Retail CPs are encouraged to create sales processes that allow customers to explore the available options when considering switching, and only start the matching process when there is some indication that the customer wants to explore the full impacts of switching. This will minimise the load placed on losing retail providers and reduce concerns of annoying customers by sending them multiple notifications about switching and potential impacts.
3.2 Match request and response
For the SOHO end of the business market, matching may take place in the “checkout” stage of a simple order journey (very similar to the consumer OTS process). Further up the business market, matching may take place during a pre-sales stage.
The overall matching step of the business process is when the customer contacts the gaining retail provider and provides details which can be used to consult the losing retail provider[2] (via the hub(s)). Matching serves two purposes, either to match the business customer and to request the LRCP send an asset list to the customer or to match the customer and match services at the same time.
Throughout this document we refer to the interactions between the GRCP and LRCP at this overall step as the “match request” and “match response”. This section takes the reader through the steps in sequence, to establish an understanding of the main process flow.
Once a request has been submitted it is expected that the LRCP provides a match response by the end of the second full working day following receipt from the GRCP. Where multiple service matches are completed at the same time, timescales may vary. Please refer to the Appendix III related to SLAs for further information.
Where an end user wants to switch services from two different providers to one new provider, the gaining provider will need to submit a separate match request to each losing provider.
Additional matches may also be required in a multiple location switch scenario where no asset identifiers are available as only one address is provided for the initial match. Some businesses with complex corporate structures may also require multiple match requests, such as where services to be switched are linked to different business accounts within a Group of companies.
3.3 BSW1.4 Gaining retail provider takes details
If the customer advises that they wish to switch, the gaining retail provider will need to follow a matching process via the hub(s) with the losing retail provider. There are several key pieces of information needed to attempt an initial customer match:
- Identity of the losing provider (brand on the customer’s bill).
- The business name or sole trader name.
- Customer address. This may be the Head Quarters (e.g. where services such as non-fixed VOIP may be associated with), but the Billing or Service address are also permitted. And at least one of the following items:
- The telephone number of a service currently active with the LRCP.
- Service identifier (IAS).
- A unique customer reference used with the losing retail provider (3.3.4 below gives examples of identifiers the LRCP might recognise.
Note: The address information provided at this stage, may be used for additional purposes. Firstly, if the customer has a single Internet Access Service at a location, but does not know the asset ID, then the address is taken as the match address when IAS service match is requested. Secondly where an asset list is requested relating to a specific address, the address will be assumed to be the one provided within the match stage.
If the customer already knows what services are to be switched and is ready to proceed, details of the service to be switched should also be captured to allow for a service match. If such details are not known to the customer, then a match request for an asset list would be appropriate.
There is other optional information that can be provided, such as contact details of the requestor of an asset list – these are covered in detail in relevant sub-sections below.
At this point the GRCP should also gain the customer’s permission to interact with the LRCP (via the hub(s)) to either request an asset list or to attempt a match of one or more services with the LRCP
3.3.1 Identity of the losing retail provider
This is a key piece of information to attempt a match – without this, the hub(s) would not know where to route the match request. The end user should be asked for the Communication Provider’s name on the bill. Where the customer has services from two providers both should be captured and a separate switch process followed for each provider.
The MAPs will provide an updated list of RCP brand name(s) (“name on the bill”) which have signed up to SforB . RCPs will be able to download this list on e.g. a daily basis, and will then cache that download for use in their sales systems.
Many RCPs have both consumer and business brands, but consumer customers are not necessarily aware of the business brand. Some RCPs share a brand name between business and consumer, and other RCPs have more distinct brand names.
When the gaining provider captures and attempts to match information about the current provider, care should be taken to select the correct Retail CP name.
3.3.2 Business name
The gaining provider must capture the business name as held by the losing provider. This field is mandatory.
Note that the business name held by the losing provider may differ from the current business name. For example, a company may have been bought out by another company. The GRCP is expected to interact with the customer to capture the business name as held by the LRCP. This doesn’t prevent the new provider from recording an updated name within their own systems, but a failure will occur for this match element and a rematch may be necessary if the name does not match that held by the LRCP. Alternatively, the customer would need to contact their current provider to correct any out of date / erroneous information which may take longer to complete. As good practice the GRCP should ask the customer for the name of the company as it appears on the bill from the LRCP.
Fuzzy matching logic is also expected to be applied on the business name. For example, if ‘Ben’s Bread Limited’ is on the LRCP’s system but a match request is raised for ‘Bens Bread Ltd’, this should not be rejected. Equally, If Mr C Hip is listed on the current provider’s system but a match is requested for Mr Charlie Adam Hip on the match request this would be considered an acceptable match.
In general, business name matching is often based on the “legal entity” name. For a sole trader, the legal entity is the individual, even if they also use a “trading as” name. Where the GRCP captures and the LRCP holds the name of the sole trader, this should be a successful match, even if one or other have also captured and hold the “trading as” name.
One business name should be provided for each Customer match rather than multiple attempts within the same customer match request. If a ‘scattergun’ approach is taken an error code will be issued.
For large complex corporate customers, the customer may have multiple addresses associated with the account. The services to be switched may also be linked to multiple addresses. For the customer match – only one address should be provided. The key is that the address must be associated with the named entity wanting to switch. If you do not have asset identifiers the customer address provided may need to be used as the service address in a subsequent service match.
3.3.3 Customer Address
Customer Address
The gaining retail provider will need to capture the customer address as held with the losing retail provider. In most cases, this should be the same address as where the gaining retail provider is expecting to provide service. Where services provided have no fixed location, for example VoIP, it may be appropriate to provide the head office address if that address is associated with the service.
The customer address is mandatory to complete a successful match. Some address tolerances are permitted in some match scenarios. The SforB Match-Request-Response-Scenarios document should be reviewed for each scenario. A single address should be provided for the customer per customer match rather than multiple attempts within the same customer match request. If a ‘scattergun’ approach is taken an error code will be issued.
In order to support successful matches, the gaining retail provider should submit the address of a good quality, with full post town and post code, and other address lines formatted as per Royal Mail’s PAF guidelines. (Refer to Appendix II).
3.3.4 Customer reference with the losing provider
For GPL business switching, the provision of the unique customer reference is not mandatory but is recommended to be provided. This is a strong information point to enable customer matching to be completed simply. Due to the greater degree of data variability associated with business name capture and complexity of business addresses, the account number is deemed to be the most likely way to enable successful matching.
It is assumed that all RCPs have the concept of an account number or a unique customer reference[3] (even if they use terms such as “customer id”). Most RCPs ask customers to treat this value with some confidence, and use it as one element of their caller validation processes. Some RCPs do not have the concept of an account number, and instead have concepts such as a username or similar used in a customer online portal – as long as such values uniquely identify a single business customer, they are valid to be used as a customer reference for matching. Some retail CPs are also considering providing end customers with a proxy for a Customer reference number to support switching. This should be used in the same way that a customer reference or account number is used.
Customer reference details are particularly needed in instances where the customer has data only Internet Access Services such as FTTP. In these instances, the customer reference will provide a strong data point to support the match and accurate customer verification.
In a business context, there is sometimes a hierarchy of accounts, e.g. accounts for individual services or sites feeding into a master account. Each LRCP will decide its own policy as to which account number is needed for a successful match, e.g. they may support matching using both the low-level account number and the master account number, if their customers are aware of both account numbers and could reasonably quote either. LRCPs should not impose a policy that Ofcom might view as unnecessarily restrictive.
Where a match is being undertaken to match the customer and request an asset list only, you will need to provide the account reference directly associated with the account which the asset list relates to.
Should you require asset lists for multiple accounts (rather than all assets associated with the customer), additional customer match requests will be needed providing the account reference for each separate account.
Note throughout this document we may refer to customer reference, account number or account reference. All used with the same meaning as described in this section.
3.3.5 Telephone number of an active service
For GPL business switching, the provision of the telephone number is optional. It is recognised that many business customers may not have their account details to hand when talking to the GRCP. By providing a telephone number associated with a service, it provides an alternative to enable a match. This telephone number does not need to be the service which will be subject to the switch and is for verification only, where provided for the purposes of identity.
In this context the telephone number is a number which has been assigned to the customer for their use of Number-based Interpersonal Communications Services. The telephone number should not be a mobile number nor a presentation number.
3.4 Match of services to be switched
Within this stage of the match request, the customer may also know which services they wish to be subject to a switch request. If known, the service details can be provided as part of the match request. If these details are not yet known, a match against the services can subsequently be completed, following a successful match of the business customer.
The Ofcom documents (and the original industry submissions) mostly refer to the “services to be switched”. However, this Industry Process more accurately acknowledges that voice might be ceased instead of being switched.
The general switching rules in the revised General Conditions apply only to Internet Access Service (IAS) and Number-based Interpersonal Communications Service (NBICS) (more commonly referred to as “broadband”and “voice”).
In many networks, the broadband and voice are technically linked. Even where not technically linked, they are often strongly linked by contracts and bundles.
To Perform a Service match the following information is required:
- The service identifier (e.g. The telephone number or other Asset ID that the losing provider will recognise). This field is optional for IAS but is mandatory for NBICS. For NBICS, the telephone number will be presented without +44 and including the trunk code (0).
- The type of service (NBICS or IAS) is mandatory to provide. Some legacy products have both data and voice (e.g. FTTC) in this instance the line is directly linked to the CLI (voice) element and this should be used for matching purposes.
- The address associated with the IAS service, where no service identifier has been provided, will be taken to be the one provided in the original customer match. A telephone number should always be used for a switch of NBICS and the number should be associated to the service.
- The GRCP can also optionally specify the action the losing provider is asked to take with the service specified. A valid value is ‘cease’, which is also the default value if no action is specified. Cease indicates the LRCP should cease the service when the switch is actioned. Other values may be added in future.
3.4.1 Multiple services to be switched
In business switching it is not uncommon for more than one service to be switched at the same time. Once the customer match has been confirmed multiple services can be matched during the switching process. The service matches can be completed in one go, or over time, up to 180 calendar days from the date that the customer Switch order reference is generated following a successful Customer match.
Where a customer wishes to switch a continuous range of telephone numbers for example 0161123456 to 0161123476 these can be completed in one match by entering into the service identifier field the start and the last in the number range with a hyphen between e.g. 0161123456-0161123476. A range should only be used if all numbers are consecutive. For efficiency purposes these should be raised as one request rather than individually. If the numbers are not consecutive separate service matches are required.
Multiple customer and service matches may also be required for each customer where:
- There is more than one LRCP linked to the services to be switched.
- If there is more than one location, and the IAS asset identifier is unknown, with one IAS at each location.
- If the customer’s services are linked with multiple account numbers and an asset list is required for specific accounts.
3.5 Decision point: does the customer have all the service identifiers they need to switch?
The GPL business switching process thus has an optional step to request the LRCP to send the customer a list of all of their services to support switching. The list would contain the service identifiers needed for a subsequent match request to specify the services to be switched / ceased, but should also contain information on each service recognisable to the customer (e.g. identification information that the customer sees on their bill) and importantly what an LRCP would recognise when a service match request is submitted.
3.6 BSW 1.5 Gaining retail provider sends asset list request to LRCP
This is an optional step as described above.
GRCPs should only send this type of request if absolutely necessary. E.g. for a SOHO customer with only one IAS service, or a small customer with several services wanting to switch them, or a customer with knowledge of their service identifiers, requesting an asset list would be an unnecessary step, creating extra work for the LRCP, and delaying the sales process for the GRCP.
When requesting an asset list the GRCP should indicate within the match request the type of asset list required There are four options that can be selected when requesting assets these include:
- All services at address irrespective of the account. This is a request for information about all IAS and NBICS services associated with the address, belonging to the LRCP for the matched customer, included as part of the match.
- All services linked to account reference irrespective of address. This is a request for information that relates to all IAS and NBICS services associated to the account reference included as part of the match, irrespective of the location provided as part of the match.
- All services for that account and address. This is a request for information about all IAS and NBICS services associated both at the same address and linked to the same account reference provided as part of the match.
- All services for that customer irrespective of address or account. This is a request for information about all IAS and NBICS services. This may be applicable for large corporations which have multiple sites and multiple accounts with the LRCP. The details within the customer match should be used by the LRCP to identify the target customer and associated services.
As previously described in section 3.3.4 different providers may associate account numbers to services in different ways. Some LRCPs may use customer account numbers or customer references differently.
GRCPs should be mindful of these differences when placing an asset list request. Examples are provided in 6.5 Appendix V to assist understanding.
Where an asset list is not requested at the initial customer match stage, but is subsequently needed, then this can also be requested at a later stage. The request requires there to be an account number associated with the customer match, and an additional customer match is needed.
The requestor name must be included in any asset list request. It is also good practice to capture the role of requestor to support with potential queries.
3.7 Hub(s) logs request and routes to the Gaining or Losing retail provider
The MAP hub(s) will log the messages (for audit trail purposes) and route the request to an end point as defined by the RCP that owns the losing retail provider RCPID. This step is repeated throughout the process, we have listed once for awareness.
3.8 BSW1.10 Losing retail provider sends asset list to the customer following successful customer match.
If the LRCP finds a single matching customer, they will send an asset list directly to the customer where an asset list has been requested. The asset list should be sent using the registered contact details the LRCP holds. As Retail CPs assign and capture contacts differently e.g. some record primary contacts, some people are listed as billing contacts, others as commercial contracts, it will down to the LRCP to determine which is the appropriate contact to send the asset list across to. If the requestor is both a recorded and appropriate contact, it will help the LRCP determine more quickly where the asset list should be sent, for large organisations with multiple contacts.
We are not prescribing what format the asset list should take. As a minimum the asset list should include:
- An Asset Identifier (something the losing provider will recognise for a specific service in a subsequent match request)
- Service description (something the customer should recognise related to the service)
The LRCP must state who requested the asset list when sending the list out. This will help to ensure that the asset list is issued to the correct party. This will also help to prevent queries where a Business Customer contact did not expect to receive a list.
The LRCP may choose to provide other information (whether the service is in a fixed contract period, or where services are linked and where the removal of 1 service impacts another). Any additional information needs to be fact based and neutral and should not create any disincentives to switch. Nothing prohibits the provider from issuing a complete list of assets for the end user if it is easier to do so. An example is provided below.
Asset List ***ILLUSTRATION PURPOSES ONLY******
Account Name Ben’s Bread Factory Ltd.
Account Number ABC12345/AAS
Requestor: Mr B Bee
| Service Type | Our Reference | Site Address | Other Information |
| Voice | 01234 699123 | 35 The Avenue, Southampton, SO99 9XX | |
| Voice | 01234 654000 to 01234 654999 | 35 The Avenue, Southampton, SO99 9XX | DDI Number range |
| Voice | 03661 256500 | Non geographic (presentation number) | |
| Voice | 01234 699123 | 35 The Avenue, Southampton, SO99 9XX | Main Billing Number |
| Internet Access | FB16549 | 123 Highstreet, Manchester
M12 3ZZ |
1GB Internet Access Service |
| Internet Access | BK68943 | 123 Highstreet, Manchester
M12 3ZZ |
4G Backup Service |
| Internet Access | XX13595 | 123 Highstreet, Manchester
M12 3ZZ |
Network Reference ONT ABC13246RT4560 Port 1 |
| Internet Access | 12A6DA4F650E | 123 Highstreet, Manchester
M12 3ZZ |
MAC Address/Serial Number 12:A6:DA:4F:65:0E |
If the LRCP receives repeat requests for asset lists, these should be assessed and a decision made by the LRCP as to whether a new asset list is required or the last one generated can be resent if needed, i.e. there has been no changes to the customers assets to warrant a new one or in instance of rate limiting. The LRCP should advise where an asset list will not be required as an asset list has recently been provided. In this instance a response code should confirm this to the GRCP along with the date of last issue.
If the LRCP finds a single matching customer, they will also create a success response for the GRCP, including information on how the asset list will be sent to the customer (e.g. email / letter), if requested. Please note the following communication channels are the currently known methods of sending the asset lists. It is possible that LRCPs may select another method. This list may be extended over time.
| Method | Additional information |
| Masked email address: first few characters of “username” element and full “domain” element, all other characters replaced with *. If the information were sent by email, this property contains an obfuscated copy of the email address. The domain should be fully visible to aid the customer to identify the email hosting provider the email went to. It Is recommended to mask all but 2 characters of the email address. If the addressee is 4 or 5 characters, then all but 1 character must be masked, and if the addressee is less than 4 characters then all characters of the addressee must be obfuscated. For example:
***@hotmail.com d***@hotmail.com d****@hotmail.com d*****e@hotmail.com d******y@hotmail.com
|
|
| Post | A letter will be sent to the contact/billing address as held by the LRCP and there is no need for any additional information to be included in the response. |
3.8.1 BSW1.18 Generation of Switch Order Reference (SOR) by losing retail provider
If the LRCP finds a match, they need to generate and include a Switch Order Reference (SOR) in the response. The SOR will be a UUID as defined by IETF RFC4122 A Universally Unique IDentifier (UUID) URN Namespace.
Note that an SOR will expire after 180 calendar days from the date of generation for the purpose of raising a Switch Order Request or requesting an Asset List The GRCP can still update any planned switch dates in the event of delays. For a worked example of how the 180 days works in practice please refer to Appendix3: SLAs.
3.9 BSW1.15 LRCP creates an error response to GRCP
If the LRCP does not find a matching customer, they will return a match failure-response with an indication of failure. The failures (and possible GRCP responses) could be:
- Insufficient elements successfully matched.
- Customer reference number not found (or found as closed account, or with no IAS or NBICS).
- The GRCP could check that the customer has provided the correct LRCP and account number.
- Telephone number does not match.
- The GRCP could check that the customer has provided the correct telephone number.
- No match on business name.
- The GRCP could check that the customer has provided the business name as held by the LRCP.
- Address not found or does not match.
- g. the address does not match any associated with the customer.
The full list of error codes are provided separately in the Switching For Business Response Codes document. Note that some address element must successfully match for there to be a successful customer match.
3.10 BSW1.13 Customer receives asset list and request GRCP to match services
When the customer receives the asset list, they will contact the GRCP, who can attempt to match services to be switched against using the details passed on by the customer.
3.11 BSW1.14 Gaining retail provider sends (additional) service match request to hub(s)
Following the successful customer match the gaining retail provider will be able to make additional service match requests against the SOR. Each time a Service match request is made the following information is required:
- The service identifier (e.g. The telephone number or other Asset ID that the losing provider will recognise). This field is optional for IAS but is mandatory for NBICS.
- The type of service (NBICS, NBICS Range or IAS) is Mandatory. Some legacy products have both data and voice (e.g. FTTC) in this instance the line is directly linked to the CLI (voice) element and this should be used for matching purposes.
- Address information may be required to locate a service where no service identifier has been provided, no NBICS or in a multisite scenario. In these instances, the address used in the initial customer match associated with the Switch Order Reference Number will be used.
3.12 BSW1.7 Losing retail provider processes service match request
The losing retail provider will receive the match request from the hub(s) and will attempt to find a match. The algorithm adopted by the losing retail provider will have the following elements:
- Are the services linked to the quoted address, where no asset identifier is provided for an IAS?
- Are the services associated with the customer matched?
- Are the asset IDs valid and allow a service to be identified.
- Are the services live?
A customer match is required for service matches to be progressed. The customer match may be simultaneous, but a customer match cannot follow a service match. The Customer match allows the Switch Order Reference to be generated and may be followed by Service matches e.g. if an asset list is needed.
A match response should be provided for each service request. This may result in a scenario where some service matches have been successful and some fail.
Note that the LRCP does not need to search for any former customers with former services at that location.
3.13 BSW1.15 Losing retail provider replies with failure to match (service)
A response will be provided for each service match request. Any services which cannot be matched will return a match response with an indication of failure. The failures (and possible GRCP responses) could be:
- SOR not found or expired.
- The GRCP could recomplete a customer match and generate a new SOR.
- No live services found on the account or at that location.
- A switch is currently in progress (i.e. LRCP has an open switch order).
- Note that this could arise when a customer has cancelled another switch order with another GRCP[4], but the cancellation has not yet reached / been processed by the LRCP.
- Range error
- The telephone number range provided includes additional numbers, for services that the customer is not responsible for. Note a range error will always fail there can be no partial match.
- Customer is not responsible for the services within the match request.
- The service is not unique.
- Product type not supported. This is used when the LRCP product is neither an NBICs nor an IAS service and the switch cannot be actioned through the business switching process.
Where multiple service match requests have been made, a response will be individually provided for each service match requested. It is therefore possible that where multiple services matches are submitted at the same time, some matches could be unsuccessful and some successful. The switch can still be progressed for individual services, which were successfully matched.
3.14 BSW1.17 Gaining retail provider receives failed match response
The gaining retail provider will inform the customer of the failed response and may attempt to resolve the non-match. Resolutions could include:
- Correction to information already provided, such as correction of spelling of business name to match the variant held by the LRCP.
- Addition of extra information, such as additional service identifiers.
If the GRCP is able to correct or add information, they would send a fresh match request to the hub(s) (this can be completed using the SOR from the customer match if it is only the service match that failed).
3.15 BSW1.18 Losing retail provider finds a service match
If the losing retail provider finds the customer service listed within the match, associated with the correct business, and where provided at the correct address (for IAS) the losing retail provider should return a positive match response to the gaining retail provider (via the hub(s)). There are several key pieces of information that the losing retail CP must include in the response message that it generates to be sent to the GRCP:
- List of impacted services (this will include every service that have been queried in the match. In addition, where a strongly related service is directly impacted but did not form part of the service match, this must also be returned in the match response. For example, the LRCP has identified a service that was not requested to be ceased but will be automatically ceased if the switch is progressed. This would happen when switching a WLR voice line to another network provider would result in the forced cessation of an IAS service provided over the same copper line.
- Whether or not switching information has been sent to the customer from the LRCP – mandatory.
- Details about the services to be switched.
If sent, method of communication to customer of the switching information – mandatory.
RCPs who consume Openreach services are expected to be aware of the interdependencies, especially between copper-based services, such as WLR, MPF, ADSL and FTTC.
3.15.1 BSW1.8 Supply chain provision of information to support LRCP
The LRCP may need to invoke query services[5] provided by their supply chain. Notable examples include:
- Mapping from a supply chain service identifier (e.g. the identifier used by a wholesaler CP and known to the LRCP) to a service identifier used by the underlying network provider (and an indication of the network provider in supply chains where the LRCP does already know this information).
- The CUPID of the current Voice Communications Provider should be provided where available to support porting.
- WLR operators with no record of broadband service will need to invoke Openreach’s EMLC service to check if there is broadband on the line, perhaps with a different CP[6].
It is also open to RCPs to work with their supply chains to do bulk updates to their service asset information to add (or refresh) the above information, so that they do not need to rely on real-time responses from their supply chain. Refer also to rate limiting.
Supply chain service identifier details include:
- Access provider –May also be known as the infrastructure provider or network provider – it is the most upstream CP that owns the “kit in the ground”, e.g. Openreach, Virgin, full-fibre alt-net. Sky and TalkTalk are both voice operators, but where they use an underlying Openreach MPF service, so Openreach would be the correct access provider. Some LRCPs may need to query their supply chain to obtain this information.
- For IAS, there will always be a physical access provider, so the ACPID is mandatory.
- For NBICS, there may or may not be a physical access provider. For a VoIP NBICS, the physical network supports the IAS, and the VoIP runs over the IAS. We will define an ACPID to represent a generic VoIP access, so that this field can be positively populated with a recognised value (rather than just left blank and looking like missing data).
Network Operator information to be included by the LRCP in the match response. The LRCP must return the following information:
- Network Operator = The network operator providing physical connectivity for the service(s) successfully matched (represented by an Access Communications Provider ID (ACPID) mastered by TOTSCo).
- Network Operator service identifier type and value as follows:
- If the LRCP records the Network Operator ServiceId of a service:
- Identifier type = “ServiceId”
- Identifier = value of ServiceId, e.g. starting LL, SGEA or OGEA
- If the LRCP records an ONT Reference (Optical Network Termination) or equivalent, they should return 2 type/value pairs:
- Identifier type = “ONTReference”; Identifier = ONT Reference (or equivalent)
- Identifier type = “PortNumber”; Identifer = port number.
Note : If the LRCP has not recorded the port number, they should omit the second pair – the GRCP will then need to choose an appropriate port (likely there will only be a single working port)
o The network/access provider will be represented by a new identifier mastered by the Managed Access Provider (MAP)
- Access provider service identifier type and value – mandatory for some access providers, e.g. Openreach. If the GRCP uses the same access provider, they will be able to place an order with their supply chain targeting the existing infrastructure for transfer. This helps targeting the correct existing infrastructure and helps avoid erroneous transfers.
- Some RCPs will know a service identifier used by the access provider (e.g. an ALID used by Openreach).
- Other RCPs may need to query their supply chain (e.g. if they use a wholesaler, and that wholesaler exposes their own service identifier, e.g. TalkTalk expose a “CASR ref” to their retail CPs, and do not expose the LLU ServiceId or ALID used by Openreach).
- Some access providers support a number of types of service identifier, e.g. Openreach support DN, Partial DN, ALID and ONT Reference + port number. If the access provider supports different types, it is mandatory for the LRCP to return both the value and the type.
For further information about Openreach service identifiers and Openreach processes refer to section 6.7: Appendix 7.
3.15.2 BSW1.18 Method of communication to customer on the switching information from the LRCP
Under Ofcom General Conditions of Entitlement, the Gaining and Losing Providers must keep the customer informed throughout the switching process. For consumer like customers, the impacts of switching are likely to be needed to support informed consent to proceed with a sale.
The LRCP may choose to send the switching information by multiple methods and should indicate durable mediums used. E.g. if the full information is sent by letter, and the LRCP chooses to also send an SMS message advising only that an important letter is on its way (but the SMS does not replicate all the switching information), then letter is the only means which should be reported.
Where switching information is sent to the customer, it should be sent via the fastest means available or via a communication channel requested for contact by the customer.
Additional information must be provided alongside each method as follows:
| Method | Additional information | |
| Masked email address: first few characters of “username” element and full “domain” element, all other characters replaced with *. If the information were sent by email, this property contains an obfuscated copy of the email address. The domain should be fully visible to aid the customer to identify the email hosting provider the email went to. It Is recommended to mask all but 2 characters of the email address. If the addressee is 4 or 5 characters, then all but 1 character must be masked, and if the addressee is less than 4 characters then all characters of the addressee must be obfuscated. For example:
***@hotmail.com d***@hotmail.com d****@hotmail.com d*****e@hotmail.com d******y@hotmail.com
|
||
| SMS | Masked mobile number:
If the LRCP stores the SMS number in UK format, first and last three digits, all other digits replaced with *, e.g: *********13 If the LRCP supports SMS numbers in international format, the country code and first two significant digits after country code should not be masked, e.g: UK example: +44*********13 ROI example: +35********13 or (an alternative is +35********13 if easier to implement) The masked number may optionally include spaces (which should not be replaced with *) and (0)[7], e.g. +44 (0) **** ****13 |
|
| Post | Letter will be sent to the contact/billing address as held by the LRCP and there is no need for any additional information to be included in the response. | |
| Verbally | Impacts have been provided verbally to the customer. | |
| Not Sent | This is to be used if the LRCP does not issue impacts of switching for reasons other than rate limiting. | |
GRCPs must be able to handle a potential list and advise the customer which methods have been used. Where the impacts of switching have already be issued recently and there are no new updates. which response code should confirm this to the GRCP along with the date of last issue.
3.16 BSW1.19 Losing retail provider sends switching information to their customer
Where Switching information is sent to the customer, it should include as a minimum; that a switching match has been made, the identity of the GRCP, which services are being matched which if progressed, will be switched away and any early terminations charges. It is also considered best practice to highlight where other associated services may be impacted; for example, static IPs, linked software, or battery back-up.
The losing retail provider will send the switching information directly to their customer. If the provider holds an email address for the customer (and the customer has not previously asked for all future communications by letter), the provider will send an email communication to their customers. The losing provider should ensure that this email is sent without any unnecessary delay.
If the provider does not hold an email address (or the customer has previously opted out of email communication), the provider will send a letter using their print and dispatch mechanisms or other appropriate means.
Where a customer match is completed in isolation without service match information it may not be possible to give the full impacts of switching at this stage, as impacts may be service specific. In this instance the impacts of switching confirmation message should be used as an indicator as to whether and how the Losing Retail CP issues impacts of switching notices.
3.16.1 Rate Limiting
There is a legitimate worry about whether a malicious actor could use (maybe multiple) GRCP sales journeys to trigger dispatch of multiple switching information, or asset list requests, with the intent of causing nuisance to an individual, or of causing embarrassment to the UK telecoms industry.
This industry process permits LRCP to “rate limit” their dispatch of notifications with switching information, triggered by successful match requests. This may be applied when the switching information would not be materially different from previously sent information within a 31-day period.
If a RCP decides to implement a rate limit, in their match response, they should indicate the date of last dispatch of switching information, where the current request will be suppressed by the rate limiting. Rate limiting is optional for the LRCP.
The principle of rate limiting also applies to asset list production. In both instances a response code has been created to enable feedback that rate limiting has been applied.
3.17 BSW1.26 Gaining retail provider places order
After gaining and recording express consent from the customer, the gaining retail provider will complete any steps required for their own order that have not yet been completed. This includes agreeing a migration date with the customer:
- The customer may want a delay, e.g. to line up with the end of a commitment period with the LRCP.
- The provision of service via the GRCP’s supply chain may have a lead time.
- The provision of service may require an engineering appointment, and if this is for a customer facing visit, the customer will need to pick an available slot when they can arrange to be at home.
- The gaining supply chain may use a model where they reply with a committed date and any date quoted to the customer at the point of sale is aspirational.
For many RCPs, at this point the sales order is “submitted”.
3.18 BSW1.27 Customer receives order confirmation from GRCP
The step represents the receipt by the customer of all the information sent by the GRCP after the customer gives their express consent to the switch, and the GRCP starts processing their “customer order”.
4 BSW1.30 Raise Switch Order Request
In the previous section a customer order has been captured and submitted. For many RCPs this represents a transition from order capture to order processing.
A “customer order” in a typical RCP’s systems service may result in multiple “supplier orders”, for example:
- An order for delivery of equipment, such any hub(s)/router needed for broadband access.
- An order to set up the customer and their services on the RCP’s billing systems.
- An order for the underlying service from a network operator/ service provider.
In order to progress the switch from the LRCP, the GRCP will send a “switch order” request to the hub(s) for onward routing to the LRCP. For many RCPs, the Business switch order will be considered as another “supplier order” to be managed alongside all the other supplier orders.
The switch order effectively allows the GRCP to tell the LRCP that the customer has given express consent to the switch. It informs the LRCP of the proposed migration date), and which LRCP services must be ceased (either because they are being switched, or e.g. the customer no longer wants any voice service and is taking a broadband only service from the GRCP). Note that is in addition to any of the following existing order types:
- Number porting request (from voice provider in gaining supply chain to voice provider in losing supply chain).
- Order for intra network transfers (e.g. “transfer orders” into Openreach).
4.1 Content of switch order
The switch order should include the following information:
- Identity of the losing retail provider.
- SOR .
- List of services to be ceased. This list should match the services which were successfully matched in the match response that included the SOR.
E.g. if the match request was to cease IAS and retain NBICS, but the match response indicated that voice could not be retained, the GRCP can gain the customer’s acceptance that voice must also be ceased. The switch order must then include cessation of both IAS and NBICS.
- Note that where the match response indicated that a service could be retained, the switch order should omit that service – the switch order will only list the services that the LRCP should cease.
- Intended migration date.
The indication of intra-network transfer or number port may assist the LRCP in correlating the switch order with any unsolicited cease that their supply chain may send for the transfer or number port. This correlation will help the LRCP to understand that the unsolicited cease is associated with the switch order, and thus Cancel Other of those unsolicited ceases is prohibited.
4.2 BSW1.33 & BSW1.36 Losing retail provider receives switch order and confirms confirmation or failure
This step represents the receipt of the switch order by the LRCP. The LRCP must respond to the switch order with either an confirmation or a failure.
If the LRCP already has an open switch order against some or all of the services requested for cessation (whether from another GRCP or the same GRCP), they would reject the switch order for that particular service.
However, if their customer has placed a cease order, the LRCP should make every effort to accept the switch order, taking the migration date in the switch order as higher priority. RCPs may choose to cancel the customer’s pending cease order, and replace it completely with the details from the switch order, but they must inform the customer of the impacts.
Other possible reasons for rejection include:
- Invalid switch order reference.
- Switch order reference has expired.
- SOR value does not match to the combination of services being ceased.
- Services already ceased.
4.3 BSW1.41 Gaining Provider – Update Switch Order Request
During the switching journey it may be necessary for the switch date to be delayed or changes to the switch order itself. This could occur for several reasons including at the customer’s request or due to supply chain delays. In this instance, where a Gaining Provider becomes aware of a switch order change they should contact the Losing Provider(s) with these details.
The Gaining Provider must send an update to the Losing Provider(s) via the hub(s) with a switch order update request conveying changes to planned switch date. The planned switch date can not be a date in the past.
The message will include the Switch Order Reference, the services to be switched and the planned switch date for each service.
The GRCP has 31 days grace from the specified date to trigger the switch (e.g. provisioning is delayed by a few days). In the event that this period may be at risk (e.g. provisioning delay due to ongoing survey and planning work), the GRCP will need to send a Switch Order Update Request to revise the date. The planned date should always be either a present or future value date. If a back dated planned date is received, the recipient can return a failure message with response code 1203,1303 or 1208.
4.4 Losing retail provider sends notification to customer
If the LRCP accepts the switch order, they must send a notification to the customer:
- If all of the customer’s services are being ceased this will be a “sorry to see you go” (STSYG) notification.
- If any services are being retained or changed, the notification may be partly STSYG and partly notification of the impacts on the other services.
4.5 Losing retail provider should not initiate cease on a fixed date
It is important to note that the switch order will contain an intended planned switch date:
- The GRCP will have asked a customer to agree an intended switch date.
- The customer may have requested a delayed switch date, e.g. to fall after expiry of a minimum commitment period (to avoid ETCs) or to a date for engineering visit that suited them.
- Delays can be encountered, e.g. a difficulty encountered during an engineering visit, which delays completion past the original commitment date.
The LRCP should await confirmation that the cease should be triggered.
4.6 BSW1.70 GRCP handling of rejected switch order
If the LRCP sends a rejection of the switch order, the GRCP will be responsible for resolution of this rejection. The GRCP may need to consult with the customer, and will need to cancel their order with their supply chain if they cannot fix the issue with the switch order.
E.g. if the LRCP rejects a switch order as it has another open switch order, the possible resolutions include:
- Full cancellation of the GRCP’s “customer order” if the customer advises that they are proceeding with another GRCP. In this case, the GRCP must cancel their order with their supply chain.
- If the customer advises that they have cancelled the order with another GRCP, this could be a timing issue, and a re-submission of the switch may be accepted (once the LRCP has received and processed the cancellation of the first switch order). In this case, the order with the supply chain would not be cancelled.
4.7 BSW1.29 Gaining supply chain raises number port order(s).
If the switch contains a number port, the GRCP via their supply chain[8] will raise a port order with the losing voice provider, and also with the range holder if different, using the most efficient method available as identified during the matching process.
The porting process itself remains unchanged,.
It should be noted that even though a switch order may be accepted, it does not prevent a port request from being subsequently rejected for other reasons. Where a port is rejected and the issue cannot be resolved, then the customer may decide to cancel the switch.
4.8 BSW1.60 Gaining supply chain completes order(s)
The supply chain will complete provision or transfer of service(s) and inform the GRCP of completion.
If the voice order involves number porting, that may be a separate supply chain, and the completion for the porting may come from a different source and at a different time.
4.9 BSW1.62 Receipt of notifications of unsolicited cease(s) by LRCP
The LRCP may receive various notifications around the unsolicited cease(s), from initial notification to final completion. The supply chain may generate separate unsolicited ceases for the voice and broadband, and number port may result in a separate unsolicited cease.[9]
Openreach have advised that they are not changing their managed cease notifications, and they will continue unchanged for an intra network switch or a number export from WLR (e.g. KCI1, KCI2, KCI3)
4.10 BSW1.63 Gaining retail provider receives order(s) completion from supply chain
The GRCP will receive notification from their supply chain of completion of their provision or transfer order(s). There may be several notifications, e.g. if their supply chain has separate orders for voice and broadband, or the order involves number porting via a different supply chain (e.g. for a VoIP service).
The GRCP will send confirmation to the customer of completion of the switch and activation of their new service(s).
The GRCP will also send the hub(s) a “trigger message” for the switch order, to trigger the LRCP to cease their service(s) and complete the switch order. As there may be a period of dual running, this may be triggered at a later point in time.
While GRCPs should send the switch order trigger request on the activation date with that date included in the message (and avoid sending late trigger messages). LRCPs should accept late trigger messages, regardless of how far back the activation date is. LRCPs are strongly encouraged to monitor receipt of late trigger messages, and engage with GRCPs who regularly send trigger messages with significant back-dating. Note also that for switches involving either an intra-network switch (e.g. a “CP migration” on the Openreach network) or a number port, the completion of those elements may have already triggered the LRCP to stop their billing, and the late arrival of an SforB trigger request may have no impact.
4.11 BSW1.64 Customer receives confirmation of order completion
The customer will receive confirmation from the GRCP, e.g. “welcome to service” messages.
4.12 BSW1.71 Completion of switch order by LRCP
The LRCP will receive the switch order trigger message.
Note that the original switch order will have included an intended switch date, but the provision of service by the GRCP’s supply chain may have been delayed. The LRCP must not trigger any cessation activities until they receive the switch order trigger message, even if the original migration date has passed. The switch order trigger message effectively provides a final switch date.
For an inter network switch, the LRCP must send a cease request(s) to their supply chain.
For an intra network switch, the handling will depend on their supply chain. E.g. Openreach will reject a cease request if their managed cease order is open or complete, so the LRCP should not send a cease request to Openreach.
In both cases, the LRCP will need to cease other services as appropriate and trigger other actions, such as prompting the customer to return equipment.
The LRCP will also need to update their billing systems. If they did not process the switch order trigger message on the day it was sent, they may need to back-dating the cessation date. The correct cease dates will need to be updated on their billing systems The LRCP will then send a final bill to the customer which may include charges for any applicable notice periods.
Some terms and conditions of the LRCP contract may continue to apply. E.g. charges for the non-return of equipment.
4.13 BSW1.72 Cease of service(s) by losing supply chain
When the LRCP receives the switch order trigger message, for an inter network switch, they will ask their supply chain to cease service(s).
This may be the first notification(s) that the losing supply chain receives for the overall switch process.
4.14 BSW1.74 Losing retail provider notifies GRCP that switch is complete
The losing retail provider will send a response to the switch order trigger message to the GRCP via the hub(s) – effectively this message represents acknowledgment by the LRCP that they now need to complete the switch order by the LRCP.
The sending of this message might be delayed by processing either by the LRCP or their supply chain, e.g. if cessations are only processed on a working day. However, the LRCP must not delay the response until all payments received or return of equipment by the customer. This step provides confirmation that the LRCP will undertake all relevant actions on the services relating to the order trigger message.
There are limited scenarios where the trigger message should be failed. This should only be where there is an invalid or missing activation date, cease already completed, switch order already cancelled, and the order date has expired.
4.15 BSW1.76 Gaining retail provider receives notification that the switch is complete
The GRCP will receive notification that the LRCP has acknowledged that they now need to complete all their steps to cease service(s) and billing.
Note that this response may be delayed by processing either by the LRCP or their supply chain.
GRCP s may choose to close their customer order when they have received completion from their supply chain (e.g. if having an open order prevents the new customer from raising any fresh orders). However, the GRCP should be able to handle the LRCP response as a late update to their customer order.
5 Cancel Own
Having successfully placed the switch order and with that switch order being ‘in-flight’ with both GRCP and LRCP, the customer may for whatever reason choose to cancel that order. Where the customer chooses to cancel the switch order via the GRCP with whom they placed the original switch order, this will be referred to in this document as a “Cancel Own”[10]. Such cancellations will be subject to the standard PONR restrictions imposed by the gaining supply chain.
5.1 Customer wishes to cancel the switch
After placing their order and providing their express consent to proceed with the process the customer is within their rights to cancel the order with the GRCP. Where the switch order is either complete or has passed the point of no return (PONR) as defined by the GRCP a Cancel Own request would not be processed.
The GRCP should be in a position to understand the PONR timing imposed by their supply chain (e.g. for Openreach, it is typically 4pm on the day before the commitment date), and how much extra safety margin they apply (e.g. many RCPs using Openreach apply a 3pm cut-off for capture of a cancellation request, so that they can get it to Openreach before 4pm).
5.2 BSW1.50 GRCP cancels the provision / transfer order(s) and switch order
Once the customer has requested that the order be cancelled, the GRCP must:
- Notify the LRCP of the switch order cancellation via the hub(s)
- Send an order cancellation request to the gaining supply chain to initiate cancellation of the provision / transfer order.
5.3 BSW1.55 Gaining supply chain cancels provision / transfer order(s)
Once the switch order cancellation has been initiated the gaining supply chain should cancel down the provision / transfer order(s). It is expected that GRCP’s and their supply chains will follow their existing Cancel Own processes.
5.3.1 Gaining supply chain notifies losing retail provider of cancellation of unsolicited cease
In an intra network switch, the supply chain will have notified the losing retail provider of unsolicited cease(s) triggered by the GRCP placing transfer order(s) for the switch.
As per the existing cancel own process in place the gaining supply chain will notify the losing retail provider that those unsolicited cease(s) have been cancelled.
5.3.2 LRCP receives notification of cancellation of unsolicited cease(s)
In an intra network switch, the LRCP will receive the notification of cancellation of the unsolicited cease(s). The LRCP will take the appropriate steps to clean up their records of the unsolicited cease(s)[11].
5.3.3 GRCP creates a switch order cancellation request
Alongside sending an order cancellation request into the gaining supply chain the GRCP will also need to create a switch order cancellation request message and send it to the LRCP via the hub(s). This request message should include:
- The switch order reference
- A cancellation reason code as appropriate (to be defined)
5.4 BSW1.55 LRCP receives switch order cancellation request
Once routed correctly the LRCP will receive the switch order cancellation request from the GRCP.
Note that in an intra network switch, the LRCP will also receive notification of cancellation of the unsolicited cease(s) from their supply chain. The notifications from the hub(s) and from the supply chain may arrive in either sequence and the LRCP must be able to handle this.
In most cases, the LRCP will not need to cancel with their supply chain:
- For an intra network switch, the LRCP should receive notification from their supply chain of cancellation of the unsolicited cease(s). So the LRCP does not need to initiate cancellation.
- For an inter network switch, the LRCP is very unlikely to have yet told their supply chain about the expectation of a cease on the future switch date, so there would be no pending order with their supply chain to cancel.
But in some scenarios, they may need to inform their supply chain, depending on the processes used by their supply chain.
5.4.1 LRCP responds to switch order cancellation
When the LRCP received the original switch order request they will have created some record of this.
The LRCP will need to update their record of the switch order (e.g. record it as cancelled), wait for a response from their supply chain and then send a response to the GRCP (via the hub(s)) to confirm that they have received the switch order cancellation and completed their processing.
6 Appendices
6.1 Appendix I: Out of area geographic numbers
Some CPs have missed the recent Ofcom guidance that geographic numbers can be taken out-of-area, notable when a customer moves premises and the voice network can support the retention of their existing number (notably in “All-IP” networks).
GRCPs are reminded that they need to check that their gaining supply chain can support any number that the customer wishes to retain, in addition to checking whether it can be imported. Supply chains may offer a single combined check, or the GRCP may need to invoke separate checks.
The supply chain might not support the number for technical reasons (e.g. older PSTN technology typically restricted the number ranges that could be hosted on an exchange, whereas “All-IP” networks typically have less constraints) or for commercial reasons (e.g. calls from 028 numbers to the Republic of Ireland may have a cheaper rate, so supply chains may constrain 028 number to Northern Ireland only and vice versa).
6.2 Appendix II: Address Quality- Structure of a UK address
It is expected that retail CPs will use authoritative sources of quality address data, such as:
- Ordnance Survey’s AddressBase products, covering addresses in GB.
- Ordnance Survey’s AddressBase Islands products (which includes Northern Ireland).
- Ordnance Survey NI’s Pointer products, covering addresses in Northern Ireland.
- Royal Mail’s PAF products, covering all of the UK.
- Or a commercial provider who aggregates all the above data.
It is also expected that retail CPs will understand the structure of a UK address, including sub building name, building name, building number, dependent thoroughfare, thoroughfare, double dependent locality, dependent locality, post town and postcode (and not just “line 1”, “line 2”). Readers unfamiliar with the structure of a UK address may wish to consult the Royal Mail PAF Programmers’ Guide at https://www.royalmail.com/marketing-services/address-management-unit/address-data-products/programmers-guide. (Note that most modern addressing products do not split thoroughfare into name and description – PAF started in the days of Summary of match information to be provided by the LRCP.
The structure of a UK address consists of the following elements:
| Element | Comments |
| Sub building name | E.g. ‘Flat 1’, ‘Apartment 1’ |
| Building name | E.g. ‘Rose Cottage’, ‘Mandela House’ |
| Building number | E.g. ‘1’, ‘1A’, ‘101-102’ |
| Dependent thoroughfare | |
| Thoroughfare | Aka street name |
| Double dependent locality | |
| Dependent locality | |
| Post town | Mandatory |
| Postcode | Mandatory |
This structure was initially documented by Royal Mail in their PAF Programmer’s Guide.
Note that the PAF Guide defines some very strict rules:
- PAF building numbers can only be purely numeric, and values such as ‘1A’ and ‘101-103’ are held as building name. Most modern implementations and data sources permit values such as ‘1A’ and ‘101-102’ as the building number.
- The original PAF split thoroughfare and dependent thoroughfare into a separate name and descriptor with a standard list of approximately 200 descriptor words (e.g. ‘Avenue’, ‘Street’). Modern implementations and data sources combine the name and descriptor as a single string.
PO Box number is intentionally omitted from the above list, as it could not be a valid service address.
6.3 Appendix III: SLAs and response times
There are several expected response times, expiry periods, audit trial periods and other SLAs.
Within the SLAs we refer to simple and complex switching.
A simple switch is defined as:
- 5 or less services to be switched as part of the match request.
- Single location of services.
A complex switch is defined as:
- More than 5 services to be switched as part of the match request. Single location of services where greater than 5 services to be switched or Multi locations.
The SLAs below are proposed for the purposes of review and comment:
These SLAs should be considered as the latest date. For a better customer experience and as best practice CPs should respond as soon as practicable to do so and should not deliberately delay actions.
| Item | SLA and comments |
| Responses to Customer match, service match and asset list requests. | 1. Customer Match. Simple and complex switch scenarios must be completed by the end of the next working day following receipt.
2. Service Matches. For simple switches the match SLA is by the end of the next working day following receipt. For complex switches:
· 1-5 services, single match or multiple locations, SLA is by the end of the next working day following receipt.
· 6-200 end of three working days following receipt of match request. Or less than 6 but multiple locations.
· 201 + 5 working days following receipt of match request
Where matching is fully automated responses should not be artificially delayed and should be returned as soon as possible. Where a service relates to a continuous number range this is treated as a single match.
Where the service match request is split into multiple requests i.e. orders which would be individually treated as simple but fall into complex when added cumulatively will fall to the longest SLA, with the date of receipt being the date that the final match request was received by the LRCP in the 24- hour period. Where the gap between service match requests is more than close of business next working day, the original SLA should be met.
|
| Customer Notification of Switch | Where a Losing Retail CP decides to send the customer, a communication keeping them informed of the impacts of leaving and notice of an intended switch, the communication should be issued as soon as soon as practicable to do so. |
| Expiry of an SOR | A business SOR is valid for 180 full calendar days from date of generation. Both the gaining and losing retailer should store the date in which the SOR was generated.
An attempt to place a switch order using a business SOR more than 180 calendar days old will be rejected by the LRCP. With day 1 being the next calendar day following SOR being generated. For example: · SOR generated 01/01/2026, · Day 1 = 02/01/2026 Day 180 = 30/06/2026. · New asset matching and new Switch order Requests linked to the SOR dated 01/07/2026 (and onwards should be rejected). Any updates to the services already being switched can be extended. |
| Retention of SOR by LRCP | The LRCP should retain the SOR for at least another 180 calendar days months after expiry (so that the response can be that SOR is expired, rather than invalid if it were already deleted).
LRCP’s housekeeping and audit trail policies may mean that they retain expired SORs and other match audit trail information for a longer period. (as above). |
| Asset List | All reasonable efforts should be made to send the asset lists as soon as practicable to do so. For large asset volumes associated with the same SOR asset lists should be issued by the end of two working days at the latest.
For reduced asset volumes (5 or less services)the asset list should be issued by the end of the next working day at the latest. |
| Confirmation or failure switch order | Where there are 5 or less assets linked to a specific switch order the SLA is by the end of the next working day at the latest.
Where more than 5 Assets or where multiple switch orders for the same SOR the cumulative volume is considered. the SLA is by the end of two working days at the latest. |
| Confirmation or failure of an amendment or cancellation of a switch order. | For simple switches the SLA is by the end of the next working day at the latest.
For complex switches the SLA is by the end of two working days at the latest. |
| Latest date to trigger an open switch order | The GRCP must trigger an open switch order within 31 calendar days of the migration date (counting the migration date as day zero). If the migration date was changed in a switch order update this is relative to the migration date in the last update.
This period is intended to account for typical delays, such as engineering issues being encountered on the installation date (which are typically resolved within a few days), or a gaining supply chain which use a “commit on CCD” model. If the switch order is not triggered within 31 calendar days, the LRCP may receive a rejection notification to the GRCP. For example: · Migration date 01.01.2026 (Day zero) · Day 31 = 01.02.2026 · Requests received 02.02.2026 onwards will be rejected |
| GRCP notification to LRCP of completion of switch. | The GRCP should confirm that the switch has completed, and services are ready to be ceased or cancelled by the LRCP as soon as practicable to do so. |
A working day for matching purposes is ‘generally’ defined as Monday to Friday 9-5 excluding public holidays, based upon English Bank Holidays.
6.4 Appendix V: Customer References and Asset Lists
Consideration should be given to the type of asset list request and what would be returned based upon the losing retail communication’s provider account structure.
Retail CPs are encouraged to provide a summary of how account information is structured to support Business customers switch.
An industry guide has been created ‘Switching For Business Asset List Guidance’ to help explain what account types exist across industry, and what asset information should be returned in consideration of different account structures and the asset request type.
6.5 Appendix VI: Matching Guidance
Having identified key differences between consumers and businesses a different recommended match approach has been taken with SforB. The approach focuses on positive points of match rather than incorrect information leading to rejection. This has been necessary due to business account structure differences, differences in the way business names are recorded, along with the likelihood of multiple addresses being associated with a business (E.g. HQ, Service address, billing address) and address complexity.
It is recommended that a scoring mechanism be used for business switching to support a positive customer match, awarding points for each successful match element rather than ending the matching process at the first key failure.
Scoring is based on an address element and a customer identifier element. A summary of the best practice is provided below:
- If mandatory information is not provided (Business name, full address and LRCP details) the match will automatically fail validation checks without assessment.
- The LRCP must always be correct otherwise a successful match can never be achieved as the message will not route to the correct retailer.
- 5 points or more are required secure a successful customer match.
- Part of the address must always match to achieve a successful customer match.
Address Information:
- The first lines of the address up to and including street name as well as full post code (or UPRN and Post code full match) are awarded 3 points. Address format guidance is provided in Appendix 2 of the GPL Business Switching Industry Process Design. All address elements should conform with standard PAF formatting rules in the messages. When processing the request, the losing provider will ignore case sensitivity and must be aware that not all providers will format the address in the same way, some lines may be in different positions, possibly concatenated together, therefore matching is not a simple line-to-line comparison and should allow for variations in formatting.
- The UPRN will be treated as equivalent to address where they match with a full post code match. Although an incorrect UPRN can still result in a positive match if other correct address information is provided. Not all LRCPs use UPRNs and where this is the case an actual address should be provided by the GRCP. If a UPRN is presented, then as long as the postcode is also a match, the losing provider can consider the address a match without having to compare the address line by line. The losing provider may do a full comparison, if more appropriate for the way they manage addresses.
- Where the postcode matches on the outcode and the first digit of the incode (i.e. only the last two letters are different), this is treated as a partial post code match but is successfully combined with the first lines of the address up to and including street name awarded 2 points.
- Where the postcode matches on the outcode and the first digit of the incode (i.e. only the last two letters are different), this is treated as a partial post code match and is awarded 1 point.
- A Headquarters, Billing or Service address are permitted for the address match.
Customer Identifiers
In order to achieve sufficient points for a successful match, additional customer identifiers must be provided. The number of points needed will vary depending on address quality. Customer identifiers and associated points when correct:
- A unique customer identifier (always recommended) such as an Account Number/Account Reference/ or Switch identity code where successfully matched is worth 3 points
- Business Name. LRCPs should allow fuzzy match logic, LTD, Limited, etc. A correct business name match is worth 2 points.
- An IAS service identifier is not typically in the public domain and where correct 3 points are awarded. If multiple IAS service identifiers are provided for a customer match a maximum of 3 points are awarded.
- A Service identifier NIBICs or (Directory Number). Where correct, 2 points are awarded. If multiple NBICS service identifiers are provided for a customer match a maximum of 2 points are awarded.
Asset List Matches
- A correct unique customer reference (such as an account number) must be provided before an asset list is issued. Where this is not provided an error code should be issued in relation to the asset list, but it may still be possible to complete a customer match.
- The GRCP can still request an asset list after the initial customer match.
Fuzzy matching
Fuzzy matching logic is expected to be applied on the business name. For example, if ‘Ben’s Bread Limited’ is on the LRCP’s system but a match request is raised for ‘Bens Bread Ltd’, this should not be rejected. Equally, If Mr C Hip is listed on the current provider’s system but a match is requested for Mr Charlie Adam Hip on the match request this would be considered an acceptable match.
In general, business name matching is often based on the “legal entity” name. For a sole trader, the legal entity is the individual, even if they also use a “trading as” name. Where the GRCP captures and the LRCP holds the name of the sole trader, this should be a successful match, even if one or other have also captured and hold the “trading as” name.
6.6 Appendix VII Specific Details for Openreach
This Appendix contains details that are only relevant to RCPs who purchase services from Openreach (directly or indirectly).
6.6.1 Openreach access service identifiers
Openreach support several types of identifiers for their services / lines:
- WLR Directory Number (DN).
- ServiceId
- For MPF lines, this starts LL
- For SOGEA, this starts SGEA
- For FTTC and FTTP, this starts OGEA
- Access Line Id (ALID) – MLPA[12] returns an ALID for each copper line. The ALID is not the same as either the WLR DN or the ServiceId.
- FTTP also has an ONT Reference and data port number.
- Over the years Openreach has supplied optical network termination units (ONT) with either 4 data ports + 2 voice ports, 1 + 1 or most recently 1 + 0.
- An FTTP ServiceId (starting OGEA) refers to service on a single data port.
- ONTs also have a visible serial number – this is also exposed via EMLC. It cannot be used as a search input, but could be cross-checked with a value supplied by the customer if there is a query on matching the correct ONT.
The data returned by EMLC[13] depends on what input is given:
- When EMLC is invoked with a ServiceId corresponding to a copper line, the ALID is returned (in the ServiceInformation block for GEA).
- When EMLC is invoked with a WLR DN, the DN is reflected in the response (instead of the ALID).
- When EMLC is invoked with a ServiceId corresponding to an FTTP service, no ServiceInformation blocks are returned, and there is no direct linkage to which ONT or port number corresponds to the OGEA ServiceId.
- (EMLC can also be invoked with other inputs, but this section is focussing on invocation using the details of an existing service returned in an SforB match response.)
For an intra-Openreach switch, it is extremely desirable to ensure that the GRCP is targeting the correct line or fibre service for transfer. The LRCP will know either the ServiceId or WLR DN, and MLPA will expose only the ALID to the GRCP.
6.6.2 Network Operator information to be included by the LRCP in the match response
The LRCP must return the following information:
- Network Operator = Openreach (represented by a access provider id mastered by TOTSCo).
- Network Operator service identifier type and value as follows:
- If the LRCP records the Openreach ServiceId of a copper service:
- Identifier type = “ServiceId”
- Identifier = value of ServiceId, e.g. starting LL, SGEA or OGEA
- If the LRCP records the WLR DN:
- Identifier type = “PartialDN”
- Identifier = last 2 digits of full DN
- If the LRCP records the ONT Reference, they should return 2 type/value pairs:
- Identifier type = “ONTReference”; Identifier = ONT Reference
- Identifier type = “PortNumber”; Identifer = port number.
- If the LRCP has not recorded the port number, they should omit the second pair – the GRCP will then need to choose the appropriate port (likely there will only be a single working port).
- It is hoped that all RCPs consuming Openreach FTTP have stored the ONT Reference and port number (or can retrieve them from their supply chain).
- ONT reference (and port number if available) must be returned if available to the LRCP.
- The FTTP ServiceId (starting OGEA) must only be returned if the LRCP does not have the ONT reference.
- For ease of matching, the spelling of the identifier types are intended to match the spelling of the XML tags used in the Openreach dialogue services.
- LRCP service identifier as follows:
- If the LRCP has their own service identifier, they should send this value.
- If the LRCP stores the WLR DN as their service identifier, it is recommended that the LRCP encrypt the WLR DN.
As a reminder, it is not mandatory for the customer to provide their existing DN – the customer may not remember the DN of a landline service that they don’t use, or may not be aware that they have an existing landline service and DN – or the customer may simply want a broadband only service, and the GRCP does not wish to expend call handling time to capture the DN. The recommendation to encrypt the DN is to avoid un-necessary exposure of the DN to the GRCP, and any potential data protection impacts (as is the guidance to return partial DN as the access provider service identifier).
6.6.3 Process to be followed by GRCP
The GRCP should already have checked the service availability at the address, before invoking the SforB match process.
When they receive the match response with the access provider as Openreach, they can recognise the switch as an intra-Openreach switch.
- If the LRCP has provided an Openreach ServiceId for a copper service (MPF, FTTC or SOGEA):
- The GRCP should invoke EMLC using the ServiceId and extract the AccessLineId (ALID) from the ServiceInformation block.
- The GRCP should then check that this ALID was returned in the MLPA response for the chosen Openreach NAD key – this may be a fresh MLPA call, or a cached response from the initial check for service availability.
- The transfer order should be placed using this ALID.
- If the LRCP has provided a PartialDN
- The GRCP should check that this PartialDN was returned in the MLPA response for the chosen Openreach NAD key – this may be a fresh MLPA call, or a cached response from the initial check for service availability.
- The transfer order should be placed using the ALID of the line with the matching PartialDN.
- If the LRCP has provided an Openreach ONT Reference:
- The GRCP should invoke EMLC using the chosen Openreach NAD key, and verify that an ONT is returned with the same reference.
- If the LRCP did not provide a port number, the GRCP will need to choose the most appropriate port (
- The transfer order should be placed using the ONT reference and port number.
- If the LRCP has provided an Openreach ServiceId for an FTTP service:
- The GRCP should invoke EMLC using the ServiceId. There will be information on at least one ONT, and no ServiceInformation block.
- The GRCP should also invoke EMLC using the chosen Openreach NAD key, and verify that an ONT is returned with the same reference.
- The GRCP will need to choose the most appropriate port
- If there are multiple ONTs and/or multiple working ports, the GRCP may need to seek further input from the customer, e.g. the ONT serial number, the connected port.
- The transfer order should be placed using the ONT reference and port number.
6.6.4 Switches and transfers with a pending cease
Refer to the “Switching For Business Open Orders – A best practice guide”, for more information about open orders and guidance as to how these should be handled during the Switching for Business process.
[1] https://www.ofcom.org.uk/__data/assets/pdf_file/0020/232058/statement-quick-easy-and-reliable-switching.pdf
Statement and Consultation: Quick, easy and reliable switching
General Conditions of Entitlement – Unofficial Consolidate version
[2] This document uses the term “losing retail provider” to refer to the RCP who would be the LRCP if a switch order were to be placed, and only uses the term “current retail provider” where it makes linguistic sense (e.g. the phrase “the customer will not know the RCPID of their current retail provider” reads more easily than “… the RCPID of their losing retail provider”).
[3] The format of account number or reference varies between RCPs. E.g. BT account references are two letters followed by eight numbers, and are commonly termed the “account number” even though they are not purely numeric. The Ofcom consultation and statement exclusively used the term “account number”. References in this document to “account number” do not imply a purely numeric value.
[4] Or even with the same GRCP – e.g. the GRCP has encountered a failure on its original order and has issued a replacement order on behalf of their customer, but has not allowed enough time for the first order to be fully cancelled at the LRCP.
[5] Openreach term these as “dialogue services”, but other network/access providers may not use this terminology23 Openreach EMLC service returns the CP who is directly paying for the broadband service (e.g. BT Wholesale), and do not expose the RID of the retail CP. Hence the intentional use of “CP” rather than “RCP” in this paragraph
[6] Openreach EMLC service returns the CP who is directly paying for the broadband service (e.g. BT Wholesale), and do not expose the RID of the retail CP. Hence the intentional use of “CP” rather than “RCP” in this paragraph.
[8] E.g. for WLR any number port request is included with the “transfer order” raised in Openreach, and Openreach raise any required NPOR/NPAR in the background. In other cases, the GRCP will raised a port request into their voice provider who will raise the NPOR/NPAR. In other cases, the GRCP may raise the NPOR/NPAR themselves.
[9] Openreach will consolidate transfer of WLR and any associated number port into a single managed cease notification for the downstream LP. The network functions of Sky and TalkTalk may do similar for their downstream retail divisions or retail CPs. With the move to VoIP, CPs are increasingly required to handle porting separately from Openreach.
[10] The terminology of “cancel own” and “cancel other” was used in the former NOT+ process and rules, and is thus recognised by many in the industry, and retained in this industry process.
[11] The LRCP may delay creation of a “customer order” until they receive notification of triggering of the switch order. So we’re being careful not to use the term “order” where for some RCPs, there may not be an “order” at this point in time.
[12] Manage Line Plant Availability (MLPA) is an Openreach dialogue service which returns the available copper lines at an address.
[13] Enhanced Manage Line Characteristics (EMLC) is an Openreach dialogue service which returns information about both copper and fibre services.