A software maintenance agreement should define covered systems, support hours, severity, response expectations, responsibilities and exclusions. Separate incident response from feature development and clarify what restoring service means. A promise of support is difficult to use when neither party knows who must act or which work is included.
Let’s plan your software support scope.
Bring your workflow, constraints and open questions. We’ll help you define the scope and work through the next decision.
Establish the supported baseline
List applications, environments, integrations and versions covered by the arrangement. Identify who controls infrastructure, credentials and third-party services. The support team needs appropriate access and current documentation before it can be accountable for recovery work.
Record existing issues at the start. Otherwise a known defect can be mistaken for a new incident, or an unsupported component can be assumed to be covered. Agree how the baseline changes when a new feature or integration is released.
Write a support responsibility worksheet
| Topic | Agreement to make | Ambiguity to avoid |
|---|---|---|
| Coverage | Days, hours, time zone and contact channel | Around-the-clock expectations under business-hours support |
| Severity | Impact criteria and who assigns priority | Every issue being labelled critical |
| Response | Time to acknowledge and begin assessment | Treating acknowledgement as completed repair |
| Restoration | Workaround, recovery and update expectations | Promising a fix time without dependencies understood |
| Included work | Incidents, updates and agreed maintenance tasks | Assuming enhancements are automatically included |
| External dependencies | Provider escalation and customer responsibilities | Holding nobody accountable for contacting the vendor |
| Changes | Approval, testing and deployment process | Unreviewed production changes during an incident |
| Reporting | Incident history, trends and unresolved risks | Monthly hours with no explanation of outcomes |
These are planning questions, not contract wording or legal advice. Review the actual agreement with a qualified adviser where needed.
Define severity through business impact
A production outage preventing all users from completing a critical workflow differs from a cosmetic issue affecting one optional screen. Include workarounds, affected population and time sensitivity in the classification.
Consider a hypothetical invoice export that fails shortly before a business deadline. The application may otherwise look healthy, yet the impact can justify urgent handling. The severity model should account for that workflow rather than relying only on server availability.
Include maintenance that prevents predictable failures
Assign responsibility for dependency updates, certificates, backups, access review and provider changes. Define how those tasks are scheduled and tested. They are separate from waiting for users to report incidents.
Agree how recurring failures trigger investigation and follow-up work. If each incident is closed after a restart without understanding the cause, response speed can appear good while the product remains unreliable. Track repeat incidents and outstanding corrective actions.
Maintenance questions
Is response time the same as resolution time?
No. Define each term and the circumstances affecting restoration. External dependencies and unknown causes can make a universal repair deadline unrealistic.
Does maintenance include new features?
Only where the agreement explicitly includes that capacity. Clarify the boundary between defect correction, compatibility work and enhancement requests.
Use the handover checklist to establish support readiness. Bring the system inventory and operating deadlines to a software support discussion.