A maintenance agreement should explain what happens when software fails, who acts, and how progress is communicated. A monthly fee and a promise of "support included" leave too much ambiguity. The most useful agreement starts with the business processes that depend on the application and the hours during which disruption matters.
Separate incident response from planned maintenance and feature development. Repairing a broken sign-in flow, updating a dependency and adding a new reporting module require different planning. If all three consume the same undefined support allowance, urgent recovery can compete with routine requests without a clear priority.
Define impact before severity labels
Use examples rather than labels alone. For a hypothetical ordering platform, an outage preventing every order might be critical. A report exporting the wrong date range may be serious but still allow staff to process orders. A cosmetic alignment issue usually requires a scheduled fix rather than an emergency call.
Document who can declare an incident and how to reach support. State whether coverage includes weekends, public holidays and overnight operations. A response target measured only during business hours should not be presented as continuous coverage.
Distinguish response, mitigation and resolution
A response means a responsible person has acknowledged and assessed the issue. Mitigation restores a usable business path, possibly through a workaround. Resolution removes the underlying fault. These are different milestones, and a short acknowledgement target does not guarantee a short repair time.
Google's incident-response guidance explains the value of defined coordination and communication roles. In a smaller company, one person may hold several roles, but the agreement should still establish who directs the response and who updates the business.
Worked example: a failed warehouse integration
Suppose an inventory connector stops importing completed picks at 09:00. The warehouse application still operates, but the sales team's stock view becomes stale. The agreed procedure classifies this as a material degradation, disables automated stock promises and shows a freshness warning.
Support acknowledges the incident within its contracted coverage window, identifies the last processed event and provides a manual reconciliation route. Recovery includes replaying missed events without duplicating stock movements. The incident closes only after both the connector and the resulting inventory totals have been checked.
This example reveals dependencies that a generic uptime percentage misses. The dashboard can be available while its data is unusable. A service indicator should therefore describe the relevant user experience, such as successful synchronization within a defined delay.
Set measurable reliability objectives
Choose a small number of indicators: successful order submissions, synchronization delay or usable sign-in requests. Define the measurement location, reporting period and exclusions. Google's SLO workbook distinguishes reliability indicators and objectives, making it a useful basis for discussing targets without confusing them with contractual remedies.
Higher coverage and tighter objectives require staffing, monitoring and recovery investment. Price those capabilities explicitly. Do not promise a repair deadline for every possible defect when a third-party provider or missing client access may control recovery.
Include planned work and exit terms
Agree on patch review frequency, maintenance windows, backup checks and ownership of external accounts. Define the approval process for risky changes and the rollback evidence required. Keep a record of recurring incidents so repeated workarounds lead to a permanent improvement decision.
Finally, state what documentation, credentials and outstanding issues will be supplied if the agreement ends. An effective maintenance service leaves the business informed and able to operate, including when its provider changes.
Primary references
Related reading
Discuss coverage, monitoring and recovery requirements with our IT consulting service.