We manage huge internal networks. We provide technology servicesto remote facilities. We support thousands of external consumers ofour products. We have Web sites, CRM systems, accounting systems,straight-through application systems, claims submissionapplications, etc.–literally scores of applications and manycategories of customer. And what do all these data processingsystems have in common? At some point in time they all will requiretechnical support.

Technical support for computer systems has becomeextraordinarily difficult. Why? Because the rapid proliferation ofpersonal computers and applications to serve those computers hasbeen done without proper attention to standards. The Internet hasserved only to exacerbate the problems we create by ignoringstandards. In addition, computer users have come to believe anyproblems they are experiencing must be caused by the provider ofthe service they are consuming. I can't think of any other branchof technology where this is the case.

Consider radio. For most commercial radio broadcasts in NorthAmerica, there are two sets of standards that must be adhered to.One is based upon amplitude modulation of the carrier signal (AM),and one is based upon frequency modulation (FM). Each has a definedset of frequencies on which it can broadcast as well as regulatedpower limits. Radios are commodities that are readily available andcan be counted on to receive and translate signals and deliveraudio to the user. Contrast this to HTML.

We Don't Need No Standards

There are HTML standards, which the World Wide Web Consortium(W3C) defines. The problem is nobody bothers to adhere to them. IfI create an HTML Web page using Notepad and publish it on theInternet, chances are everyone who has a Web browser will be ableto view that document. However, hardly any of the players in thebrowser world interpret HTML in the same manner. They all havetheir own set of rules loosely based on W3C standards. Not onlythat, but none of the tools vendors provide us to create HTML playby the rules. Create the same page using Dreamweaver, thenFrontPage, then Word, and take a look at the source. Scary. Forsome reason, everyone in the PC world seems to think it is good tooperate outside of the box.

The Web applications my company delivers clearly state they willoperate correctly using only Microsoft Internet Explorer versions5.X-6.X–not because we love Microsoft or are convinced Microsoftdistributes the best browser but because we know more than 90percent of our customers use those browsers. Nevertheless we stillget the technical support call from the guy with the browser hebuilt using modified open-source code, which for some reasondoesn't run our application properly. Furthermore, he has been aloyal customer for 32 years, and he is going to have my head if Idon't do something about this. Sound ridiculous? Sure, but thesesituations really occur. I don't understand it. My bank tells me Ineed to use IE for online banking. Even though Firefox may be mybrowser of choice, I use IE for banking.

It's like someone building a radio that decoded only AM signalsbut operated in the FM frequency range–and then calling the radiostation to complain that he can't "hear" the broadcast. Or howabout taking a working FM radio while exploring some caves and thencomplaining the station was not working? Is that any different thana computer sitting behind a firewall with a crazy proxy server andport 80 locked down? Computer users are difficult to work with. Ilive 30 miles from a major metropolitan area. I don't get goodtelevision reception with the built-in antenna. I know I eitherneed a rooftop antenna or must invest in cable or satelliteservice. I don't expect the television station to solve myproblems. Yet a customer sitting on an AOL dial-up using a 486system with Netscape 2.0 will call me and complain our Web site istoo slow.

Problems

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

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

o External "employee" customers–people, such as producers oragents, who are involved in selling our goods or services and mustuse our systems to enter orders and interact with the "homeoffice."

o External end-user customers–those users who access various Websites either to gain information or to purchase a policy or modifytheir information.

It's All About Control

The first class is the easiest to handle. You have completecontrol over employee-customers' hardware and their installedsoftware. They all probably are using cloned boxes, are securedtightly behind firewalls, and have antivirus protection you haveapproved. If there are real technical issues with these folks, theyare limited possibilities. Maybe your application is buggy. If so,then you are getting good information you can work with. Maybethere is a problem with the box–hardware failure or softwarecorruption. That is easy enough to test and repair. The remainingpossibility is user error, and that can be solved in a number ofways. Help-desk support for these customers is critical and oftencan be handled quickly and easily.

The second class–folks who are in the middle of the moneychain–can provide more challenges for tech support, but theseprobably can be mitigated by good design. Remote agents or agenciesmay need to access your policy admin system to quote or write apolicy. Hopefully, they will be using software supplied by you oryour contracted third party to access your system. The tighter thecontrol you can maintain over the user, the less likely you will beto experience failure. There is a greater front-end cost to equipagencies with software to communicate with your internal systemsthan to deploy a Web-based system, but the extra control is wellworth the expense. Yes, in a perfect world, we should be able touse Web services via .NET or J2EE to deliver Web applications thatcan be accessed any time, anywhere, by anyone. But we don't live ina perfect world.

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

If you couple that with the never-ending stream of securitypatches, you will face a technical support nightmare. You can useHTTP over TCP/IP as well as all available industry standards–buttry using a piece of software you own to conduct business. If youown 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 atleast can minimize the amount of technical support needed tosupport them.

The Buck Starts Here

That brings us to the great unwashed masses. Those folks at thebeginning of the money train. Your paycheck ultimately starts withindividuals who purchase the insurance policies or financialservices your firm offers. Lose that customer class and you havelost your business. Providing adequate, timely, and usefultechnical support to this group presents enormous challenges.

We all have taken that leap of faith that tells us to dobusiness successfully in today's world, we must have Web sites.Those Web sites originally were intended to serve our customers byproviding them with information about our products. Most firms alsoallow customers to purchase products, modify their personalinformation, and complete online transactions–which may range frompurchasing 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 theyare ready to do business now. That means when the log-on page keepscoming back around, your customer wants an immediate resolution. Itdoesn'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 KrispyKreme, and your tech support guy better talk him down. This is ourcustomer. It is not appropriate to say: "Look buddy, lose theparanoia, and at least enable cookies for this site," although thatis the end result. Technical support workers always are walking afine line as they explain to unsophisticated users how toreconfigure their systems without sounding condescending or lettingcustomers know how they really feel. The problem is compoundedbecause that unsophisticated customer thinks he knows what he isdoing. It is much easier to deal with customers who admit theirignorance and allow you to walk them through a process than thosewho think they know what they are doing.

Are You Talking to Me?

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

"NEW YORK (AP) — The National Security Agency's Internet sitehas been placing files on visitors' computers that can track theirWeb surfing activity despite strict federal rules banning most ofthem."

Huh? When did the federal government ban cookies? And doesanybody really think the NSA would try to track your Web surfingusing a cookie–even if that were possible. The NSA probably is oneof three organizations in the world that can decrypt your tripleDES encoded PGP message. Give me a break, CNN–or at least hiresomeone who understands technology.

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

The Real Question

And that brings up the real question: How much support are wewilling to give our customers? Are we willing to "teach" them basiccomputer skills? Are we willing to write off technically challengedcustomers? At what point do we draw the line? These really aren'tIT decisions. These are business decisions–tough business decisionsthat need to be made and, once made, properly supported. Externalcustomer technical support may be the only "real" way you touchyour customer for months. How you handle that support just may makethe difference between retaining and losing that customer. And howmuch time and effort are you willing to devote to a singlecustomer? One hour, two hours . . . four hours a month. That seemslike a lot until you consider how much it costs to get thatcustomer in the first place. Maybe a top-notch,hold-their-hand-all-the-way-through tech support team is worth themoney. I think so.