What should a software support contract include?
A software support contract should state the systems covered, the hours of cover, how to raise a problem, response times by severity, what counts as chargeable change, who owns the code and accounts, how either side can end it and how the system is handed back.
What is covered, and when
The systems covered. Name each application, database and environment, including any test copy and the connections to other systems. Say what is outside the contract as well, such as the hosting platform, third-party products and staff PCs.
The work included. Responding to faults is only part of support. Check whether the contract also covers security updates, keeping the platform on supported versions, monitoring and testing that backups restore. A contract that covers faults alone leaves the upkeep undone.
Hours of cover. State the working hours, the time zone and what happens on bank holidays. If the system is used out of hours, cover outside working hours needs to be written in.
Raising problems and response times
How to raise a problem. One agreed route, such as an email address or a ticket system, with a telephone number for urgent faults. The contract should say who on your side may raise a problem and what the supplier needs to be told.
Severity levels. Define each level by its effect on the business: the system is unusable, a function has failed but there is a way round it, or the fault is minor. Agree who decides the level when the two sides disagree.
Response times by severity. A response time is how soon someone qualified starts work, which is different from how soon the fault is fixed.
Changes and charges
What counts as chargeable change. A fault is the system failing to do what it did before, or what was agreed. A change is something new. The line between them causes more disputes than anything else in a support contract, so it needs a definition and a named person on each side to settle doubtful cases.
How changes are priced. Either each change is quoted before work starts, or an agreed amount of change work is included each month. If time is included, check whether unused time carries over.
The fee and how it can rise. State what the monthly fee covers, when it can be reviewed and how much notice a price change needs. Costs passed on from others, such as hosting and licences, should be shown separately.
Ownership, ending and handing back
Who owns the code and accounts. The contract should say who owns the code, including code written during the contract, and that hosting, domains and repositories are held in your organisation’s name. Ownership of code is a legal question, so take advice on the wording.
How either side ends it. Look for the minimum term, the notice period and whether both sides have the same rights.
How the system is handed back. On ending, the supplier should deliver the current source code, the documentation and every credential, and give reasonable help to whoever takes over, at a stated rate. Ask a prospective supplier to describe how it would hand your system back. The answer says a good deal about how it will look after it.
Nothing on this page is legal advice. For how we set these terms ourselves, see our software maintenance page and how we work. If you are leaving a supplier, the supplier transition plan sets out the handover as a sequence.
Related questions
What is the difference between a response time and a fix time?
A response time is how soon someone qualified starts working on the problem. A fix time is how soon it is resolved. Most suppliers of bespoke software commit to response times only, because how long a fix takes depends on a cause nobody knows yet.
Should the contract include a service level agreement?
Yes, if the system matters to the business. A service level agreement is the part of the contract that sets out hours of cover, response times by severity and escalation. Make sure each severity is defined by its effect on the business, so that both sides class a problem the same way.
Who should own code written during the support contract?
Agree it in writing. The safest position for a client is that fixes and changes made to its system are assigned to it, on the same terms as the original code. Without an assignment in the contract, copyright may stay with the supplier, so take legal advice on the wording.
How long should the notice period be?
Long enough to appoint another supplier and hand the system over in an orderly way. A long minimum term with no way out suits the supplier more than the client. Check that the handback duties apply during the notice period.
Want the answer for your system?
Tell us what the software does and what you are trying to decide. We will reply with a straight answer and what we would need to know to be more precise.