As some of the other folks said, I'd be reluctant to commit to a percent of defects reduction, especially since the number of defects that are found in the field at any given year is very dependent on your product cycle. Unless you can be sure that all of your users are always using the most recent version of the product, there's an unknown/unknowable number of defects that are currently baked in to your numbers. And even then, if you have 15 customers, and 5 of them bought the product, but haven't actually used it yet, they're probably going to find some number of defects whenever they do start using the product, and that's out of your control. And at some level, would be a good thing. More defects can mean lower quality, but it can also mean more users, or more usage, or different usage, or a number of other things. If you're providing some sort of managed service, you might be able to ignore some of the above, but not all of it.
If you do want to reduce defects, you need to understand them. There's a methodology called Orthogonal Defect Classification that you could take as inspiration, if not use it exactly. It does require a fair amount of historical data, and also a defined development and test process, and depending on the size of your development/test team, may not be appropriate to use as is.
But you could use part of it, namely, review all of the defects found in the field, and think about what it would have taken to find the defect prior to it being found in the field. Was it a design issue? A load/stress issue? A serialization issue? Related to a specific hardware or software configuration? A problem with some sort of recovery code? Functional regression? You need to be very honest with yourself/your organization when doing this review. At some level, once you know that a problem exists, you can probably envision ways you could have found that specific problem. But you need to think about problems in terms of classes, not individual problems.
So if, for example, if there was a video card driver that revealed a problem, the way you would have increased your chance of finding that class of problem would have involved running a host of test systems with different video cards, and many different video card driver levels. And that would be an ongoing effort, because nvidia and AMD put out drivers on a regular basis, so you'd need to test all combinations of currently supported levels of the software every time a new driver was released.
So, after you've reviewed the defects, sorted them into classes, and then thought about how you'd find that class of problems, then you can put proposals for reducing defects together. It's possible you'll find a class or classes of defects that you could find quickly and easily, and that would be great. And there may be other classes that could have been prevented entirely if the developers had code reviews, or used different compiler options, or whatever. But after any of those, there's a business decision to be made, as there are going to be either tradeoffs or some sort of investment required, and the powers that be will need to decide if finding that class of defect is worth the investment, either as a one-off cost or an ongoing investment. Or, if they don't want to make the investment, but do want to reduce the likelihood of a certain class of defect being found in the field, some other classes of defect are likely to increase as you reduce one sort of testing to focus on another sort. (Although you may be able to, by analyzing the problems you find in test, find areas/methods of testing that aren't finding many problems, so you could potentially recommend certain areas as being less risky to reduce than others.)
So, I'd be very reluctant to commit to a percent of defects reduction. What I would commit to, after doing the analysis, is making changes to the development/test processes that would reduce the likelihood of classes of defects, and then give the powers that be a list of other classes of defects and what the cost of reducing them would be.
And then you need to keep doing the analysis, probably for several years, to see if you were correct, and you have reduced the number of defects of that class (relative to product usage), or if you need to make some sort of course correction.
