One-Click Phone Service

2000, BroadRiver Communications

Creating a phone number for a customer.

Problem

At a young telephone company, provide salespeople with the ability to create a customer's account, assign the customer a phone number, and activate the customer's phone service with a single mouse click.

Solution

Build a prototype of such a system.

An environment called Clarify had previously been selected for use as BroadRiver's customer-relationship-management (CRM) tool. For this project, I had to do the following:

• Using Clarify, build screens which provided the aforementioned features: create a customer, assign the customer a phone number, and activate the phone service for that phone number.

• Integrate Clarify with the telephone switch (IPCell) and a corporate software-integration tool (Vitria). Other developers made the system work from the IPCell and Vitria sides.

It took us a month. It worked. We ran the prototype in our lab, with Clarify visible on one machine and a telephone next to it on the desk. To start, we tested the phone: it had no dial tone. Then we created a customer:

...selected a phone line for that customer:

...and clicked the Save button.

We waited for a few seconds. On another machine, a status monitor showed the progress of the inter-application communication between Clarify and the telephone switch. In the Clarify window, the customer's "status" field showed:

After about 10 seconds, the other machine was finished, and the Status field said:

When we picked up the phone, there was a dial tone, and we could make phone calls.

HCI Notes

Streamlining: In the original version of Clarify, doing the above process would have required 10 separate steps, each of which was fairly complicated. For example, one of the steps, shown here, involved assigning a telephone number for the customer; in Clarify, this equated to "selecting and modifying an item from the system's inventory."

Step 8 of the original 10-step process (at 50% reduction): configuring a phone number from Clarify's inventory.

I extracted from those 10 screens the pieces we needed to see for this prototype: customer's name, phone number, and calling features. I then created two windows which allowed us to do everything the original 10 screens did, as far as our needs were concerned.

Automation: All 10 steps still needed to be accomplished, but the sales rep didn't need to use them during this prototype. So I performed the other 10 screens' work behind the scenes.

In addition, we wanted the sales reps—and, hence, the customer—to have an updated status report in real time. A significant part of the systems-integration effort for this project involved ferrying the status information from the telephone switch back to Clarify. Clarify did not support inbound inter-process communication, so we faked it; the telephone switch left me "messages" in the Clarify database.

UI Design: The screens you see here follow Clarify's UI standards, which I learned by mimicking other Clarify windows: the placement of the buttons, the relationships of the labels and the text fields, and so on. I chose to keep the Clarify look and feel, instead of adopting a Microsoft Windows-standard look and feel, because the end users—our salespeople—were immersed in the Clarify environment. Changing to the Windows standard would have actually made these two screens look and feel anomalous with the rest of the Clarify system.

Environment

My employer, BroadRiver Communications, was a telephone company. Like most phone companies, we owned a great deal of expensive, complicated hardware and software. Yet we wanted to provide top-notch customer service, which meant that internal operations had to be as streamlined as we could make them. Toward that end, we built a system that would allow our salespeople and customer-support representatives to activate, monitor, and modify a customer's phone service quickly and easily. Companywide, this was known as the Operations Support System (OSS); it involved about 12 on-site computers (or computer clusters) and several off-site systems—a billing system, the Clarify server, the telephone switches, and many more.

I was hired as "the UI guy." My job, in general, involved:

• Learning Clarify's programming language and development environment.
• Building customer-service tools with Clarify.
• Integrating those tools with the rest of the OSS.
• Mentoring other developers.

Clarify is, itself, a complex environment; it contains many modules, with overlapping functions, which use a centralized database. The environment ships with customized tools for modifying the user interface and the database schema; attempting to do so without using those tools will corrupt the system, quickly and irrecoverably (I tried it). The environment also has its own programming language. Part of my job was to master that environment, build BroadRiver's CRM system with it, roll it out, maintain it, and mentor other developers as they joined the project.