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)
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.