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.