In this guide 6 sections
A maintenance contract names the systems covered, sets response and resolution targets by severity, and says whether change requests are included or billed separately. It also settles who owns the code and the access, and how either side can leave. Specific wording ends disputes before work begins.
Systems and services covered
Name every system the contract covers. That means the application, each environment such as production, staging and the mobile apps, and every integration, not a vague phrase like the software. List exclusions too: hardware, outages at third-party platforms, hosting incidents outside the vendor’s control and any component that was not part of the original build.
Take a retailer’s inventory app. It exchanges data with a point-of-sale system and an accounting package, yet the contract says only inventory software, so the vendor may call a failed sync out of scope. The shop saw one product. The contract listed one. Write the point-of-sale connector, the accounting sync and the barcode scanner app into the schedule by name, and the argument never starts.
Support hours, severity levels and escalation
State when the vendor can be reached. The window may be office hours only or extended cover, and the contract should say what happens outside it when something genuinely urgent breaks. Severity levels, commonly critical, high, medium and low, need examples from your own business, such as checkout down for everyone versus a misaligned button on one report.
Escalation needs a named path. It says who is contacted, and by what time, when the agreed response is missed, because otherwise a missed deadline goes unnoticed until the business happens to check. Ask to see a sample report.
Maintenance, change requests and third-party costs
Maintenance and new features are different spend. Maintenance keeps the existing system stable, patched and working, while a change request such as a new report, a new field or a new workflow is fresh scope. The contract should say whether requests sit inside the retainer, are billed separately, or are capped at a number of hours each month before extra charges apply.
Third parties add cost too. Say who pays when a fix needs action from a hosting provider, a payment gateway or an SMS service, because chasing suppliers takes vendor time. Hours caps deserve a second look. A cap of a few hours a month sounds generous until one failed deployment uses them all by the second week, leaving routine patching unfunded.
Access, ownership, confidentiality and exit terms
Ownership decides who controls the exit. State that source code, credentials and infrastructure accounts stay under the business’s control, or are handed over in full on request, never trapped in vendor-administered accounts. Ask for a handover pack every quarter. It should hold the current repository link, the list of environments and the password-manager entries, so a replacement vendor could start on Monday.
Confidentiality of your data belongs here too. So do exit terms: a notice period, a defined handover process, and the documentation and knowledge transfer the vendor owes if the relationship ends. None of this replaces legal review. A lawyer who knows services contracts should check severity definitions, liability limits and termination clauses against the specific risks of your business before anyone signs.
Reporting and regular review
Contracts drift without review. Build in a reporting rhythm. A monthly or quarterly summary lists tickets resolved, patches applied and risks pending, and a service review lets both sides adjust scope, severity definitions or support hours.
Use that review as a test. Ask whether the systems named in scope are the systems in use, and whether response times that felt adequate at signing fit how critical the software has become.
Maintenance proposal comparison checklist
A side-by-side checklist for comparing vendor proposals on covered systems, severity definitions, response and resolution targets, change-request handling, access and ownership terms, and exit provisions. Gaps show up before signing, not after.
Open a blank worksheet to printQuestions owners ask
Does a response SLA fix the time to resolve an issue?
No. A response time promises acknowledgement and a first action by a deadline, and says nothing about how long the fix will take. Resolution or restoration time is a separate, usually longer target, and the contract should state it next to the response time for every severity level.
Are feature requests included?
Only if the contract says so. Most contracts cover bug fixes, patching and monitoring and treat new features as change requests that are billed on top or capped in hours each month. Ask before you assume.
What should happen if the vendor misses a response time?
The contract should name a consequence. That can be an escalation to a senior contact, a service credit against the next invoice, or a right to end the agreement after repeated misses.
Who should hold the hosting and domain accounts?
The business should hold them. Registering the domain, the cloud account and the code repository in your name lets a new vendor take over in days instead of begging the old one for access.