Business Mentor
In System Design, Treat Exceptions Like Exceptions

After our weekly status meeting, Diane rushed up to me with a look of distress.

In hushed tones she said, "Niel, we forgot about split payments."

I was confused. "Split payments? What are those?"

She explained. When a customer places an order through our call center, we allow him to make his purchase with multiple credit cards. For example, he might pay for a $50 order with $30 on a Visa card and $20 on a MasterCard.

"Why do we do that?" I asked.

"To provide customer service," she said. "Until now, I forgot to include it in our requirements for the new system."

Diane was my sales order processing lead on a project to replace our 25-year-old legacy system with a new enterprise resource planning (ERP) system. We had used the purpose-based alignment model to identify three of our company's "differentiating" activities, one of which is excellent customer service. [For more on the model, see "The Route to IT Heaven: 'Differentiating Projects,'" September 2005 issue.] We also identified the activities -- known as "parity" processes -- that aren't differentiating but that help the company stay competitive. We had taken a vanilla approach to the configuration of these system processes.

Preventing Exceptions From Creating New Rules

If one of the ways we differentiate ourselves is through excellent customer service and since supporting split payments provides customer service, I wondered whether we should spend resources to customize the new system to support split payments? Diane and I had a good enough relationship to have this conversation.

"Diane, do we advertise that we can handle split payments?"

"No."

"If split payments truly provide excellent customer service, we should promote the fact that we can handle them."

"We offer them only as a customer convenience."

"That makes sense. If offering split payments is a differentiating activity, they would help us acquire new customers. So how often does a customer request split payments?"

"During peak season, we probably get these requests once or twice a day."

(Our peak season produces about 1,000 orders a day.)

"Diane, this is not a way of providing excellent customer service. This is a one-in-a-thousand exception, and we should treat exceptions as exceptions."

"What does that mean?" Diane asked.

"It means that we do not design the system to handle exceptions. If you agree that handling split payments is a nice-to-have but not a must-have feature, let's figure out how to support them without customizing the system."

She agreed, and we thought through a process that used the vanilla system design to support split payments.

Now, when a customer pays with multiple credit cards, a call center agent applies a partial payment with one card and then, in the order's notes section, enters the credit information for the other cards used to pay the balance. The agent then opens a line of credit in the amount of the remaining balance. The ERP system automatically routes the order to a credit manager to extend or deny credit. When the credit manager receives the order, he opens an account and then pays off the balance using the credit card information in the notes section.

This was not as elegant as a customized solution, but it did treat these exceptions like exceptions: tasks that should be handled as best as possible, but not treated as a standard, system-supported process.

In our desire to satisfy customers, how often do we design based on the exceptions? Does doing so generate measurable business value? In my experience, the answer is no.

Digg This!     StumbleUpon     Del.icio.us