Why do you assume you're right and your customer is wrong?
Either you have enough knowledge in UX field; in this case, it won't be difficult for you to find the reason why, in the particular case of the app you're working on, having a Save button is a must-have, and how to explain that in non-technical terms to the customer.
For example, you may be in a case where the end user don't want his changes to be seen immediately online, and it can make sense to spend a good amount of time changing the content before pushing the Save button. It's exactly what happens right now: I'm editing my answer, and I while it's possible technically to make the changes visible to everyone in real-time (through WebSockets), Stack Exchange let me decide when I consider my answer is finished and should become visible to the public.
Or there is a technical constraint making it either difficult, or impossible to implement an AJAX solution. Here again, explain it to the customer, explain the additional cost, and let the person decide.
For example, adding AJAX to every form at this stage would have an additional cost of $20,000. While you consider that the ROI of this change is particularly low, your customer may have a very different opinion on the subject.
Don't plainly assume customers are wrong, especially if you need to ask on a Q&A website for arguments to support your point of view.
There are cases where customer' mistakes are obvious: in those cases, it may not be easy to find how to explain the error to the customer, but at least the arguments under their technical form are abundant and obvious. As a professional, it's up to you then to guide your customer to a better solution.
Customer: I was reading that in order to avoid issues with Unicode, data should be stored in Base64. Please, can you store everything in the database in Base64?
You: Base64 increases the size of the data with a ratio of 4:3. This means that for every 3 GB of data, you'll actually store waste 4 GB of space. Also, storing the data in this format will make it much more difficult to manipulate the data by hand during the debug and testing phase. Finally, I'm using Microsoft SQL Server and a C# application; both have a good support for Unicode. I also worked on this project and that one which used Unicode extensively, so I know pretty well how to handle Unicode and avoid the usual pitfalls.
There are also cases where your opinion differ from customer's one, and none is right or wrong. In such case, remember that:
Customer: Great. Finally, I want it to be done in PHP.
You: Frankly, I don't enjoy PHP too much. Ruby or Python can do the job too, and your server is fully compatible with both.
Customer: I know. But I still prefer you do it in PHP.
You: Is it because you have somebody in your company who knows PHP better?
Customer: No. But several programmers I know told me PHP is great.
You: Ok. But since I program mostly with Ruby and haven't used PHP for the last four years, I'll have to spend some time relearning stuff, and I would be a bit slower than if I were coding in Ruby. Is it ok for you to increase the cost of the project from $25,000 to $28,500, and move the deadline from August 10th to September 10th?