Legacy Evolution

1
Local Service Ordering and Provisioning Fallout
Reduction February 22, 2006
2
Fallout What is it?

• If an LSR contains any type of error, it will
  typically be rejected by the receiving LEC and
  will have to be resent or supplemented
  (modified), depending upon the type of error(s)
• Fallout consists of the LSR transactions that
  must be recycled one or more times due to errors
• Can be expressed as a percentage of new LSR
  transactions or percentage of total LSR
  transactions (including supplements)
• Can range as high as 100 of new transactions
• Drain on efficiency
• Inserts delay into service provisioning interval
• Unhappy customers
• Delayed revenue

3
Todays objectives

• Share information regarding the causes of fallout
  and what service providers can do to minimize it
• Review the types and frequency of errors that
  cause orders to be rejected
• Examine the underlying causes of errors and what
  service providers can do to reduce them

4
Who is NeuStar?

• Telephone number administration and pooling for
  19 countries in North America
• Maintain the authoritative database of telephone
  numbering resources
• Manage the administration of the allocation of
  pooled blocks of unassigned telephone numbers
  through our clearinghouse, including the
  reallocation of pooled blocks of telephone
  numbers to the consolidated network of
  consolidating carriers following a merger or
  other business combination.
• Wireline and wireless number portability
• Manage the master, authoritative directory that
  allows end-users to change their telephone
  carrier without changing their telephone numbers.
  
• Continuously managed the Number Portability
  Administration Center (NPAC) since 1996
• Order management services
• Centralized clearinghouse services permit
  communications service providers (CSPs) to
  exchange essential operating data
• Processed 3M LSR transactions in 2005

5
LSR Fallout Analysis - Summary
of Total Fallout by Error Category
Other
Info Found on Pre-Order
Invalid Dates
Pending/ Duplicate Order
11
5
7
40
8
8
Supplement Issue
21
Invalid Trading Partner Info
Provisioning Error
6
Information Found on Preorder (40)

• Errors relating to
• The entire account e.g.
• Address
• Telephone numbers
• Circuits
• Features on the account

• Error types
• End user name does not match profile (Customer
  Service Record)
• Invalid Address
• TN not Found
• Invalid Activity (ACT) Code
• Line share errors

7
End User Name Does Not Match Profile

• Root cause
• Provisioner uses account name given by end user

• Countermeasures
• Pull a Customer Service Record (CSR) via an LSR
  Preorder to verify the correct name and
  formatting.
• Cutting-and-pasting the name from the CSR
  directly into the order helps eliminate
  formatting errors.
• Some LSR applications enable the importing of the
  account name directly from the CSR response to
  the Preorder into the LSR Order.

8
Invalid Address

• Root cause
• Provisioner uses address given by end user
• Typically, end users will give their mailing
  addresses, which will not always match the
  service addresses that the LEC uses.

• Countermeasures
• For all orders except new install activity, pull
  a Customer Service Record (CSR) via a Preorder,
  cut-and-paste directly, or import into the LSR
  order.
• For new install orders, process an Address
  Validation Preorder, cut-and-paste directly, or
  import the address into the LSR order from the
  Address Validation Exact Match response to the
  Preorder.

9
TN Not Found

• Root cause
• Frequently the end user is unsure of what the LEC
  uses as the Billing Telephone Number (BTN),
  especially if it is a larger account or more than
  one account exists at one location.
• Provisioner pulled a CSR by the Working Telephone
  Number (WTN) only. For some LECs, when the CSR is
  requested by WTN, they will not return all TNs
  associated with that account.

• Countermeasures
• Pull a Customer Service Record (CSR).
• If no CSR available Most likely the account is
  with another reseller and not the LEC.
• If CSR returned, verify that the TN is on the
  CSR. The TN could be under a different BTN.

10
Invalid Activity (ACT) Code

• Root cause
• Provisioner provided incorrect information such
  as the wrong activity code on the order.
• Example The provisioner has placed a full
  disconnect order with only one line on the LSR
  order, but the account actually has 3 lines on
  it. In this instance, the provisioner should
  have submitted a change order (partial
  disconnect).
• Example The opposite scenario the provisioner
  places a change order (partial disconnect), and
  the line on the order is the only line on the
  account so the provisioner should have submitted
  a full disconnect order.

• Countermeasures
• Pulling a CSR allows the provisioner to verify
  the lines on the account and create the correct
  order activity.

11
Line Sharing Error

• Root cause
• Typically means that the wrong Type of Service
  (TOS), Network Channel (NC), and Network Channel
  Interface (NCI) codes were used when creating the
  LSR order

• Countermeasures
• Provisioners should have a cheat sheet for all
  TOS, NC, and NCI codes used by their companies by
  product. This should be broken down by LEC due to
  differences between them.
• Pull the CSR and review. Line-sharing will be
  listed on the CSR if it is part of the account.
  Identifying it will assist the provisioner in
  selecting the correct TOS, NC, and NCI codes for
  the LSR order.

12
Provisioning Error (21)

• Errors relating to
• Missing service codes (e.g., USOCs)
• Invalid formatting of fields
• Specific field required for the order not filled
  in

