|
Self-Service Customer Interface
Building a generic, open, and extensible customer information
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: March 13, 1998
Note: For help designing/implementing your self-service customer interface or developing tools to help you improve or implement such a program contact Birds-Eye.Net.
Overview:
Empowering Broadband Service Provider (BSP) customers to
activate/modify Express service themselves (the beginnings of self-provisioning) will
require several back system components to fulfill a single customer installation/change
order. Among the most important of these components is the interface that customers will
use to gain access to their account. While work is proceeding to build widgets for
customers and TSS to use the concept of a central interface on which all these widgets
must ultimately reside remains largely undefined.
The purpose of this document is to begin drafting 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 1.0) and customer premise equipment (CPE). Note that enabling
customers to interact with various aspects of their video services account through the CI
should be considered as “future” capability.
Figure 1.0 CI from customer’s viewpoint.
The ultimate goal of the CI is to automate the initial installation
and further processing of customer’s needs bypassing the need for BSP personnel
interaction. The CI provides a web-based customer interface for “existing” BSP
customers as well as all “qualified prospective” customers. An
“existing” BSP customer being one that subscribes to Express Internet service
(again note the desired capability for customers who also subscribe to video 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-provisioning 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 BSP 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 1.1 shows the major components of the CI.
Figure 1.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.
CI Accounts:
The organization of accounts within the CI must support various
flavors of the BSP Express Internet product (i.e. residential, commercial, etc.) Figure
2.0 provides a high-level view of proposed account relationship.
Figure 2.0 Representation of CI accounts
This representation suggests three categories of user accounts
(Owner, Sub Account, and User Account) and their inter-relationships. The owner of the
account in all cases being the primary person/department responsible for the account
– or who gets the bill. This account should be fairly high-level and only contain
information about account specifics. Changes to sub-accounts should bubble-up to this
account so that at a quick glance one can obtain quick summary of how sub-accounts are
configured and any additional charges they incur.
The sub-account(s) should represent the primary user (residential) or
site administrator (commercial). This account should have a 1 to many (1 to 1+)
relationship with the Owner account to support various flavors of the BSP product (small
business, and telecommuter uses). Through the sub-account various add/remove/change (ARC)
functions/permissions are possible. For example this account would set up individual user
accounts such as email addresses for family members (residential) or site employees
(telecommuter or soho). Other examples might be to set bandwidth or number of supported
users for this site. A important component of the sub account is that it also have billing
field. The billing field is necessary because customers set up with basic corporate
accounts for telecommuting (for example) may also subscribe to services above and beyond
that of basic service. These extended services would represent additional revenue
opportunities for an MSO and thus should be associated with an account number that is
different than that of the owner account.
The user account identifies an individual user and is restricted to
only change user specific properties (NIC mac address, email password, hostname,
etc).
<Further details are needed
to define various account types!>
Requirements summary of user accounts section:
<Further details are needed
to define various accounts>
CI Environment:
The CI environment is one of complex multi-level security,
connectivity, and distributed access. Figure 3.0 drills down one level from Figure 1.1 and
begins to identify some of the hierarchy of the CI.
Figure 3.0 CI
Environment
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 is enables a look
up of their ethernet address on the provisioning server – this can also be used as a
means of alternate authentication).
Security:
Since the user that accesses the CI can reside on two types of
networks (private, public) the authentication should account for this. Customers coming
from the private network (for example10.x.x.x) fall into one of the following
categories.
·
“New” customer that has
never been provisioned
·
“Existing” customer
that replaced his/her ethernet interface on the computer
The customers accessing the CI from a public
network fall into one of the following categories:
·
“Existing” customer
attempting to log in and modify their account
·
“Non-BSP” customer
attempting to hack in to an existing account.
The distinction between which network a
particular customer is accessing the CI from will be the primary logic used to determine
whether a customer should be allowed an option to sign up for service (self-activation).
The various ways that simple email names and passwords can be hacked should force a
thorough study geared towards defining all known ways to break into a user’s account
and steal BSP Internet service *. How each of these ways are addressed must have a goal of
keeping the customer informed, providing a way for customers to undo any forbidding locks
without calling customer care or negatively impacting their service functionality.
Extensive logging of transactions may be necessary. Here are a few examples of possible
scenarios:
·
“New” customer attempts
to use buddies email name as a login and tries guessing their password. Email customer any
unsuccessful attempts to log into their account and encourage them to change their
password and potentially restrict the “New” customer’s access to the web
site after some threshold **. Actual restriction may be by “New” customer’s
IP address.
·
“Existing” customer
forgets their password and would like it reset. Offer a secondary way to authenticate (via
IP address and/or alternate password for example).
·
“Non-BSP” (not from 24
network) customer finds CI web site and successfully logs in. Limited functionality should
be available from off networks (can’t change password for example).
* Since self-provisioning can occur without BSP intervention
precautionary steps should be developed to protect against misuse. These measures need to
be in place prior to activating full self-capability.
** For security reasons, multiple failed logins should restrict a
particular ethernet interface from further access to the CI. This should also escalate
some type of notifier to customer care that this activity has taken place.
Graphical User Interface:
The graphics environment of the CI
must be extremely flexible and support configuration outside of reworking the code that
generates the dynamic content. The following points must be address to support the desired
functionality of the CI:
· Mapping of predefined style sheet content areas to dynamic
content generated by CI action
Style sheets or equivalent must utilize in such a way that dynamic
content can be mapped or associated with a particular area of a web page. These pages must
also support enterprise and regional content so company and regional marketing
opportunities (like cross selling) can be supported.
·
Interfaces (submit buttons, drop
downs, etc) need to be customizable via graphics library as opposed to hard coded.
Dynamic content should be customizable to enable regions or BSP to
standardize the look and feel for all customer interfaces (make them all the same). The CI
library must conform to that of other customer interfaces used by BSP.
· Concept of shared library of graphics
One of the requirements of the CI
is that it permit regions to customize the layout and graphics of the dynamic content. To
do this, all dynamic graphics content needs to be mapped to a set (library) of graphics.
Although the dynamic content should be able to be displayed without this library (using
internal default HTML colors, buttons, etc.) the library would allow regional or company
wide changes in the GUI to be handled quickly.
Components of CI:
Figure 4.0 Major components
of the Customer Interface
Staged Development/Deployment:
The CI will be deployed in three phases that are tightly coupled with
the phased releases of BSP’s self-service activation & maintenance modules. The
first phase described in Figure 5.0 represents functionality associated with the login
process.
Figure 5.0 Phase 1 release of CI
The login process (authentication) enables subscribers to enter the
CI maintenance area. The initial screen for this phase of the CI is the login screen.
Through the login screen subscribers can enter their current username and password or just
their username if they forgot their password. Since there are two maintenance functions
closely associated with authentication these tools are included in this login/maintenance
phase.
This phase is heavily dependent on the following to successfully
deploy:
·
Technology transfer of
provisioning various types of devices (PC, LANCity, GI, Motorola) currently handled by
STAGE is documented so that requirements can be developed for a standardized provisioning
API.
·
Provisioning API developed that
standardizes the action of de/provisioning “any” type of cable modem or customer
PC. This enables various systems (like STAGE and other provisioning interfaces) to
similarly activate these devices.
·
Move authoritative source of
provisioning data from Remedy to LDAP. Reconcile provisioning data stored in Remedy and
move it to the appropriate customer record in LDAP.
·
Develop “new” STAGE
functionality that dynamically places LDAP data into Remedy fields yet does not break
existing de/provision functionality. This approach is similar to what STAGE did for email
names and passwords (moving authoritative source from Remedy to LDAP but not breaking the
ability to de/provision email names through STAGE interface) *.
* Note that de/provisioning in LDAP will need to be coupled with
de/provisioning on the DHCP/BOOTP server. These two separate actions will eventually be
phased out when all that is required to de/provision a device is place it in LDAP. These
actions are best taken care of by including this second action with API described above.
This keeps infrastructure dependencies out of the hands of applications that interface
with the APIs. Once the infrastructure does not require this second provisioning action
(registering on the server), it can be removed without changes to any of the
applications.
Random Requirements: <need to find a category to place under>
1. This
interface must be accessible by any BSP client (platform independent).
2. Several
layers of security must be implemented to deny only those without a BSP account. Initial
authentication must be multi-faceted to allow for all instances (forgotten passwords,
etc.).
3. Must
to sustain large numbers (50,000+) of simultaneous users
4. Developed
with growth in mind. Additional functionality can easily be added with little change to
existing interface.
5. CI
environment provides built-in access to primary Express systems (Billing, LDAP,
Provisioning, etc)
6. Front
end graphics and surrounding links user configurable.
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.
|