Start with four scope states
Classify every responsibility as exactly one of:
- Included: covered by the recurring fee under named limits.
- Excluded: not supplied under the retainer.
- Metered: available under a separate unit, rate, allowance, or approval.
- Unclear: the proposal does not support a reliable classification.
Do not turn unclear into included because the heading says “full support” or
“ongoing maintenance.” Ambiguity is a buying fact. Resolve it in writing before
using the price in a comparison.
Define the system being maintained
List the production application, environments, databases, storage, identity provider, background jobs, integrations, domains, certificates, monitoring, deployment tooling, and third-party services in scope.
A provider can reasonably maintain the application runtime while excluding the customer's identity tenant, an external accounting integration, usage charges, or a data-export job. The buyer needs those boundaries before deciding whether the arrangement covers the complete operating system.
Require a versioned service inventory in the monthly evidence. If the system changes, the parties can see whether the scope changed too.
Separate five different promises
1. Monitoring and incident intake
Name the signals observed, hours covered, alert destination, intake channels, and person who acknowledges an incident. “24/7 hosting” does not mean a person will investigate an application failure at 2 a.m.
Ask what starts the response clock: an automated alert, a buyer ticket, or provider confirmation. Record which incidents fall outside the channel or service window.
2. Initial response
Define response separately from resolution. A response might mean that someone acknowledged and began diagnosis. It does not necessarily mean the defect is fixed.
King County's public software maintenance agreement is useful evidence of structure: it defines severity categories and separates response and resolution measurements. Its exact clocks and consequences belong to that procurement; they are not a universal benchmark.
3. Diagnosis, workaround, and defect correction
These can be three separate obligations. State whether diagnosis time is included, whether the provider must propose a workaround, and how a defect is distinguished from an enhancement or changed requirement.
Require a decision record when work is reclassified. Otherwise a buyer cannot tell whether a recurring fee reserved corrective work or only intake and estimation.
4. Routine operation
Classify dependency updates, security findings, backups, restore tests, certificate renewal, domain renewal, usage review, database operation, routine releases, and third-party account administration independently.
The public UK supplier maintenance schedule shows why this matters: one maintenance service can bundle updates, hosting, technical support, support hours, and defect correction. Another proposal may bundle a different set under the same label.
5. Change work
State whether the monthly fee reserves any change capacity. If it does, define the unit—hours, points, requests, or another measure—and what happens to unused or excess capacity.
Reserved capacity is not automatically unlimited work. A provider can reserve ten hours while a requested feature requires thirty. The schedule should show the estimate, buyer approval, consumed capacity, remaining balance, and separate charge before work begins.
Make every promise measurable
For each included or metered row, name:
- the service window or trigger;
- the metric or clock;
- the capacity, limit, or unit;
- the provider owner;
- any buyer duty needed for performance; and
- the evidence delivered afterward.
The U.S. General Services Administration's performance guidance describes measurable standards in terms such as quality, timeliness, and quantity plus a method for assessing performance. A small-business schedule can use the same structural idea without copying a government procurement process.
“Monitor the app” becomes inspectable when it names the signals, coverage window, alert owner, acknowledgement target, exclusions, and monthly alert and response record.
Require a monthly evidence report
A compact report should show:
- the service inventory and production revision;
- alerts and incidents, including received, acknowledged, and resolved times;
- severity changes and reasons;
- defects opened, corrected, deferred, and released;
- dependency and security findings plus decisions;
- backup failures and the latest restore-test result;
- releases, approvals, outcomes, and rollbacks;
- change requests, estimates, approved work, and capacity consumed;
- hosting or usage charges with the supporting export; and
- exceptions, risks, and open handoff items.
A month with no incidents still produces useful evidence: system inventory, monitoring health, backup status, release identity, capacity balance, and open risks should not disappear.
Garden's first-party fleet and audit pages show two evidence shapes a buyer can ask a provider to expose: owner and app stage, live and failed releases, plus attributed actor, action, target, and time fields. They are not a maintenance-retainer benchmark. Garden explicitly does not promise an SLA, configurable audit retention, legal hold, or application-specific monitoring and recovery on those pages, so each item still needs a written scope state, owner, limit, and delivery schedule.
Write buyer duties beside provider duties
The buyer may need to maintain contacts, approve releases, provide access, confirm business severity, pay buyer-owned cloud accounts, supply acceptance criteria, or respond within an agreed window.
Hiding buyer dependencies makes a service promise look stronger than it is. It also makes later performance disputes harder to diagnose. Put the needed input and owner on the same row as the provider promise.
Make termination part of maintenance
The schedule should name the notice and transition window, transition capacity, successor access, open-ticket export, source and artifact delivery, data export, configuration, account control, operating documentation, backup and restore procedure, release history, and unresolved risks.
Source code alone is not the handoff. The successor needs enough control and evidence to identify the live system, operate it, restore it, and understand unfinished work.
Require a receipt that lists what was delivered and who verified access. If transition work is metered or excluded, say so before the relationship ends.
Use the fourteen-row schedule
The evidence packet contains a buyer-fillable schedule covering:
- covered systems;
- monitoring;
- incident intake;
- severity classification;
- initial response;
- diagnosis and workaround;
- defect correction;
- security and dependencies;
- backup and restore;
- hosting and usage;
- routine releases;
- change requests;
- monthly reporting; and
- termination and handoff.
Apply one simple ambiguity test: if a row lacks its scope state, owner,
measurable trigger or limit where relevant, or evidence source, keep it marked
unclear.
Questions to send with a proposal
- Which named systems and environments does the fee cover?
- What starts each response or resolution clock?
- Which work is defect correction and which is a paid change?
- How much capacity is reserved, and what happens when it is unused or exceeded?
- Which security, dependency, backup, restore, and release tasks are included?
- Which third-party and usage costs pass through to the buyer?
- What must the buyer provide, approve, or operate?
- What report and raw evidence arrive every month?
- What happens to open incidents and unused capacity at termination?
- What accounts, data, artifacts, documentation, and access transfer to a successor?
Frequently asked questions
Should every maintenance retainer include feature work?
No. It can reserve operation and incident capacity while treating features as separate change work. The important point is to make that boundary and its price mechanism explicit.
Is a fast response time enough?
No. Response, diagnosis, workaround, correction, release, and resolution may be different events. Define and report the ones the buyer needs.
Does this worksheet create an SLA?
No. It helps a buyer expose scope and evidence questions. Qualified commercial, security, privacy, and legal advisers must review the actual agreement.