Automated Service Provisioning

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.

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.

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:

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.