At some point, most IT leaders or practitioners will run up against the conflation of the terms “customer” and “user” within the context of managing a program, project, or service. This is especially true for those of us who cut our teeth implementing business applications such as ERP or Student Information Systems. On the one hand, during those projects we tend to involve large numbers of end users in the requirements, design, and acceptance testing process; these activities tend to give their participants the opportunity to define the solution. We take our cues from them and tend to want to make them happy; to the business systems analyst or functional consultant these end users are without question "the customer.”
But the harsh reality is that most of those end users do not pay the bill, so to speak. According to several management frameworks -- most notably the IT Infrastructure Library (ITIL), at least in my world -- the term "customer" should be reserved for those who pay; such an entity often represents the interest of many end users, and may or may not be a user herself, but critical differences in priorities, needs, and influence exist. For example, users may desire additional features but the customer may not want to pay a premium for those features. Unfortunately, service providers are often stuck in the middle. To exacerbate the problem, there may be cases where the (paying) customer refuses the surcharge but delivers the message to their users in a way that ascribes blame to the service provider rather than own up to her decision(s).
The problem of differentiating customers versus users can be especially acute for those individuals serving in the perhaps-misnamed function of "customer service." These folks may never have a direct interaction with the Big C Customer, but instead stands on the front-line fielding complaints, concerns, and issues (and occasional praise) from the users, the actual consumers of the service we provide. People in customer service roles often land there by virtue of a passion for helping people and solving problems. Their relationship with the user community is tangible and grounded; in the same way they seldom interact with customers, their managers and managers' managers seldom interact with the users. This disconnect presents real challenges, especially when organizations start rolling out IT Service Management and try to re-align processes and functions to meet the boilerplate from the Crown.
At a recent all-day retreat for my organization, we had a group activity on stakeholder mapping. It was not entirely successful, except insofar as it cast light on this divide. In fairness, we face a few (not quite) unique challenges that make a complicated problem worse. First, the issue of being an internal service provider. We are a pure cost center; no revenue flows into my organization. In such a context, we cannot define "customer" by virtue of bill-paying criteria. But we ought to be able to think in terms of leadership, right? Except that our institution is extremely decentralized. And unbalanced: not all organizations are created equal. Some organizations (the schools, in our case) indirectly pay (via a central assessment) for our services, whereas other units in Central Administration, funded from that same tax, receive the services "for free." And then there is the issue that in some cases we provide services on behalf of another unit in Central Administration. So is that unit -- and that unit only -- our "true" customer?
All of this isn't to say that user satisfaction isn't important. At the end of the day, the customer, whoever that may be, will not be happy if the users are banging down her door, rioting in the hallway, screaming in her ear, or otherwise demonstrating discontent with the service. We have to listen to the users; they are the subject matter experts, they do the work of the place. It is tricky business to simultaneously roll out new user satisfaction tools and say that users aren't really the boss.
The problem is that we know we cannot meet their every desire. For us to succeed, we need customers who prioritize, advocate for their users, and communicate with their users when a request does not move forward.
For this to happen, we need to formalize our Business Relationship Management (BRM) processes and develop a clear, (relatively) jargon-free customer outreach packet. In addition to obvious content such as org charts and walk-through of our service catalog, this document articulates the tension between customer service and user demand and defines the relative roles and responsibilities on both sides of the service delivery process.
In the end, we walk a very fine line! But recognizing these tensions is certainly a critical step in helping us keep our balance.
Labels: ITIL, ITSM, Management