• Error types
• CORRECT Exchange Company Circuit ID (ECCKT) IS
  REQUIRED FOR Line Activity (LNA) and Line Number
  (LNUM)
• INCORRECT DATA IN THE FEATURE FIELD
• (Type of Service) TOS AND LINE Universal Service
  Order Code (USOC) DO NOT MATCH

Typically these errors are reduced as
provisioners become more experienced and familiar
with the different business rules of each LEC
with which they interact.
13
CORRECT ECCKT IS REQUIRED FOR LNA LNUM

• Root cause
• The provisioner may have used the copy/paste to
  populate several service detail forms and then
  forgot to change the TN part of the ECCKT to
  match the TN on the service details form.
• The provisioner may have forgotten to fill in the
  ECCKT field, which is required by some LECs for
  specific Reqtyp and activities.

• Countermeasures
• Before clicking on the submit button, review each
  service detail and ensure the TN and the ECCKT
  match. Also ensure the LNUM field is incrementing
  on each service detail section
• Provisioning expertise Attend any available LEC
  provisioning training for each of the LECs to
  which your company sends LSRs.
• Use a system that provides a pre-validation tool
  to alert the provisioner when a field is required
  for the specific Reqtyp and activity

14
INCORRECT DATA IN THE FEATURE FIELD

• Root cause
• Provisioner either forgot to fill in the FEATURE
  data or formatted it incorrectly. Also possible
  that not all service codes required for the
  specific feature were included.
• Example Call Forward Busy, requires the call
  forwarding number in the FEATURE field. Each LEC
  has specific formatting required for that
  information.
• Example AYK (anonymous call rejection), which
  is prohibited with AYW (anonymous call rejection
  with caller id)

• Countermeasures
• Provisioning expertise The more a provisioner
  submits orders and works fallout, the more
  familiar specific LEC codes will become.
• Each of the ILEC websites provides USOC guides
  that include not only the service codes but also
  the formatting for FIDs.
• Use of a cheat sheet for the most commonly used
  service codes and the formatting of the FIDs will
  assist the provisioner in submitting clean LSR
  orders.
• Use a system that has templating functionality so
  provisioners can create a template with set
  service codes (features) their company uses along
  with the formatting for the FIDs.

15
TOS AND LINE USOC DO NOT MATCH

• Root cause
• Specific LECs require not only the Type of
  Service (TOS) field but either a Line Type of
  Service (LTOS) or a FEATURE (e.g. USOC) code to
  identify the type of service.
• The provisioner has used the incorrect codes by
  either not matching it to the existing service on
  the CSR or by not matching the TOS code to the
  LTOS/USOC code.

• Countermeasures
• Pull a CSR to identify the correct type of
  service e.g., Centrex, business, residential,
  multi-line, PBX
• Provisioner should have a cheat sheet of all the
  TOS codes for each of the types of service their
  company sells, broken down by LEC since each LEC
  uses their own TOS codes.
• Included on this cheat sheet should be the LTOS
  or USOC codes required by the LECs.

16
Invalid Trading Partner Information (8)

• Root cause
• Errors relating to trading partner IDs e.g
• Invalid Company Code (CC)
• Invalid Customer Carrier Name Abbreviation (CCNA)

• Countermeasures
• Use cheat sheets
• Use a system that has templating functionality so
  provisioners can create templates with
  pre-populated trading partner information
  encompassing both their company and for each LEC
  to which their company sends LSRs

17
Supplement Issues (8)

• Root cause
• Errors caused by incorrect submittal of
  Supplements or incorrect information on a
  Supplement
• Errors include
• No original order found
• Previous version being worked
• Activity cannot be changed on a supplement

• Countermeasures
• Provisioning expertise
• Know the LEC business rules governing the
  conditions under which a supplement can or cannot
  be issued
• Use a system which
• Controls the version number
• Will not permit the wrong action to be taken
  regarding a supplement
• E.g. supplement vs resubmit
• Not change activity
• Not supplement after completion

18
Pending / Duplicate Order (7)

• Root cause
• Errors regarding duplicate orders
• Primary error is duplicate Purchase Order Number
  (PON)
• Typically caused by
• Same order submitted more than once
• Re-use of the same order ID (PON) for different
  orders within a prohibited period (usually 2
  years)

• Countermeasures
• Good order ID tracking system
• Use a system that prevents duplicate PONs by one
  or more of
• Performing duplicate PON validation checking
• Auto-generating unique PONs for each new order

19
Invalid Dates (5)

• Root cause
• Errors associated with invalid due dates e.g.
• Insufficient interval
• Expedite field required
• Due date is a holiday

• Countermeasures
• Provisioning expertise knowledge of the LECs
  standard intervals and rules regarding the
  scheduling of due dates
• Use of a system that includes business rule
  validation encompassing the validation of due
  dates and related fields

20
Summary 3 Key Countermeasures to Minimize
Fallout

• Pull Preorders to get accurate data on existing
  customers with the LEC
• There is no substitute for knowledge on the part
  of staff creating LSRs
• Invest in training
• Create cheat sheets
• The more sophisticated the application being used
  to create LSRs, the lower the chance of fallout
• Pre-validation of data
• Templates
• Data links between Preorders and Orders