Service Provisioning encompasses both externally visible activities as well as internal facing ones and may also include interactions with third part suppliers and partners for some or all the elements of the order.
Service Provisioning relates not just to orders received from customers, and from partners, but also for orders generated by internal teams, for example as part of a network expansion. It is also important to highlight that an order can be a request to start a new service, or to modify or cease an existing service, or multiple combinations of these.
Service Provisioning will typically involve a wide range of applications and systems within the CSP (Communication Service Provider), including the order capture system, CRM (Customer Relationship Management), billing, product catalogue, inventory and stock control systems, third-party systems, network elements and network management systems; workforce management applications; and monitoring and assurance applications.
Additionally, it is likely to include jeopardy management processes to ensure that delivery is performed within target SLAs (service level agreements), and if not, the operation of fallout management procedures. When things go wrong, or go too slowly, progress and escalation procedures are invoked to ensure appropriate communications are made to the relevant stakeholders (including the customer) at the relevant times.
Service Provisioning begins with the capture of the order. For customers, this may be performed by the customer visiting the telco website, using a mobile app, by contacting the contact centre, by visiting a retail store or by a partner’s channel.
Order Capture can be a long-running process with multiple options and variations before a final decision is made and the order is submitted.
During this time, the Order Capture processes must support both multichannel and omnichannel experiences for the customer, for example enabling them to begin, run and complete the process in an e-commerce experience, or by commencing the process on a web page, subsequently completing it with a Contact Centre experience.
The submitted order may contain multiple line items, each for a separate product; each line item may have multiple sub-items depending upon the structure of the product as defined by the CSP.
Each order item and sub-item will contain specific configuration parameter values (e.g., bandwidth, channel list, location) relevant to the product, as well as an indication of whether the item is to be created, modified, or ceased; additional operations – such as suspended and resumed, may also be supported.
The customer account for the order must be created (Account Creation) using customer-supplied data, for a new customer, or re-validated for an existing customer. Depending upon the type of customers a complex hierarchy and interrelated set of accounts may need to be established.
Commercial and business validations may cause the rejection of the customer, for example based on their address location, their credit score, or their market segment.
Order items are validated according to defined business rules.
The items in the order are then validated according to defined business rules, for example:
- Geographic rules: Are the products ordered available for purchase and/or delivery at the requested location
- Regulatory rules: Is the customer allowed to purchase the ordered products
- Commercial rules: Is the customer allowed to purchase the requested combination of products
- Technical rules: Are the products compatible with existing services purchased by the customer
If the order contains a request to port out a number, the CSP may perform verification that the number is in a number block currently owned by the CSP, that it is assigned by the CSP to the customer requesting the porting out, and that the customer services with which it is associated is in a commercial and technical state to allow it to be ported out (for example, that the service has been active for at least 90 days).
Validation failure may result in the order being rejected completely, and the customer being notified, or in the customer being contacted to understand their requirements and to amend the order accordingly.
Once the order has passed validation, it is then decomposed (Order Decomposition) into a service order, translating the order line products on the customer order into internal services that will be used to deliver them.
This translation is data driven using information in a product catalogue. The product catalogue will contain not just services implemented by the CSP, but also component products offered by the CSP partners and suppliers, which must be managed as they change.
The resulting service order is then orchestrated across the physical, logical, and 3rd-party processes necessary to deliver it. Depending upon the type of services required, this may be a simple linear sequence of activities, but for more complex services there may be many separate activities with a convoluted web of inter-dependencies.
Activities may need to run in sequence, or in parallel with other activities, or may be able to start but not finish. Some activities may have a short duration, whereas others – for example, related to the installation of last-mile connectivity – may last for weeks or months.
Typically, the first step is to create – or to re-validate –billing accounts in the billing system (Billing Initialisation), which are linked to relevant usage, payment, and reporting accounts, as necessary. Any one-time charges (OTC) related to the customer order – for example, Wi-Fi router fees, installation fees, or early-termination fees – are added to the account.
For new services, the usage account(s) may be activated, to eliminate the chance of revenue loss that may arise from the time the service is technically active to when the customer is informed.
When the CSP resells a supplier or partner product ‘as-is’ – for example, a 6-month subscription to a streaming service, then there will be interaction with the supplier’s Order Capture process to submit an order for that.
Depending on the complexity of the resold product, and on the interface capabilities of the supplier’s systems, this may be a fully automated action, or it may require some manual activities. The integration with the supplier’s systems will be through a previously agreed channel (e.g., website, email, set-top-box user interface etc); the progress of the submitted order must be managed, and changes both ways appropriately communicated. Upon completion of the order there may be an acceptance process to undergo.
For some types of products there may be follow-on activities within the telco, and/or recording in the telco’s inventory systems reference identifiers supplied by the third-party.
The Logical Design and Assign activity results in any logical resources (numbers, VPNMs, circuits, etc) related to the requested services being created, modified or deleted, as necessary. This will involve interaction with at least one, possibly many, inventory systems.
The logical resources are selected for use by the service according to the service-specific technology rules, reflecting the CSP-defined service architecture (and intended, for example, to ensure correct service operation as well as avoiding network element performance problems), and their availability in the inventory system is updated accordingly.
Different service types (e.g., SIP, IPVPN, Mobile, IPTV, etc.) will require several types and different combinations of logical resources, and there will be business rules, technical standards and equipment vendor recommendations which will affect which resources may be allocated for a given service.
Typically, logical resources will transition through a lifecycle.
An example:
The specifics of the service order will determine how the resource is moved through these states.
The completion of the Logical Design And Assign will affect which of the following activities need to be performed, and in what order
Physical design and assign processes include the identification and specification of any physical resources required to complete the order. This may include:
- CPE such as modems, routers, set-top boxes, and mobiles
- New physical connections (copper, Coax, fibre) either from the CSP’s equipment to the customer location, or between CSP equipment.
- New street-side distribution cabinets.
- Additional cards, racks or similar which are required to be installed in the CSP data centres.
- New network elements to be installed in the CSPs data centres or telephone exchanges.
Some of the physical equipment may need to be shipped to the customer for new service order line items; for modify or cease order lines existing equipment already in the customer’s possession may need to be returned/retrieved for recycling or reuse initiatives.
Stock may be picked and shipped from the telco’s own warehouse, or they may have outsourced this to the stock vendor or another third party.
Whatever the implementation, the telco must ensure that the equipment is correctly received by the intended recipient, and where not must have in place appropriate procedures to resend it if necessary.
There may need to be installation of physical equipment; this may be in corporate data centres which will be undertaken by an in-house team, or there may need to be outside plant installed with associated civil engineering works, or this may be a customer-facing service that is required to install e.g., a modem in a customer location, or to provide setup and training services at a customer house.
Where outside plant such as street side cabinets or last mile connectivity is to be installed, this may require appropriate licences or permission from local authorities for digging up roads, by ensuring sufficient notices are issued, signs are erected and/or agreeing wayleaves with landowners. Scheduling and agreeing installation dates with customers can also be an extended process with many changes.
While not particularly complex, this process can contain many information exchanges and reschedules as availability or conditions change. Before the in-house or subcontracted field force installation activities can begin, there may need to be some validations or preparatory actions undertaken; additionally, actions, such as undertaking safety-related commissioning tests, may also be required as part of the installation activities.
After installation has been completed there may need to be some standard data and service configuration to be provisioned on the equipment. The relevant inventory systems will need to be updated to reflect the new availability and status of the equipment, and of any physical and logical sub-components of it.
There will be times when the CSP is unable to provide directly all aspects of a product on an order, for example when a third-party product is required following the Design and Assign activity (e.g., to provide last mile connectivity to a customer location).
In a similar scenario, where the CSP is reselling a partner’s product, an appropriate order must be submitted to the supplier, through a previously agreed channel (e.g., website, email, set-top-box experience etc). The progress of that order must be managed, and changes both ways appropriately communicated. It is probable that this type of component may take days if not weeks to complete – especially if civil excavation, construction, and installation to lay connections are required, for example.
During this time there may be multiple changes in the order status, and its forecast completion date, and there may be multiple updates to some of the technology configurations in response to this.
As these updates are received by the CSP, automatically or otherwise, the relevant inventory systems must be updated accordingly to accurately track the resource status. Upon completion of the order by the supplier, the CSP may undertake an acceptance process to confirm that it is working as expected.
Finally, for some types of supplier products there may be follow-on activities within the CSP to make correct use of the delivered functionality.
Changes to logical resources resulting from the Logical Design & Assign step and following on from any physical installation or supplier sub-component delivery must be applied to the relevant network elements.
Commands must be issued to the network elements in a format and with parameter values that reflect not only the customer-supplied data, but the specific vendor, model, and firmware versions of the network elements.
A single service order item is likely to result in a complex sequence of changes which must be applied to Network Configuration.
This often affects several different network elements, which must be orchestrated carefully to ensure not just that this service is correctly configured but also that other existing services are not unnecessarily or adversely affected by the new configuration.
Each service order item may result in configuration commands to add or create configurations in the network element, or to modify or delete them, which may seem initially counterintuitive when compared with the original customer request; for example, a request to delete a leg of a VPN may result in a new VRF being created.
Requests to cease service may initially result in a soft cease configuration (where network configuration is maintained but in a disabled state) being deployed, followed at some later date by a hard cease configuration (where network configuration is removed). This can be used to support a variety of scenarios, including:
- On customer request, for example when they are unable or unwilling to use the service for a period – a soft cease will be used to
suspend the service; after the agreed period, the network configuration is re-enabled. - Non-payment by a customer; once an agreement has been reached on the outstanding bill, the service can be re-enabled.
Porting of service numbers (such as MSISDNs and PSTN numbers) will vary according to the regulatory requirements imposed upon the CSP. Number porting may be donor-led (where the customer must notify their current service provider that they want to move to another service provider) or recipient-led (where the customer must notify their new service provider).
In either case, there will be a regulator-defined process to ensure that both providers agree a specific date and time on which the number will be migrated, to reduce as much as possible any loss of inbound service to the ported number. Often, as well as interfacing with the other CSP, this phase will include integrations with a regulator-appointed number management provider.
Upon completion of the logical, physical, and third-party component changes for a product, and depending upon the service complexity, a series of tests may be performed prior to handover to the customer to ensure that the service is working as intended and are Ready for Service.
These tests may form the basis of future tests (see Diagnostics-as-a-service in Customer Experience, and see Ready for Service in Life Cycle Management).
These tests can be executed when a customer reports a problem, as a customer self-service mechanism accessible via a web site or mobile app, or as part of a routine service quality assessment by the CSP.
It may be part of a self-healing network solution or alerting the NOC to failures in configuration. Anyerrors or quality issues identified during any part of Ready for Service and parallel automation can initiate trouble tickets trigger manual diagnostics or ultimately result in fully automated resolution activities.
Once service tests have been satisfactorily completed, the service is ready to be handed over to the customer (in the case of new service provision) or is confirmed ceased (in the case of service cessation).
To integrate the service into the financial framework, it is imperative to include it in the routine billing operations stack (Billing Initiation). This integration is crucial for accurately capturing both recurring charges and usage-based fees, ensuring they are consistently and correctly accrued to the customer’s account. The system guarantees that all charges associated with the service are meticulously reflected in all subsequent customer billing statements and invoices. This process not only upholds billing accuracy but also enhances transparency in the customer’s financial obligations related to the service. Incorporation into the billing operations is essential for maintaining a clear and consistent financial relationship with the customer, thereby fostering trust and satisfaction in the services provided.
Finally, Service Monitoring for the service must be appropriately configured (Initiate Service Assurance) – the service must be added to or removed from the CSP’s service assurance activities. This is essential for ensuring comprehensive monitoring and management of physical and logical service components and any third-party products involved in service delivery.
By doing so, the CSP can maintain a vigilant oversight over the service infrastructure, enabling prompt detection and response to any faults, alarms, issues, or events reported by network equipment.
Read more about Service Assurance.
Proactive monitoring is pivotal in maintaining service quality and reliability. It ensures appropriate and timely actions are taken to address potential disruptions, enhancing customer service experience. This approach not only safeguards the integrity of the service but also reinforces customer trust in the CSP’s commitment to delivering consistent, high-quality service.