Purchase Order Number Skimmer - PONSkimmer
In February of 2000, the
FCC permitted the Regional Bell Operating Companies (RBOC) to offer
Digital Subscriber Line (DSL) services for general sale to the public,
with the restriction that the RBOCs had to provide parity for competitive
carriers. One major telecommunications provider took the approach of
spinning DSL sales and operations into a separate entity and affording
it the status of a competitive local exchange carrier (CLEC). This new
entity would have to deal with the incumbent local exchange carrier
(ILEC) on the same basis as other competitors, even though the RBOC
itself was the ILEC.
The company created a parallel
information system for the new unit, copied from the existing system
at the ILEC operation. An EDI-type interface was implemented to feed
orders out of the CLEC in the external order specification used by other
CLECs. Although this seemed to be a straightforward strategy, several
factors complicated real-world performance. The original ILEC software
was fully integrated. Orders were designed to flow in an uninterrupted
process from order taking to order fulfillment and billing. Since orders
were now interrupted between the CLEC unit and the ILEC unit responsible
for provisioning the circuit, orders would experience difficulties at
the hand- off between systems. Timing issues surfaced as orders and
changes to orders flew between the organizations. In pilot studies,
orders were lost or delayed significantly, and single orders were often
duplicated multiple times as customer service representatives tried
to expedite customer orders. Work-around procedures were identified
and implemented. Although the system covered the bases in theory, the
small pilot used to design the process would prove to be inadequate
for the system under full operational demand.
In the fall of 2000, the
company began aggressively marketing DSL into its service areas. Almost
immediately, the inadequacies of the software solution surfaced. Orders
were delayed for weeks. Some were lost completely. IT responded as quickly
as possible, but the complexity of the environment exacerbated their
efforts. Old legacy systems and new web-enabled interfaces were hard
to mesh. New problems arose as soon as old ones were retired. Ultimately,
resolving these problems would take several months.
In the meantime, the company
needed to provide for the huge demand for DSL service. Within a few
weeks, customer service representatives were entering thousands of orders.
Hundreds of customer support representatives were needed to marshal
the orders through the system. Their work week averaged over 60 hours
for months and turnover took a heavy toll on managers and customer support
representatives. Order fallout was very high, and resolution relied
on the skills of customer service representatives in various regional
call centers. Lacking the experience and the tools to quickly resolve
errors, some orders were not fulfilled for weeks, and some were never
fulfilled. Cancellations were common and customer frustration was very
high. New product promotions threatened to drown the customer support
As the first line of response,
call center personnel had a problem that was not easily resolved. Because
of system architecture, customer support representatives had to correlate
information from at least three different computer systems in order
to resolve even simple problems. Incredibly, there was no common order-based
key linking all systems. Additionally, each system had a unique interface,
complicating training strategies. Two systems ran on mainframes and
required knowledge of proprietary interfaces and special search methods.
The information needed to track orders passed to and from the ILEC consisted
of a variety of text reports posted to websites. The order interchange
software used a Java-based GUI to a client-server system, completely
unlike the 3270-style mainframe programs. Because of explosive growth
in new offerings, customer service representatives were added quickly,
with no experience using the old, legacy mainframe applications. Even
experienced mainframe users were spending an inordinate amount of time
searching all the scattered sources for information. Fallout rates and
backlogs were enormous and growing. On top of it all, computer staff
from IT were swamped rolling out fixes to the new systems and adapting
to the changing environment.
for data operations support and customer satisfaction wanted a way to
have all the information the customer service representatives would
need to resolve their problems gathered automatically and presented
in a single, unified format. They wanted a system that could run with
minimal support from center staff or from IT. They wanted the ability
to home in on specific categories of problems. Finally, they wanted
a way to help managers assign and follow up on customer representative
Using these needs
as the basis for a solution, a prototype system using Skimmer Technology
was developed in approximately four weeks. Within eight weeks,
the initial production system was running delivering a dozen customer
reports to service representatives and their managers by 9 a.m. across
four time zones. A Skimmer Technology solution extracted information from
all sources, correlated orders in all systems, validated the data for
completeness, and presented it in a series of optimized spreadsheets.
Since spreadsheets were standard on every desktop and used widely, training
needed for the new tool was very minimal. Even newly-hired representatives
had sufficient spreadsheet training to immediately use the information.
Filtering and sorting tools allowed representatives and their managers
to isolate information based on any column in the report. Managers could
also see which people were assigned to each troubled order, allowing
them to monitor progress and balance work loads.
Within weeks, backlogs
were eliminated, customer frustration reduced, and workloads normalized.
Processes were streamlined and efficiencies increased. Within two months,
overtime demands were reduced significantly and personnel turnover dropped.
Thousands of hours (and millions of dollars) of overtime were eliminated.
By using a business information
integration approach, an enormously expensive problem was solved in
a very short time for a fraction of the cost of software enhancements
to the underlying IT systems. This approach has worked time and again
at this same customer site, enabling them to address their own bottlenecks
and problems using office automation-based tools.