Customer Self Service Requires Service

Ever since the first moth was removed from the Eniac computer, debugging computer applications has always been an interesting challenge full of anecdotes and folklore.

When I first started building Web applications in 1996-1997, I was quickly blind-sided and stunned by a fundamental issue. Web Applications can't be debugged!

In the classical model of debugging, breakpoints are set -- or extra print  statements are added. These are the tried and true methods behind debugging -- but they don't work for web applications, why not?

Web Applications are multi-user and real-time. Debugging is single-user and more like suspended animation -- i.e. the world stops when debugging begins.

The web originated as a means of quickly disseminating information. People (myself included) soon built dynamic applications to empower customers, employees and partners to accomplish 'Self-Service.' My early applications were simple HTML forms that accessed a complex back end, SAP R/3. I started with insufficient knowledge of the web, even less of an understanding of SAP and a market hungry for my solutions. Almost overnight, I had over 1 million users at 100+ SAP customer sites. My customers loved the fact that they could publish applications and deploy them with no perceived need for training -- because no software needed to be installed. All you need was a URL and a user-id. Ready-set-go.

In an early harbinger of the complexity to come with SOA (Service Oriented Architecture), RIA (Rich Internet Applications like Ajax and Flash/Flex), Mashups and more, I had little appreciation of the configuration options that could change the behavior of an SAP back end. Each customer configured their SAP system differently -- for instance some customers used a factory calendar instead of a normal calendar. My application, didn't allow for 'Monday' to not be 'Monday.'

My programmers had the typical reaction to customer problem reports. If you can't reproduce it, then it must not be a bug. Getting the bug to reproduce at SAP was even harder -- because our SAP system was configured differently than the customer's. Even when the customer would write copious notes about the sequence of actions which caused the problem -- the problem didn't always replicate. Why?

The back end processing of complex web based transactions can be an organic, living machine. The environment changes constantly. The contents of the database change, security models change, user permissions change, prices/contracts change, even with users shielded from one another with 'protected address spaces' -- the contention for resources such as database cause lock contentions and other failures. Since most web based applications are layers on top of the existing back-ends, the failure of a single component may not always be visible.

• So, if you can't reproduce the problem, is it still a problem?
• Since the underlying system is multi-user, how many others had the same problem?
• Out of this data analysis -- can I start the process to determine the root cause?

If you think that this is just an 'IT' problem, then you are in store for a rude awakening.

If the problems were performance and availability, then the existing application performance management tools would be aware of the issues and would start the process of 'self-healing.'

The majority of problems affecting self-service users are reported by the customer (i.e. the end-user). The definition of 'problem' is also customer specific and pretty broad. Customer’s could be complaining about things as obscure as database exception error messages, or be annoyed that they couldn't configure the router in red, or simply that they can’t log-in, or the site navigation doesn’t make sense.

Where is the SNMP trap for unhappy customer? How do you solicit this request, validate the information, quantify the problem and dispatch the appropriate resources? In parallel, how do you turn this process from reacting to the problem to being proactive? And how do you define 'unhappy' in a frictionless channel like the web.

Proactive measures include doing customer assisted 'order recovery', or getting early warnings if problems resurface.

I'm personally more likely to give feedback to a site -- if I think they can actually do something about it. Nothing upsets me more than getting a computer generated response that acknowledges my 'issue',  however they have no idea of my context -- nor a desire to solve my problem. With more and more services going to self-service -- how does the customer get to speak, and how will organizations listen?

I can only imagine the feeling that went through the Hurricane Katrina “experts” when they realized that 'It's only going to get worse.'

The web is coming to this crossroads. People now have the same expectation of self-service as they do for traditional channels. When was the last time that Safeway (the store) wasn't able to ring up your shopping basket (you know the thing with wheels)?

Web-based applications are growing in complexity by leaps and bounds. The browser is now orchestrating data and services across multiple channels. The logic for a web application - which used to solely reside on a server - now resides on multiple servers and on the client. The drive to create a more interactive user experience now utilizes client caching, document modification, asynchronous services and a ton of code running on the client.

In other words, the customer (aka client's) experience is no longer under the control of the enterprise(s) serving it up. If you want to protect your customers, your brand, your increasingly important online  revenue stream, then you have to know what's happening from the perspective of the only person that matters, your customer.

Once I understood this, I took action, I started Tealeaf to address this issue.

Footnote:

The traditional urban legend of web sites is that your customer is one click away from your competitor. While in some cases this may be true, I think that customer experience failures typically cost the company much more than a simple “lost” sale. If I fail online, I might contact the call center if I still want the product or service. But, all of a sudden, the cost of processing my “order” went from pennies on the dollar to tens of dollars. This is true even on 'non transactional sites.'

In my never ending quest to 'let the customer speak' -- I would like to create a 'Hall of Shame' for problematic web sites. Please send me screen shots or anecdotes. Each month, the winner gets a prize.

--Robert Wenig

Comments

[Joe Tooman]

I can completely relate to what you are saying. Ten years ago, supporting Web sites was black and white. Performance and availability were the key measures to evaluating the user experience. But back then, the Web was dominated with content-oriented Web sites. Much of what you needed to know could be determined by looking at Web server logs and traffic analyis reports. Things changed. Once transactional Web sites grew in number, black and white became shades of gray. It wasn’t enough that the Web site was up or that pages were responding quickly for your users.

As the Web changed, users became customers and page views became dollars. Customers that could be observed at a brick and mortar store became numbers on Web analytic reports as they shopped on the Web. The understanding of what customers were experiencing and how they interacted with the Web site became abstracted in many ways. With session replay, and the rich set of data associated with it, it is much easier to understand why customers are complaining about site issues or abandoning their shopping carts. Now, Web analytic packages can continue to tell you what is happening at a high level without straining themselves to help you understand why. For people like me who are relied on to provide an accurate analysis on the customer experience, I couldn’t imagine doing my job without the insight that TeaLeaf provides.

[jim slaymon]

As a mgr of our web site, I like most other webbies look at other sites differently than the regular customer. Recently, I found myself spending a lot of time (and money) on E-Bay. I ran into several problems under "My E-Bay" view. I contacted support, who of course sent me one of those wonderful "we care" auto replies. After several days, a response from a human came back, ensuring me that there was no problem and that it must be me doing something wrong. After several more exchanges, I finally sent them tons of documentation and screen shots to prove my point that there were several bugs in their system. They finally acknowledged these and sent them along to technical support. BTW....E-Bay thought of pretty much every detail and fucntion to put in their web app, but it is the most user unfriendly site I have ever encountered, especially their help section. It makes you feel like you need a PHD to navigate.