There are HTML standards, which the World Wide Web Consortium (W3C) defines. The problem is nobody bothers to adhere to them. If I create an HTML Web page using Notepad and publish it on the Internet, chances are everyone who has a Web browser will be able to view that document. However, hardly any of the players in the browser world interpret HTML in the same manner. They all have their own set of rules loosely based on W3C standards. Not only that, but none of the tools vendors provide us to create HTML play by the rules. Create the same page using Dreamweaver, then FrontPage, then Word, and take a look at the source. Scary. For some reason, everyone in the PC world seems to think it is good to operate outside of the box.

The Web applications my company delivers clearly state they will operate correctly using only Microsoft Internet Explorer versions 5.X-6.X–not because we love Microsoft or are convinced Microsoft distributes the best browser but because we know more than 90 percent of our customers use those browsers. Nevertheless we still get the technical support call from the guy with the browser he built using modified open-source code, which for some reason doesn't run our application properly. Furthermore, he has been a loyal customer for 32 years, and he is going to have my head if I don't do something about this. Sound ridiculous? Sure, but these situations really occur. I don't understand it. My bank tells me I need to use IE for online banking. Even though Firefox may be my browser of choice, I use IE for banking.

It's like someone building a radio that decoded only AM signals but operated in the FM frequency range–and then calling the radio station to complain that he can't "hear" the broadcast. Or how about taking a working FM radio while exploring some caves and then complaining the station was not working? Is that any different than a computer sitting behind a firewall with a crazy proxy server and port 80 locked down? Computer users are difficult to work with. I live 30 miles from a major metropolitan area. I don't get good television reception with the built-in antenna. I know I either need a rooftop antenna or must invest in cable or satellite service. I don't expect the television station to solve my problems. Yet a customer sitting on an AOL dial-up using a 486 system with Netscape 2.0 will call me and complain our Web site is too slow.

Problems

So, we have identified two major problems: lack of adherence to standards and the peculiarities of computer users. We can control a lot of this and thus control the level of technical support we need to provide. There are three classes of users we need to support:

o Internal customers–employees or consultants who are directly under our physical control.

o External "employee" customers–people, such as producers or agents, who are involved in selling our goods or services and must use our systems to enter orders and interact with the "home office."

o External end-user customers–those users who access various Web sites either to gain information or to purchase a policy or modify their information.

It's All About Control

The first class is the easiest to handle. You have complete control over employee-customers' hardware and their installed software. They all probably are using cloned boxes, are secured tightly behind firewalls, and have antivirus protection you have approved. If there are real technical issues with these folks, they are limited possibilities. Maybe your application is buggy. If so, then you are getting good information you can work with. Maybe there is a problem with the box–hardware failure or software corruption. That is easy enough to test and repair. The remaining possibility is user error, and that can be solved in a number of ways. Help-desk support for these customers is critical and often can be handled quickly and easily.

The second class–folks who are in the middle of the money chain–can provide more challenges for tech support, but these probably can be mitigated by good design. Remote agents or agencies may need to access your policy admin system to quote or write a policy. Hopefully, they will be using software supplied by you or your contracted third party to access your system. The tighter the control you can maintain over the user, the less likely you will be to experience failure. There is a greater front-end cost to equip agencies with software to communicate with your internal systems than to deploy a Web-based system, but the extra control is well worth the expense. Yes, in a perfect world, we should be able to use Web services via .NET or J2EE to deliver Web applications that can be accessed any time, anywhere, by anyone. But we don't live in a perfect world.

The insurance industry has the benefit of many good, strong standards that can be used for interapplication operability. But if we deploy those standards in a browser-based application, we still are at the mercy of the browser makers. Even if we insist on a particular browser with a particular service on a particular operating system, there are no guarantees your application will work.

If you couple that with the never-ending stream of security patches, you will face a technical support nightmare. You can use HTTP over TCP/IP as well as all available industry standards–but try using a piece of software you own to conduct business. If you own it, you control it.

You have a lot of control over the first two customer classes. Use that control to insist on certain standards so that you at least can minimize the amount of technical support needed to support them.

The Buck Starts Here

That brings us to the great unwashed masses. Those folks at the beginning of the money train. Your paycheck ultimately starts with individuals who purchase the insurance policies or financial services your firm offers. Lose that customer class and you have lost your business. Providing adequate, timely, and useful technical support to this group presents enormous challenges.

We all have taken that leap of faith that tells us to do business successfully in today's world, we must have Web sites. Those Web sites originally were intended to serve our customers by providing them with information about our products. Most firms also allow customers to purchase products, modify their personal information, and complete online transactions–which may range from purchasing an annuity to making a claim on an automobile policy, and everything in between.

Instant Gratification

The thing we need to understand about online customers is they are ready to do business now. That means when the log-on page keeps coming back around, your customer wants an immediate resolution. It doesn't make any difference if we are dealing with a user problem. The application needs a session cookie to identify the customer, but he doesn't care. He just wants to sell 300 shares of Krispy Kreme, and your tech support guy better talk him down. This is our customer. It is not appropriate to say: "Look buddy, lose the paranoia, and at least enable cookies for this site," although that is the end result. Technical support workers always are walking a fine line as they explain to unsophisticated users how to reconfigure their systems without sounding condescending or letting customers know how they really feel. The problem is compounded because that unsophisticated customer thinks he knows what he is doing. It is much easier to deal with customers who admit their ignorance and allow you to walk them through a process than those who think they know what they are doing.

Are You Talking to Me?

Speaking of paranoia and cookies, why do people insist on perpetrating this fear of cookies? Check out the lead for a story that appeared on cnn.com on Dec. 29:

"NEW YORK (AP) — The National Security Agency's Internet site has been placing files on visitors' computers that can track their Web surfing activity despite strict federal rules banning most of them."

Huh? When did the federal government ban cookies? And does anybody really think the NSA would try to track your Web surfing using a cookie–even if that were possible. The NSA probably is one of three organizations in the world that can decrypt your triple DES encoded PGP message. Give me a break, CNN–or at least hire someone who understands technology.

It doesn't matter why or how we have become a nation of fearful people, we need to deal with it. Personal firewalls and pop-up blockers are anathema to Web applications. Operating systems and browsers that come out of the box totally locked down add insult to injury.

The Real Question

And that brings up the real question: How much support are we willing to give our customers? Are we willing to "teach" them basic computer skills? Are we willing to write off technically challenged customers? At what point do we draw the line? These really aren't IT decisions. These are business decisions–tough business decisions that need to be made and, once made, properly supported. External customer technical support may be the only "real" way you touch your customer for months. How you handle that support just may make the difference between retaining and losing that customer. And how much time and effort are you willing to devote to a single customer? One hour, two hours . . . four hours a month. That seems like a lot until you consider how much it costs to get that customer in the first place. Maybe a top-notch, hold-their-hand-all-the-way-through tech support team is worth the money. I think so.