As part of your customer agreement, you'll want to define severity levels for support tickets. Some examples would be critical (systems down, no workaround available), high (product operation is impaired, no workaround available), medium (product operation impaired, workaround available), low (non-critical, request for enhancement or question about product).
Based on the severity define target response time (when your team will respond to the customer), target for escalation to engineering (when your support team will pull in engineering resources) and target resolution time (when your engineering team will have a fix).
You could have something like:
Severity | Target response time | Target development escalation | Target resolution
critical | 2 hours | 8 business hours | action plan in 1 day
high | 4 hours | 2 business days | 7 business days
medium | 8 hours | 7 business days | 15 business days
Then you'll want to include some words that these are targets and not a guarantee.
There are lots of factors in setting up this type of agreement. Are you providing 24*7 support or business hours? Is the customer in the same time zone with you if you're providing only business hours support? Do you have the infrastructure and staffing in place to provide 24*7 if needed? Is the deal big enough to warrant the extra work it entails?
If you're a VAR for this software rather than developing it, you'll want to consider what SLA the actual software provider is giving you. If you have to escalate an issue to them, you don't want the customer expecting an answer faster than you can get it from the provider.
I've seen support pricing calculated on the price of the software itself in the case of enterprise software.
Here's an example SLA from Microsoft http://technet.microsoft.com/en-us/library/cc543293.aspx
The good news is that once you've sorted this out for the first customer, you'll have it in your hip pocket when needed for subsequent sales.