An ever-present fact in our business is that an MSO must continue to grow its
subscriber base. However, to insure profitability, we must begin to streamline customer
activation and its technical support obligations by augmenting personnel with technology
wherever possible. Figure 1.0 represents a complex sequence of events that each potential
customer must experience. Today, the MSO must rely on its internal employees to process
each phase of the customer care process. If unaltered, this single fact will continue to
limit our ability to scale the business.
The purpose of this document is to draft the requirements and vision for this interface
that will be referred herein as the Customer Interface (CI) to evolve. The CI must provide
a modular environment that has built-in capability to authenticate and transact with an
Express customer and all aspects of their Express Internet account (See Figure 2.0) and
customer premise equipment (CPE). Note that enabling customers to interact with various
aspects of their video and telephony services account through the CI should be considered
as "future" capability.
Figure 2.0 CI from customer’s view point.
The ultimate goal of the CI is to automate the initial installation and further
processing of customer’s needs bypassing the need for the MSO personnel interaction.
The CI provides a web-based customer interface for "existing" MSO customers as
well as all "qualified prospective" customers. An "existing" MSO
customer being one that subscribes to Express Internet service (again note the desired
capability for customers who also subscribe to video and telephony services). A
"qualified prospective" customer is one that has obtained a copy of the personal
computer qualifier program, qualified their personal computer, and signed-up for service
(i.e. using the advanced leads tracking system to set up their account). This process is
known as self activation and utilizes consumer available technologies like set-top boxes
and DOCSIS (formally MCNS) modems when they become available in the near future.
This interface must be flexible and "easily-expandable" so that any
additional functionality that the MSO wants to push down to the customers can be quickly
developed and deployed using rapid application development (RAD) techniques where
possible. The key to the CI is its handshaking with critical provisioning components.
Figure 2.1 shows the major components that interact with the CI.
Figure 2.1 Major components of the CI.
The basic idea behind the CI is that once properly authenticated, a customer should be
"trusted" and empowered to change various aspects of their account, sub
accounts, and CPE. The CI is therefore a self-service environment or foundation on which
customer modifiable widgets reside. The CI represents both the graphic user interface
(GUI) as well as the underlying methods and procedures (workflow) surrounding its use.
The CI environment is one of complex multi-level security, connectivity, and
distributed access. Figure 2.2 drills down one level from Figure 2.1 and begins to
identify some of the hierarchy of the CI.
The CI environment communicates with the user through a secure sockets layer http
server (https). This ensures that information passing between the trusted user and the CI
is not visible to others residing on the customer’s shared network portion. It also
ensures that the IP address of the user is unaffected by the user going through a proxy
since proxies (knowing the IP address of the user enables a look up of their ethernet
address on the provisioning server – this can also be used as a means of alternate
authentication). Atop the CI is the function slices that enable the CI to manage various
account properties. These functional slices adopt the user interface properties inherent
to the CI such as look and feel, access to external resources, security, and logging.
Each of these phases seeks to provide some additional benefit to customers and off load
some portion of overall support calls into the MSO to fulfill the function provided by the
maintenance tool.
| Self-Service Customer
Interface (CI) Requirements |
Priority |
Phase |
Assumptions |
| 1.0 |
Hardware/Software |
|
|
|
| |
Will support ServiceCo
System-Level Requirements related to Hardware/Software as described in a separate
document. |
|
2 |
|
| |
A custom DNS server must be
co-located with the web server to ease auto provisioning. |
|
1 |
|
| |
A datastore provides logging
of any changes to customer’s account. One central logging facility per region??? LDAP
store??? |
|
1 |
|
| |
Ensure that actual client IP
address pass-through any proxy and available for use in CI (default for https sites???). |
|
1 |
|
| 2.0 |
Operations: |
|
|
|
| |
Will support ServiceCo
System-Level Requirements related to operations as described in a separate document. |
|
2 |
|
| |
CI will be designed
initially for HSD account management but will have capability to mange other MSO accounts
(telephony, cable tv, etc). |
|
1 |
|
| |
Inquiries should be less
than updates. 10 seconds is cutoff – performance only applies to cable modem access
not those done outside of this space. |
|
1 |
|
| |
Should support "bulk
changes" by M1 operators for many subscribers |
|
2or3 |
|
| |
Configuration information
such as IP addresses, SNMP passwords, and regional configuration parameters must be stored
centrally and external to the CI. |
|
2or3 |
|
| |
Configuration parameters
must be accessible by administration |
|
1 |
|
| |
Provide means for the MSO to
force all customer’s to change their email password when using the customer
interface. |
|
2or3 |
|
| |
Accesses from IP addresses
outside the MSO’s network that force an account to be locked will be reported to
operations via email and/or open customer trouble ticket. |
1 |
1 |
|
| 3.0 |
Access: |
|
|
|
| |
Supports access through
general Internet access (e.g. dial-up), provisional cable data access (aka
self-provisioned), and phone access (e.g. today's CSR environment) |
|
1 |
|
| |
Access to CI by MSO
employees will leverage LDAP User and Group permissions. |
|
2 |
|
| |
Access control is primarily
by username and password "unless" customer is coming from a MSO address. |
|
3 |
|
| |
Password forget function
– provides the customer with the ability to have his/her email password sent to them
by entering in their UID. |
|
1 |
|
| |
Supports the use of a CD for
subscriber selection and qualification -- screens out nonqualified customers and
simplifies web forms |
|
3 |
|
| |
Need strong protection from
name duplication |
|
1 |
|
| |
Provide the ability to
determine whether the desired UID is taken. |
|
1 |
|
| |
If desired UID is in use,
provide the ability to allow the user to try another one. |
|
1 |
|
| |
Transparent access by
individuals and groups; one would use a user-id for initial login, then select from zero
or more group accounts for "enhanced access"; this hides enhanced access from
casual users and hackers |
|
3 |
|
| |
A hyperlink into a
customer’s CI account must be supported – but only after proper logon has taken
place. |
|
3 |
|
| |
Repeated hyperlinks into the
CI after properly logging in will not require additional username/password entry. |
|
3 |
|
| |
Private data will only be
accessible by authorized MSO people (perhaps only by Accounting). |
|
3 |
|
| |
A button is added to the
customized browser to allow customers to access the customer interface. Button or
hyperlink may reside on home page instead of browser. |
|
1 |
|
| 4.0 |
Logging: |
|
|
|
| |
Will support ServiceCo
System-Level Requirements related to logging as described in a separate document. |
|
2 |
|
| |
Log entries include
information time/date, who logged in (including administrator/TSS/Accounting/or Customer),
from what IP address and what was added/removed or changed. |
|
1 |
|
| |
A customer can look up the
last 20 transactions on their account which is administratively configurable. |
|
2 |
|
| |
Unsuccessful logins will be
recorded/tracked on a datastore and available for customer/TSS/administrator review. |
|
3 |
|
| |
Logins entries in the
datastore will include date/time, and IP address of client. |
|
1 |
|
| 5.0 |
Locking: |
|
|
|
| |
Repeated, unsuccessful
logins to the CI that exceed a administratively set (not hard coded) limit will force that
particular CI user account into a locked state. Email and other uses of the users username
and password will be unaffected. |
|
1 |
|
| |
CI accounts that have been
locked will have the ability to unlock the account via this Interface. |
|
1or2 |
|
| |
To unlock a CI account the
email sent to the customer will explain the procedure for accessing a locked account
(copying and pasting username and "special" password strings in the email that
matches that stored in the locked account). |
|
1or2 |
|
| |
Special password strings
will consist of the encrypted password actually stored in the LDAP entry. This is just a
suggested process. |
|
1 |
|
| |
Entering the username and
the correct encrypted password will unlock an account. |
|
1 |
|
| |
Customers who experience
locked accounts will be forced to change their password (enter the change password tool).
Prevent the previous password from being seen or activated on that account. |
|
1 |
|
| 6.0 |
Notification: |
|
|
|
| |
Customers will have the
ability to control (turn on/off) whether they are notified of changes to their account via
email. This field is stored either in LDAP (preferred) or in a dB accessible by the CI. |
|
2 |
|
| |
Modification of the notify
field is via a specific account management tool that maintains CI environment properties. |
|
2 |
|
| |
Before a customer enters a
modification screen, they will be informed of the impact of such a change as well as any
additional action as needed (i.e. power cycle modem). |
|
1 |
|
| |
Notification email will be
sent to the username who’s CI account was improperly accessed. |
|
3 |
|
| 7.0 |
Security: |
|
|
|
| |
Administrative access
(TSS/Operations/Accounting) will be able to see similar information as the customer with
the exception of confidential data. |
|
3 |
|
| |
Confidential data will be
designated as anything that is not public knowledge (SSN, credit card number info, DOB,
passwords, mother’s maiden name, etc.) |
|
3 |
|
| |
Confidential data will be
encrypted by a private key. |
|
3 |
|
| |
Individual access to private
data will be tightly controlled and managed. |
|
3 |
|
| 8.0 |
Escalation: |
|
|
|
| |
Any failure in communicating
with authoritative sources will be recorded and escalated. |
|
? later |
|
| |
If authoritative source is
down, the CI will report an out-of-service error along with a link to an MSO status page
for up to date information on outages. ETE reporting outages to status page may be a later
phase. |
|
1 |
|
| |
Customer Interface will
tightly integrate with Customer Care’s e-desk system (Web Center). |
|
2 |
|
| |
The CI will generate the
appropriate "data wake" to transfer a customer with an error condition over to
Customer Care e-desk system for problem resolution/escalation. |
|
2 |
|
| 9.0 |
Data Model: |
|
|
|
| |
Data model is: owner ->
primary account -> subaccounts, where each arrow is a one-to-many relationship. |
|
3 |
|
| |
Both owner and primary
account(s) ‘should’ have billing accounts associated with them. |
|
3 |
|
| |
Application #1 (family):
primary account exercises "parental control" over subaccounts |
|
1(?) |
|
| |
Application #2
(telecommuting): corporation has owner account, and creates primary accounts for
telecommuters with "basic" privileges; telecommuter primary account may have
extended privileges and subaccounts based on additional revenue from employee |
|
2or3 |
|
| |
Each account has billing
opportunities. For example a company pays for several employee’s basic account and
the employee’s want better service – the employees pay the difference. |
|
2 |
|
| 10.0 |
Password Management: |
|
|
|
| |
A date/time parameter must
be associated with the password to keep track of aging. |
|
2 |
|
| |
Give customers that option
to enforce regular changing of email passwords with a selective interval. |
|
2or3 |
|
| |
Login procedure will provide
alternate ways for customers to obtain a forgotten email password. |
|
1 |
|
| |
Email their password. For
customers who have set up their browser to remember their password but have now forgot it
yet still receive email. |
|
1 |
|
| |
Incorrect passwords will
authenticate by IP address of the client and backup password (i.e. mother’s maiden
name or alternate password) or provide a hint to the customer’s email password. |
|
2or3 |
|
| |
IP address authentication
matches an ethernet address obtained from the DHCP server and a customers LDAP record.
Note exception when using remote access. |
|
2or3 |
|
| 11.0 |
CI Engine |
|
|
|
| |
Finite state machine is
utilized for all account management tools. |
|
1 |
|
| |
Initial states supported:
Login, Authorization, Selection, Display, View Only, Modification, Validation of data |
|
1 |
|
| |
Individual maintenance tools
descriptions, display, and processing instructions will not be part of CI code but rather
stored as a single record in an external database. |
|
1 |
|
| |
All maintenance tools are
created for general purpose rather than specific use. |
|
1 |
|
| |
CI will manage only those
services displayed in the menu (as dictated by subscriber’s profile). |
|
1 |
|
| |
More detail to
follow… |
|
|
|
| 12.0 |
Convergent Services
Support |
|
|
|
| |
Each subscriber will be
identified by some user id (UID) and a profile. |
|
1 |
|
| |
The subscriber profile will
represent active services associated with an individual. |
|
1 |
|
| |
Services offered (available)
will be determined by the Central Configuration Database (CCD). |
|
1 |
|
| |
Each tool record will be
described in such a way as to allow the CI to display or not display this functionality
based on the subscriber profile. |
|
1 |
|
| |
Any changes in service will
be able to pull existing settings and configurations to new service selection. |
|
1 |
|
| |
More details to
follow… |
|
|
|
| 13.0 |
Administrative Interface |
|
|
|
| |
Additional maintenance tools
that do not require access to an additional resource can be added to CI without re-coding. |
|
1 |
|
| |
Administrative interface
will be able to act as a type of build tool for adding maintenance tools to CI. |
|
3 |
|
| |
Each tool that is created
may be placed into one of three categories: services, features, options. |
|
1 |
|
| |
More details to
follow… |
|
|
|
A problem that would need to be solved is how customers (who are initially configured
with a net10 address) can get to a net24 (routable IP address) self service web server.
Regionally, this presents an access problem as somehow customers with a net10 must be able
to connect with the server to sign-up and perform account maintenance. To maintain the
idea of a single web site for self service maintenance (desired model), the MSO will need
some kind of special routing to forward regional requests for certain IP addresses to a
central web site of machine.
Self service maintenance first release must include provisioning facilities that would
enable one-way regions to easily upgrade to two way. This functionality would not
represent much effort and would enable regions who are currently converting one-way
customers (those already setup with an UID) to access this interface and add the
information that would enable them to upgrade to two-way service without the MSO having to
roll a truck.
A road block for the expansion of this system will be interfacing with a changing SMS.
Hsd and IT will need to work together to build the necessary APIs that would support
continued expansion of the self service maintenance tool set. Key functionality should be
initial account activation (priority 1), account change (priority 2), and account close
(priority 3). With both IT and hsd working together this issue may provide the necessary
functionality to vastly expand the number of self service tools available.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.