Hacker News Reader

Comment by hiAndrewQuinn | Hacker News Reader

The problem can't always be resolved or even compromised on satisfactorily, however. So you have a game theoretic 2x2 matrix of options:

* Validate emotions + solve the problem: Most people consider this excellent service, and some people consider it at least adequate. Very few people will complain about this.

* Do not validate + solve the problem: Some consider this excellent, most consider this adequate, some consider this a slight even though the problem is solved.

* Validate + not solve: Most people will be annoyed, but at least be civil about it because you've been civil to them. A few will lash out, but they were going to anyway.

* Not validate + not solve: Virtually nobody likes this.

The game theoretic optimal solution for a service provider is to always validate, and hopefully solve the problem as well.

View on HN

> The game theoretic optimal solution for a service provider is to always validate

Which can be a mistake when the person you are dealing with has or may have an ulterior motive for your interaction (i.e. said "toddlers").

This is why in actual customer service, validating someone's feelings ("I understand you did not like the cook on the steak") is good, while validating their concerns ("I understand that the steak was undercooked") is bad.

You don't want to "find common ground" or "shared viewpoints" just to fulfill the validation matrix plot, because it may very well be based on a false premise, or even a blatant fabrication. In real world terms, validating concerns can often be an admission of liability or fault, or a soundbite that will be weaponized against you.

> This is why in actual customer service, validating someone's feelings ("I understand you did not like the cook on the steak") is good, while validating their concerns ("I understand that the steak was undercooked") is bad.

Well at least to some people, this makes it look like a sleazy attempt form customer service at deflecting blame from a fact ("the steak is undercooked") to a feeling from the customer ("you just don't like the steak, but I don't believe you when you say it's undercooked").

It immediately makes the person seem less human and more like a customer service robot. I'm pretty sure most people hate it, but maybe I'm wrong.

Yeah, no. I don't want to end up in a lawsuit because I agreed with the customer offhand that the steak was undercooked. I'll stick with "I understand the steak was not to your liking. May I ask the chef to bring you another? Drinks are on the house, by the way." You can't sue an agreeable robot.

If you assume I can take a good look at you and just know you're the kind of guy who would never do that, you're assuming a level of sight-reading people that even most police investigators don't have. I'm sorry, I'm only human, and I'm waiting five tables simultaneously right now.

Oh hey bad news you just got double sat and one of them has actually been here for twenty minutes but the host forgot to drop menus so everyone thought they were already taken care of. Also table three has a gluten and allium allergy, they want to know if the beer battered onion rings can be made with suitable substitutions. Also, sorry, final thing but I'm quitting right now so you'll probably want to take care of your drinks yourself

Validating facts is good too.

If the steak is blue and they ordered medium ... then there is little room for debate. If they wanted something other than what they ordered, then validating the feelings is more appropriate.

> then there is little room for debate

And that debate can be had (or not) by a lawyer or perhaps a manager, whose job it is to do so. No server is going to be vested with that authority, nor wants to be saddled with the uncompensated responsibility to.

> * Validate + not solve: Most people will be annoyed

Actually, if they came to vent about a problem that they don't view as solvable, then validation only is what they're looking for.

e.g. When your partner tells you about their difficult day at work, or your friend tells you about a bad date that they had, they're not usually asking for advice. They just want emotional support.

Spotting when this is the case is useful. Trying to solve it when validation and empathy is what's wanted can be the more annoying response.

https://medium.com/musings-with-meg/the-first-question-you-s...

I'd argue that by solving their problem, you are agreeing with their feeling that whatever was happening was a problem worth fixing. So in essense, validating it.

I can't really think of what #2 would look like (solve but not validate)

User files a ticket for their computer, then goes to lunch. IT fixes the problem and closes the ticket while user is at lunch with nothing but an email "we've resolved your ticket" and user discovers it is in fact solved. Some people will still be mildly upset because they didn't get to talk to the technician and give them a story or socialize, or they start calling the IT team "ghosts"

Hmmm, I'd argue that there's two separate problems here:

1. The desire to have a working computer, which was validated and solved

2. The desire to be connected to the process and the people they're working with, which was neither validated nor solved

Validating but not solving the second would include some sort of message saying that you know they'd rather a call but it helps you serve more tickets this way, or something to that regard.

3. Understanding, Independence and control. The desire to continue to have a working computer in future, and to have own control over that by knowing what went wrong, how to avoid it happening again and what to do after. "There I fixed it." does not help with this. It is low information and high dependence.

Some would draw the conclusion that the person doing this is deliberately maintaining high dependence. That may be paranoid (The tech person may just be overworked and find social explanations harder than fixing computers) but some do draw that conclusion.

I'm annoyed with that kind of response because I want to know what was broken, so I can keep an eye out for it in the future or be careful not to trigger the behavior.

Those messages can be a little short. For the back end staff, I hope they collect meaningful information to resolve subsequent issues down the road. But I don’t expect the user to respond to the IT staff w “thank you. I can verify you solved my problem as I can now perform eigenvalue decomposition” What pissed me off was my occasional lazy employee who would report the problem fixed but no verbiage as to what was fixed. Problem would reoccur and everyone would be frustrated.

"You are a total wimp for wanting gloves in this weather! Here they are though, you weakling."

Still acknowledges that they understand youre feeling cold and that you'd rather not be.

I guess it doesn't agree that it's something you should be feeling, just that you are feeling it.

Maybe its a definions thing, idk which of the two validation is supposed to refer to

> which of the two validation is supposed to refer to

In this context, it's the former. If I say, "It's dumb that you feel that way but here's you're stupid gloves," to a toddler, I solved their problem but I also likely made them feel like their problem is somehow not a "valid" one. Especially when this happens repeatedly to children is when they grow up with particularly anti-social behaviors, for fear of others abusing them similarly.

the game theoretic is to notice that +validate -solve is cheaper than +validate +solve, and capitalize on that. -validate +solve is the Comcast and Spirit airlines approach, so it's also valid

Comcast and Spirit both run their business on NOT solving problems.

In fact Comcast is one of the few cases where I've had a customer service rep commit outright fraud. Validated my problem, responded to my questions, told me they did X when in fact they did Y (which I would not have found acceptable and they were fully aware of this).

It's the alternative option that most people don't realize is in the table. Validate, pretend to have solved, don't actually solve.

Reply on news.ycombinator.com