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
answered 2009-06-12T23:54:10.350