Advice: Start with hourly fixes. Unless you are dead confident in your code and the airtightness of everything you put in a spec and put blueprints on, go hourly.
Why?
Every time I have launched a new project I try to leave it hourly to build a history of cases that need to be resolved. Once I have some data (average amount of time to fix, type of bug, etc) to back it up, I see if I can average out a price for the year. So If I figure I use 100 hours a year of "support", I can then come up with a yearly cost, pad it due to the programmers genetic make up of underestimating and then present it.
Critical considerations for service contracts:
First, it has to be good for you and them. It has to stay good for you and them. There can't be more bad months than good for either of you. Regardless of what you are paid you will have to present value or lose the support agreement at renewal.
What does it cover? You must be careful when it comes to Fixing "anything". Becoming the catch-all to support the entire application even if it's not your problem (hardware, or network issues, etc) is very costly, first to your time, and second potentially to your image, if you are being called for a central support resource for the entire application.
4 Hour what? 4 hour response is much different from 4 hour resolution. The only thing you can offer is the first, the second is a bonus for 60-80% of cases. If they want the latter, add a zero to everything. You may need to staff an extra person. You will also have to track your own performance (response time, etc.)
Define Support. Training? Meetings? Answering Questions? Bugs only? Don't become a free department that needs to be on call 24/7.
Priority. - I set all my cases with priority. Only Priority 1 or 2 cases (out of 7) should be 4 hour response time. That way any fires get attention appropriately and the smaller bugs keep getting fixed.
Cap the hours/bugs monthly. - Cap the number of requests, or fixes per month if you insist on going on a support contract. So, up to 50 hours a month, or up to 10 priority 1, and 10 priority 2 cases, etc. Anything beyond 15 blazing infernos a month and its x per incident, where each incident is so many hours. It entirely depends on your customer and their habits. The ones who break stuff a lot and need more of your time and attention personally will need more checks and balances for both sides to be happy.
Be optomistic, but be realistic. With a new project neither of you know what may come. So for you to cover your unknown, what could be the absolute worst amount of time that could be spent? It's often best to work from worst case estimates instead of best case. What you're selling is essentially an insurance policy. The more unknowns and lack of data history there is, the higher your insurance policy would be, right?
Have an air tight process. - Have a mutually agreed upon way of defining what is support and what is a "change request" for new or modified functionality. Be sure you have the appropriate signoffs for analysis (mutual interpretation), design (how you're going to build it), and signoffs for launching so there can't be any pointing back to mis-interpretations or mis-understandings.
Subtle abuse - Clients, often, will make you do the leg work after a contract is up. Something looks wrong... but isn't? Send it to you to figure it out. Over time you can spend so much time supporting inquiries of where "it isn't working" when, in fact, someone is simply using you as the path of least resistance to answer their question, or what they are assuming about how it works since they have forgotten. So, to clear your name you have to show that it was how the system was used.. and not something that happened spontaneously like a bug.
So, after all that.. how to bill?
Sliding scales for billing? Set your rate at $125 hr for priority 3 and 4 fixes, and $150/hr for Priority 2 and Priority 1 fixes. This will also encourage them to truly prioritize with their wallets and give you some breathing room to fix stuff before it becomes a raging fire. I always present it like, don't fix things that don't add value to the bottom line. Priority 1 cases are minimum 1 hour. You could be booked on other work and have to be interrupted to do it, because like everyone, you have your development time scheduled.
Billing hourly and working up to a contract may build trust. Building this relationship further that you're always going to act in their best interest and spend their money at least as good as your own, if not better is a great way to win more business. If they want a support contract and you say "lets just see first how much it needs to be instead of picking a high number and it not being good for you", they will respect you that much more because you are not gouging them. This, again, is best with clients that you have a good relationship with, who will likely refer you other work. If on the other hand there is a lot of devils in the details, it may be best to stick to hourly, period so they can control their decisions on what they want to address, or not.
Wild Guess:
Chances are if your client wants a support contract (maybe even approached you), they are likely very happy with you, your process, the quality of your product, and the value you have generated for their business with their $35k investment in you. They want to make sure your attention is kept for them because it is of value to them.