How do you know it?
When chatting with clients, I often think I wrote a perfect summary of what they just said, ask “Is this what is happening?”, and get a “lol, no. you got it all wrong”.
Well, at least I found out 5 minutes into talking to them rather than 50.
In the world of the customer, words might mean totally different things than they do to us. My dad still records his data on a “CD-ROM floppy disc”. When he talks about problems with his computer or blog, I only understand what he means because I’ve known him for years.
With our customers, I don’t have this luxury. I don’t know how their experience with WordPress looked like up to date. Because of this, I can never be sure they have the same thing in mind as I do when they say words like WordPress or WooCommerce.
All I can do is guess what the customer meant, consciously or not. When telling them “Problems like this are often caused by plugin conflict”, I’ve already made an assumption about what their problem is, and what is causing it. This assumption might be very high-level (“There’s something wrong with the checkout”) or detailed (“There’s a JavaScript error on the checkout page preventing Stripe scripts from collecting all needed data”). But it’s there, and it’s shaping what kind of advice I’m going to give.
But how do you know your assumption is right?
Unless you’re a mind reader, there’s very high chance that you don’t. There’s only one way to find out: ask them.
Say you just got an email, where it’s clear at first sight English is not the first language of this customer. They’d like to buy one of your products, but it’s not quite capable of doing what they want. The second best thing looks weird, but might still be worth considering, depending of their motivation. You’re not even sure if you got their question right.
Now how do you communicate this to the customer?
1. Repeat everything they just said, in your own words. Add screenshots where possible.
The customer took their time to explain what they want in the best possible words they could find. It’s always a good idea to thank them at first.
If I think I have a good grasp of what’s happening, I start with “I see what you mean.”. When I have no idea, I go with “I think I got it”.
In your summary, show how you understand the specifics (“size 39-42 or 43-46”) instead of talking in abstract terms (“the product has variations”). The user doesn’t want variations, they want to sell socks that have different sizes. If you’re not sure what the specifics are, guess. Worst case scenario they’ll be able to show you where you’re wrong.
To guess what the customer wants, I usually use Toyota’s 5 Whys, and stop one step before “To make money”. What do they want to do to make money? It’s never “setting up product X” or “creating shipping zones” but rather something like “selling socks at different sizes either separately or as a part of a bundle”.
2. Give them room to correct you if you’re wrong.
This is easier in chat, when you can get a “lol, no” in a matter of seconds. But even in email it’s helpful to check in and make sure you’re on the right track. You do want to make sure the customer is heard and understood. Show them this, and you’ll have them on your side even if you got it wrong.
3. Explain what is possible. Be super specific.
Sometimes there is no option to achieve the result the customer wants (or what you think they want). Still, you can at least show them how it works by default. Set it up on your test site first, to make sure the product does the thing you remember it doing, use the same names as the customer (“Red socks, size 39-42”), and take lots of screenshots to illustrate how the whole thing is working.
Even if it doesn’t quite do what the customer is asking, who knows? Maybe they’ll decide that selling a mix and match of different sizes is worth considering too?
4. Suggest next steps.
I always try to find a perfect fit for the customers’ needs, or at least give them a workaround, link to a coding tutorial, or even a competitor product. Sometimes, I don’t even have these and my options are pretty limited.
Still, the least I can do is to suggest sending us a feature request, or hiring a developer. The first option might take ages and the other one will likely be costly, but that’s for the customer to decide.
5. Wrap up, but let them know you’re open for questions.
Maybe you did get it completely wrong. If you clearly outlined your whole thought process, they’ll have a chance to say where exactly.
Even if you’re unable to help them, you’ll at least make the customer feel heard and understood. This too is an important part of engineering happiness.
***
Originally posted on one of Automattic’s internal P2 blogs, adapted for folks who don’t know our secret lingo.