Perhaps the most important aspect of the service contract is that it clearly defines who is expected to do what, and at what cost. Will you be responsible with providing the service vendor with onsite office support? Is the support vendor required to address a bug, even if it can't reproduce it? Does escalating a problem also escalate the cost? The contract should explicitly answer these types of questions, Anderman advises.
Both sides should also be very clear on fees, when they are levied, and how much they will cost. Neither side wants surprises when it comes to money, so it is very important to define hardware and software resources, what actions will result in what charges, and how the payment process should work. "You want to set up a situation where it never comes to litigation," says Anderman. To do that, "you cover all your bases so that terms and procedures are clearly defined."
The contract should spell out exactly what happens when something goes wrong. If there's a bug, you want the contract to define the bug: What priority is it? Critical? Somewhat important? Easily worked around? Based on those priority levels, you need certain vendor resources to come into play.
If, for example, you have a major system shutdown, you'll want a rapid response. Your support contract should spell out the nature of that response -- a callback within one hour, the bug fix within a certain negotiated time period, and so on -- and make sure to specify whether this happens during business hours only or 24/7. "You need to establish hard deadlines for response time and correction time," Anderman notes. "If you can't get hard times for that, then you want 24/7 coverage with X amount of resources working on it until it's corrected."
Anderman recommends putting a requirement in the contract for a primary support contact or a project manager whose job is to coordinate everything and be the sole liaison with the support vendor. That way, you'll have a consistent relationship with somebody who knows what you need, you'll know who to contact, and your contact will be fully aware of any bugs that have been reported in the past.
This sort of one-to-one relationship is invaluable when it comes to getting problems fixed -- and it's something you're more likely to find with a third-party support vendor than with a big software vendor that also sells support for its products.
You should also think about the potential for escalating bugs up the support vendor's chain of command and how that escalation should work. Anderman notes that a clearly defined escalation clause can be a helpful provision in case a high-priority bug needs to be moved up the executive chain, perhaps even as high as the support vendor's CTO, in order to guarantee that critical bugs get the appropriate response.
How should you handle negotiations?
The basic conundrum of software support is this: You can spend a lot of money and get full support, or you can spend much less money for lesser support. But with good negotiations, you can get what you need out of a support contract, leave out the parts that don't apply to you, and save a nice chunk of change.
Before entering negotiations, Anderman asks two basic questions about the support vendor: "How bad does it want my client's business?" and "How big is the company?" These questions help him ascertain a support vendor's flexibility in negotiating a support contract. Big support vendors tend to be rigid, often preferring to offer set packages or otherwise dictating the terms of the contract to the customer. Bigger support vendors also have many more layers of management than smaller ones, so it's less likely the salesperson you're dealing with will have the authority to adapt their negotiating terms.