Bear in mind my solution comes from experience.
To answer the question, after (as I explained) the user is told multiple times on how to file a bug, then yes, it is, indeed, the user who is to blame. It's a bit like calling a support desk and telling them nothing more than that your computer doesn't work. (For all the tech knows, the computer is doing nothing more than sitting on the user's couch, watching daytime television, and drinking all of their beer.) Even better, it's like telling your mechanic that your car broke down and it needs to be fixed - but you failed to bring the car to the mechanic, let alone give the symptoms. Ain't nothing the mechanic can do at that point until they can isolate the problem. The user, in these cases, simply has not given the developer the tools needed to locate the bug in an expedient manner so as to get things moving along. Moreover, the blame goes on the person who finds the bug and fails to report in a useful way, not the developer - read on.
Consider the reality of programming. In coder land, you have people who are tasked with writing software, and if all is well, you have people who are tasked with finding initial major bugs in the form of a quality control department. In user land, you have people who expect that software is written correctly the first time every time. The reality, however, is in that, speaking for myself the only time I have ever successfully written a completely bug-free program is by 1) reading from a text and transcribing perfectly (and even then, there've been typos), or 2) writing an endless loop program in Applesoft BASIC as a child, just for kicks. On the other side of that coin, bugs happen - and software developers can't catch them on the dev side. There are seemingly infinite reasons for this to happen, but it boils down to one thing, I suppose: people just are not perfect. This is what beta testing is for - because when you really think of it, if you never get a program out of the clean room, you can't test it in the real world, and it won't be released for years, if ever, as a result of this, and if a user is beta testing a program, they need to be fully aware that stuff will break.
It's not to say that the developers need to write correct code, by any stretch - but as I indicate above, well, shite happens. But "it's broken" doesn't help anybody at all!
All considered, what I suggest here is a quick and dirty solution to an existing problem. It's far from elegant, all considered. But at the end of the day, if I just get user information that tells me something borked, and nothing more, I'm going to need more information. Presumably, what happened, what is supposed t happen, and how to reproduce. When you see plenty of reports that say little more than "that doesn't work", you kind of get to this point, and besides, there is no amount of business savvy, no certifications that can get around the fact that they need this information.