In my department at Michigan State University, we are having interesting conversations revolving around the notion of “customers” and “partners” for the people that we serve. In many IT organizations, like many other service organizations that exist, there is a well known notion to call the people that depend on you for service as “customers.” We are told to treat these people as “customers first” in an attempt to think about how to best evolve our own service to make them happy. We have come to realize that while we call them customers, and attempt to treat them as if they were customers at, let’s say a grocery or department store, we really don’t.
Really, most IT organizations need to make a decision on how to serve the people that depend on them for service and decide how they really want to interact with them. There is not a single right or wrong answer, but you can’t choose both. The method you choose really depends on your own overall organization and how you feel you can best serve them.
What is a customer? A customer is a person or group that approaches you to fill a need. Let’s say they need a new printer and they contact you to order a printer. You might have one or two models that you support and you offer it to them. The customer agrees to one of your options and you order it, install it, and make it work on their PCs. You provide service with a smile and everybody is pretty much happy — you were able to fill their need, and they were able to accomplish the task they sought out to do.
Where the customer methodology typically breaks down is when the customer has a need that can’t be filled by your typical offering. How would this methodology change if, lets say you only offered black and white laser printers, but the customer needed a high-capacity color printer. Would you allow the customer to go somewhere else and get the printer that best meets their needs? Would you get the printer they found that fits their needs, or would you tell them “NO.” The best fit for this methodology would have been to allow the customer to buy their own (or even better, for you to buy that model and do what you do best) — however many IT departments feel that they lose control and can’t possibly support that “one-off.”
A printer is a pretty easy thing to visualize — it’s tangible and something I’m sure IT departments already deal with multiple models of. But think about other examples where customers have made requests — like PC models (like a Apple Macbook), operating systems, CRM software, browsers, etc. Often times, if a customer is making a request for a particular piece of software or hardware it’s for a reason — and if you treat the end user as a customer, you have to be prepared to allow them to make those choices. This often involves bending your own standards to allow them to make the best decisions for their own organization. After all, the customer probably knows their line of business much better than you do.
This method is all about providing great customer service and allowing the customer to do what they need autonomously.
What is a partner? A partner, or an even better term would be a business partner, is somebody that you work with to accomplish a goal. When a group approaches you to help solve a problem or business need, they will depend on you to help them make the best decision. But being a partner is not a one-way street — it also requires you to approach the end-user and ask them how you can best help them accomplish their goals. There is a clear nuance here, but let’s dive into this a bit more.
Using our earlier example of a customer needing a new, specific printer, a business partner should have noticed the requirements of that user before they formally asked for help and offered to help mitigate the need. This could have been forming a better partnership with an outside entity for doing those color prints, or maybe partnering with an inside organization that also has a similar need, or proposing getting the printer. Conversations change from “What can I do for you?” to “Can we suggest XYZ to make your life easier?” A quick consequence of this relation often is that changes to it systems are often done for the benefit of the end customer, rather than the IT group (ask yourself how many of the IT policies that are in place are to make it easier to manage your systems, vs. helping the customer).
Now the downside of being a partner is that it is much more human capital intensive. It requires that your IT department becomes involved in all the line of businesses that happen at the organization that you support. It requires that they have at least some institutional knowledge of accounting, etc. in order to help these organizations. I’ve seen some implementations of this where the IT department has their staff distributed among all the groups they support — for example, they might have a cube next to the secretary so they can glean how they do their job and be their advocates in the overall IT plan. Other ways to accomplish this would be to have certain people “deputized” (actually have access to work on systems that the group needs) within these groups and represented in IT staff meetings, again to help evangelize what the needs are of the groups they represent.
This method is really about empowering the end group to participate in IT.
The danger zone. Where a lot of IT organizations run afoul when serving others is that they pick either neither of these methodologies or, sometimes worse, pick BOTH. Hybrids of these methodologies never work — because quickly everybody becomes confused in their role. The most common is where a customer is told they aren’t allowed to install or request application X onto their PCs to fulfill a role, yet their IT department also refuses to give them any alternative to do their job (neither methodology is chosen). Another example would be that the end user is allowed to chose a particular piece of software to meet their business needs, but then expects the IT department to change the way they do business in order to meet the needs of this software (both are implemented).
IT departments need to also be careful to not switch methodologies on customers either. Either allow them to be a customer or a partner — don’t change on a project by project or product by product situation.
How do you interact with your end-users? This may be the most telling way of how your operate as an IT organization. You do have helpdesk software that you ask people to “put in tickets?” or a common phone number that you direct all users to call for every IT interaction? You are most likely treating end users and groups as customers. Do you have staff sit in organizational meetings (other than meetings with groups like department heads), or invite end-users to your department meetings on a very regular basis? You might have business partners in that case.
Some questions to think about as you assess your IT business :
- Do you know the IT strategy of all your organizations businesses? If you don’t think they have an IT strategy, you may want to ask.
- What was the last software that you installed for an end-user that was “non-standard”. Do you know why they requested?
- What was the last software that you didn’t install for an end-user. Do you know what business need they were trying ti fill?
- What was the last thing you did to increase productivity to an end-user? Is this something that you brought to the table, or something they requested? Did this actually increase their productivity?