I don't know, I feel like if you build something, and it's defective, that you should fix it free. I would expect the same from a car mechanic. I get that software is a hard thing and bugs are inevitable. I'm curious what other people do.
Also, i've noticed in my own work that people are always eager to blame problems on whatever component is the cheapest/easiest to solve. If you charge $50/hr for application support and the guy they contract to do virus scans and run disk defragger costs $40/hr, their first call will always be to him, not you, no matter where the actual problem lies. Somebody at their office has figured out that whenever a user has a problem, it's cheaper to pawn the problem off to you and let you do the triage than it is to triage it themselves before calling you. Even if you don't start charging for bug fixes, you need to start charging for wasted time.
One is to cap your hours/cost. Just build in 40 hours (or whatever) of bug fixing for the first month into the price. Line item it, so the customer knows what he's getting and what it costs. Often customers will complain about this cost, and say they'd rather pay a la carte. Bingo. But if they don't, you have now set clear expectations about what is being provided.
Another is to make bug reports consumable. For reference, Apple has a bug fix consumable called a DTS Incident where you pay in advance to have N bugs investigated. Something you may want to consider if the bugs are all invalid is requiring somebody to pay to file a report, and if it turns out valid you refund their money. This may lead to more disputes though it's unclear if disputes are a problem in your situation. In that case you may want 2 hours of your time no refundable for every report.
The third thing is technical, and it works even if you don't have a good contract in place. Become omniscient. Log really detailed, invasive things and phone them home. Every user action, all the user's data, etc. Then when the bug comes in you cross-check against the logs and can verify quickly. "No you pressed the delete button, that's why you don't have any data. Not because a bug in the app destroyed it." Make it clear that you are doing this and make it clear that you will disable it, but disabling it voids the warranty.
Having all their business data logged doesn't sound like a condition that any reasonable customer should agree to. In some cases, such as healthcare related data covered under HIPAA, it would be outright illegal. Asking for this kind of arrangement tells your customer that you don't understand the importance of confidentiality and security, and also tells them that you think they're so stupid that they don't know the difference between a bug and a user error. If a contractor suggested this condition to me, I'd show them the door immediately.
You'd also be taking on a serious risk. Even if it was legal for you to have the data, it could open you to legal liability if through some error of yours the data was compromised, costing the client money. And if you had possession of the data, you might get blamed even if the data leak wasn't your fault.
Even if you logged the data on the customer's own machines, bad things might still happen, like a bug in your logging code logging confidential data in plain text when it was supposed to be encrypted. It could then fall into the hands of an employee who wasn't authorized to see it.
Any business that uses SaaS or externally-hosted software agrees to this. The question is whether your vendor has a reasonable access policy for that data, and what "reasonable" means hinges a lot on your vertical and the kind of data you're storing. PCI is a completely different ballgame than button clicks for example.
Increasingly, plenty of non-SaaS products work this way (e.g. Tesla cars, OnStar, your iPhone, apps in the Windows Store, etc.) Again the question isn't so much about "whether" to collect usage and bug reporting data, it's about getting the defaults right and educating concerned users to tweak them to a level where they are more comfortable.
> also tells them that you think they're so stupid that they don't know the difference between a bug and a user error
This is literally the case that OP came to us to solve
Make it entirely clear and transparent what you're working on, including time spent bugfixing, and if they're unhappy they can take their business elsewhere.
This of course puts great incentive on you to write high-quality code, because your failings in that area will be visible as bugs to the client.
Recurring revenue and the client is happy: they are now able to budget their costs.
I can understand why you feel this way, but I don't think it applies to software as much as it would tangible goods or service.