Is the customer always right?

A very provocative question, some businesses live by this mantra; believing that if they simply do everything the customer wants; their business will thrive. The culture of the organization jumps every time the customer makes a request, almost without thinking.

I’m of the belief that if the customer is always right, they don’t have much need for you.

If you haven’t read the business book, The Challenger Sale, read or listen to it immediately no matter what your role – it applies to everyone in business and it is the best sales book I’ve ever read.

I was on the launch call of a Print MIS implementation the other day; the printer asked if the vendor could implement the accounting portion of the Print MIS first. This is a reasonable question which warrants a reasonable answer. The situation gets tricky if you’re operating in a culture of “do anything the customers says” because implementing accounting first in a Print MIS is not the recommended path or the best practice. The important part of this story is to recognize a “question” from a “request/demand.” In many cases, this situation plays out like this. Customer asks an innocent question, vendor interprets it as a demand, goes against their best practices and tries to make it work. The project goes sideways, the printer is frustrated, the vendor is frustrated, and nobody wins all as a result of the premise to simply do what the customer wants.

There is a simple rule you can implement to help you prevent many of these mis-understandings. When you’re in a customer service relationship and a customer asks a question, think through the question in the following manner:

STEP 1: Is the customer question a challenge or a proposed solution?

Most questions are proposed solutions to an unstated challenge (Can we implement accounting first is a solution to some unknown challenge the customer is having). Your job is to solve customer problems, not implement customer’s proposed solutions.  When it comes to software, customers mostly give you proposed solutions (e.g. can we have the button moved over there, can we support this feature or that?).

STEP 2: Proposed Solutions Require Clarifying Questions to Uncover the Challenge

Your reaction to a proposed solution has to be a clarifying question “what challenge are you trying to solve?” In the accounting question, we inquired why the printer wanted to implement accounting first, they didn’t really have any strong reason other than they were anxious to be off the old accounting software. The clarifying question uncovered that it wasn’t actually that big of deal to the printer. We simply described the best practices order of operations in a Print MIS implementation and the topic was dropped all together in a matter of minutes. Imagine if the vendor had reconfigured their whole process to accommodate this request that wasn’t even that important to the printer? What a mess that would have been! Unfortunately it happens all the time.

STEP 3: Be Patient Defining the Challenge (it’s not a race)

Most business challenges are not understood after a single clarifying question. Proposing a solution quickly makes us feel smart and for some reason we also act like it’s a race. Have you ever been on a call or in a meeting when someone states a problem and five people start talking all at once on a proposed solution? It’s like we’re playing Jeopardy, racing each other to a solution. The best thing you can do in this situation is be patient. The more clarifying questions you ask, the more the customer will talk, the more you’ll learn (if you’re listening) and the better your solution will be. The quality of the solution is directly proportion to the level of understanding of the problem. Most solutions fail because folks failed to ever arrive at anything close to an agreed upon challenge definition.

STEP 4: Give Yourself Permission to Solve it Later

When things get complicated, don’t think you have to solve the problem in real-time right after you defined it. Think it through, give it some time. I’ve found that I’ll get off calls after hearing a customer’s challenge and three hours later the perfect solution will seemingly pop into my head. I call it the background processor. The perfect solution is worth a few hours or a few days of background processing. 

STEP 5:  Some Challenges Aren’t Worth Solving

Once you’ve defined the challenge, make sure you ask the question “why?” There are endless challenges we can apply resources to, some aren’t worth solving. What is the business objective of solving this challenge? That is a VERY good question especially when it involves technology challenges. Technical folks react almost in auto-pilot to challenges, they start coding in their heads immediately. I wish I had a dollar for every time I interrupted a meeting and said, “Before we argue about the solution, tell me why it’s worth solving the first place?”

When we’re in the customer service role, the customer is NOT always right. The customer is counting on your expertise, even if it is in opposition to their opinion. Yes, this can cause some tension and this tension is worth it because it prevents a lot more problems down the line and it gives you a chance to demonstrate your expertise in guiding the customer in the right direction.

Just a brief warning here; when you change your approach to this, you will make some people uncomfortable. One customer told me I overcomplicate everything by asking too many questions. They are right, I’m complicating the definition of the challenge so I can simplify the solution and assure it hits the mark. When you complicate (by asking clarifying questions about the challenge) during the verbal phase of a project, it is so much cheaper than untangling complication written into software code or manufactured into a product. Clarity upfront comes at a cost but it is peanuts compared to having to re-work solutions that missed the mark.

Ask clarifying questions. Agree upon and write down the challenge. I see Statements of Work (SOWs) all the time where I can’t even tell what problem they are trying to solve and why. Some of these SOWs are in the six figures!