I have the opposite problem with many technical support teams these days. I supply them with a full breakdown of what error I encountered, the reproduction code/commands/data, my configuration, what I think happened, how I tested for that, alternative explanations I came up with and tried, traces, trace markers, vendor-standard dumps, and a call to action of the next piece of information I need (usually an explanation of what is exactly happening inside a specific function call that the trace doesn't reveal). I did what I dreamed of receiving when I fielded technical calls back in the day but never did, and am trying to follow all the vendors' own support guidelines of what they want to save everyone time.
There are so many offshore teams these days that I wonder whether the volume of what I supply in my support tickets overwhelms the English as a second language support engineers' total comprehension abilities, between the combined English-to-native language parsing and internalization of the case details itself. About 9 out of 10 times now when I reach offshore engineers, there are responses with blatant signals they simply did not read through even a third of what I painstakingly put together. With English native speakers, it is closer to 1-5% depending upon the vendor.
No shade to the offshore teams, but it adds an unnecessary debugging cycle for them, I suspect they're under insane metrics to uphold incentivizing this behavior and I just politely point out where I already gave them the information they're requesting. Most of the time they simply escalate the case straight towards the development team.
> I suspect they're under insane metrics to uphold incentivizing this behavior
This is likely to be it: perhaps they are effectively paid by the ticket or response (due to how pay/bonus/other structures align) so paying attention to all that information costs them significantly. Their ideal is to get a reply to you ASAP so they'll prioritise tickets where they can bang out a link to an existing knowledge-base article.
> No shade to the offshore teams
In some cases it may also be that they are employing cheaply rather than not carefully, so some of the people aren't great to start with (either technically, in terms of their claims to understand English well, or both), but I think you are right generally to give them more credit than that and suggesting that most of the time it is due to unhelpful metrics & targets (you get what you measure!). That and failing to provide sufficient support/documentation/training to the people trying to help you (sometimes you might know far more than them as they first saw the system last week).
> Most of the time they simply escalate the case straight towards the development team
They are likely not to do this on first response, even if it is very much the right thing to do in a complex case, because of a negative metric deliberately in place to reduce load on dev teams (which may be as under-staffed/under-trained and more over-worked than the support team).
> I have the opposite problem with many technical support teams these days. I supply them
I try to be forgiving about lack of information in the initial request, as long as they are understanding about my response being a curt “I need more information” and a list of example data¹. If I ask for more information and just get a vague response, that is when I knee-jerk hit the CNR button.
----
[1] the standard “what was on-screen, details of the form you were editing², what did you do, what did you expect, what happened instead, include error messages³ and data you entered², and at what time did this occur (be as accurate as you can)⁴…”
[2] which parts of this may vary significantly depending on the situation, and providing all possible information may be a waste of their time and mine, which is part of why I try not to mind the initial information being slight vague.
[3] this doesn't tend to vary, as a rule I always want to know any messages that were emitted and feel justified in being immediately irritated when this data isn't included from the start - “I got an error” does not suffice.
[4] this can be as vital as the error/exception messages, sometimes more so, if I need to go diving into logs for further clues.
There are so many offshore teams these days that I wonder whether the volume of what I supply in my support tickets overwhelms the English as a second language support engineers' total comprehension abilities, between the combined English-to-native language parsing and internalization of the case details itself. About 9 out of 10 times now when I reach offshore engineers, there are responses with blatant signals they simply did not read through even a third of what I painstakingly put together. With English native speakers, it is closer to 1-5% depending upon the vendor.
No shade to the offshore teams, but it adds an unnecessary debugging cycle for them, I suspect they're under insane metrics to uphold incentivizing this behavior and I just politely point out where I already gave them the information they're requesting. Most of the time they simply escalate the case straight towards the development team.