I don’t know exactly what caused the problem. I may have crashed into a wall harder than usual while playing racquetball. I vaguely remember the hatchback of my car lightly hitting the back of the head while I was unloading something. I may have “slept on it wrong.” All I know is that about a month ago, I woke up with a stiff neck.

I didn’t think much of it. It was a little uncomfortable, and the range of motion was slightly restricted. I had to turn my head slowly to avoid discomfort. But, it was a busy time, and I charged on with my day.

As the day wore on, I became more uncomfortable. I couldn’t turn or elevate my head at all. I learned that taking aspirin or drinking out of a cup without being able to tip my head back was painful (and a little funny). By the evening, I was not a happy camper. It became very difficult to lie down. I was really appreciating the fifty-three prior years I had enjoyed without ever injuring my neck.

Twenty-four hours and a fist full of ibuprofen later, I was fine.

A few days later, fully recovered from my “neck lock” incident, I facilitated a planning session with senior IT staff of a local organization. We reviewed the thirty-year history of the outfit. Many of the people in the room had been there fifteen years or more and had a long-term perspective on some of the challenges.

In this organization, IT mostly consisted of application, desktop, and network support (application development was outsourced), and the past few years had seen a procession of frustrated IT leaders with differing visions. The scope of the support work performed by IT had expanded with the growth of the organization and the addition of new applications, but IT headcount had been frozen and budgets had been shrinking for the past eight years or so. IT wasn’t highly valued, and their budget had languished as a consequence.

The group seemed honest in their assessment: The support organization had earned its spotty reputation for service. As we discussed the kernel of the problem, it became apparent that there was danger of a deadly embrace. Business users were frustrated and skeptical of IT’s ability to deliver and hesitant to allocate more resources. Meanwhile, shrinking budgets and expanding scope were stressing the IT support organization’s ability to recruit and retain staff, and service was continuing to decay. The bottom line was that resource relief was not expected in the near term.

The new CIO had been working to improve governance with the business executives and had succeeded in getting a list of the current IT projects prioritized. The business execs, though skeptical at first, quickly embraced the notion of prioritizing IT’s work when they realized that this might influence the level of service they received.

From a planning perspective, the challenges boiled down to the following questions:

1. How can we successfully address the top ten projects as prioritized by the business executives?
2. How can we improve the level of service we provide to our clients?
3. How can we improve our clients’ perception of the quality of the service we provide?

Several people in the room were initially surprised when I emphasized the distinction between items two and three. Engineers and technical people often leap to the conclusion that the best way to improve the perception of service is to improve service. In reality, this is a necessary but insufficient approach. Marketing people often assume that if you address perception, actually improving service levels isn’t important—but let’s not dwell on those evil impulses.

People who receive occasionally poor service are used to complaining (justifiably) about it. Poor service and jokes about poor service become an expected part of the culture. Good service—the occasions when help is timely and efficient—may often go unnoticed, but bad service gets noticed and reinforces expectations. This gives expectations a great deal of inertia, because they have been reinforced over a long period of time.

When I began to explain my recent “neck lock” as an example of changing my perception and helping me appreciate a well-oiled neck, one of the meeting participants asked, “Do you mean we should go on a campaign of providing really bad service, so that people appreciate what they had before?”

I explained that the relevant part of my neck story was how much I appreciated the lack of pain when it returned to normal. When did you last wake up in the morning and feel thrilled that your neck felt normal?

“But ‘normal’ here hasn’t historically been very good service,” another participant offered.

“That is exactly why we need to encourage people to look for an improvement.” I said. “We need to get people to look for a change in service levels.” I pointed out that I was carefully monitoring the mobility of my head for the first few days after my injury had healed and really appreciated what I had taken for granted before, primarily because now I was aware of it.

We discussed the challenge of changing perceptions. Many of the people on the business side of the organization had been there twenty years or more, and it would be difficult to change their perceptions. Historically, business users had often been forced to fend for themselves when faced with technical issues. They were jaded, and their perceptions would be slow to change. When new people joined the business organization, it wasn’t long before they learned from their peers that they should expect the IT organization to provide poor support.

That suggested one target audience for changing perceptions: people newly hired into the business organization. How could we inexpensively provide them with a good customer support experience right after they joined the organization?

One of the initiatives that we identified was a program of assuring that new users received a welcome soon after they started with the organization that included providing them with a new workstation that was ready to go and a quick briefing about the software used by the organization and online resources with more information about the software (user’s guides and FAQs). Providing new workstations normally happened within a week of the new employee starting anyway, so it wasn’t net new work; it was a matter of prioritizing the activity so that new people had an initial positive experience with IT. The FAQs existed, but standard procedure was to direct users there when they called for tech support (which didn’t win hearts and minds). It was further suggested that for the first week, new employees would be assigned a member of the technical team they could go to directly with questions. It was even agreed that, after a week, the formal hand off from their “IT buddies” could happen over coffee, assuring that the new person had all his questions answered and knew what “normal” channels for support were going forward. Net cost of this initiative was pretty much zero.

Another prong of the approach was to publicize the changes that the IT organization was making to improve service. This might encourage some of the jaded, long-time business users to pay attention and look for service improvements.

A third step toward managing user expectations was making sure that the business executives were clear about the priority that they assigned their projects and assuring they understood and would communicate to their organization the service implications of not assigning a high priority to an initiative.

The organization has its work cut out for it, but these initiatives (among others) may help users recognize and appreciate improving service. Over time, this may help IT improve its reputation with its user base, hopefully leading to renewed appreciation of the service organization’s value that can be reflected in future budgets.

The next time someone says that tech support is a pain in the neck, remind him that it really is. “When it works well, no one notices, but when it doesn’t work people really pay attention.”