Specify exactly what maintenance includes
List every part of the service: application, database, server, domain, certificates, backups, external APIs and customer support. Name an owner and responsibility boundary for each. A supplier who fixes code may not manage the VPS or payments to a third party. Distinguish defect repair, security updates, small changes, feature development and on-call cover in the proposal. Each consumes different capacity and cost. If nobody is assigned to watch certificate expiry or a full disk, the problem may first become visible during an outage. Describe maintenance for the particular service rather than relying on a vague promise of technical support.
Define what counts as a defect and what is a new feature. For example, a contact form that stops storing messages is an incident; adding another CRM field changes scope. Disputed cases need a decision process, not automatic billing without explanation. State what access is needed for repair and who provides it. If the customer owns a dependency, the supplier cannot guarantee its recovery. The agreement must distinguish responsibility for response from responsibility for the final outcome. Ask a lawyer to review actual contractual language; an operational description does not replace legal advice.
Derive incident priority from user impact
Define severity with concrete examples. Inability to process a payment or data loss may be critical; a cosmetic defect outside the main journey may rank lower. Priority should not depend only on who reports most loudly. Consider how many users are affected, financial or security impact and whether a workaround exists. For some services, a wrong result is worse than complete unavailability because people may not notice it immediately. Write examples for each level and say who can change priority when new evidence arrives. Include the case where a third-party service is down but your own application remains technically healthy.
Use one reporting channel and a case number. On receipt record time, service, symptoms, impact and available evidence without unnecessary sensitive data. Acknowledgement is not a fix. Separate time to first response, time to start work, time to restore service and time to eliminate the underlying cause. With an external dependency the team may respond quickly while another organization controls recovery. Explain these differences before an incident. Make priority changes traceable so the history of decisions remains clear through a long outage. Give users a way to provide new impact information after initial classification.
Set response times from real capacity
State support hours, holidays, time zone and how deadlines are calculated. A two-hour response during working hours differs substantially from nighttime on-call duty. A stricter SLA requires available people, monitoring, access and substitutes; without these it is only a paper promise. Consider incident volume, system complexity and on-call cost. Say what happens when a report arrives outside the supported window. Do not confuse a guaranteed incident acknowledgement with a guaranteed root-cause fix. For a complex fault, regular communication and a safe workaround may matter more than a superficially short repair target.
Google SRE distinguishes a service quality indicator from its target; these concepts can establish internal expectations before a contractual SLA. Measure, for example, the proportion of successful user actions and time during which the service is genuinely usable. Agree on the measurement period and handling of planned maintenance. Do not adopt an availability percentage without calculating it and accounting for critical external services. If historical data are missing, begin with a temporary target and revisit it after observing the service. Penalties or compensation belong in a specific legal agreement, not an unfunded technical promise.
Maintain dependencies and vulnerabilities systematically
An application changes even if no feature is added. New versions of the operating system, libraries, database and external APIs may require work. Assign ownership of the dependency inventory, support-status checks and a regular update plan. Test each change against main user journeys. Postponing an update can be a reasoned decision when risk and compensating controls are documented; silently ignoring it is not. For critical components prepare a route to rapid repair or reduced exposure. A provider's API change can break the service as surely as a defect in your code. Review this risk in the maintenance report.
Prioritize security findings by actual exposure, impact and evidence of exploitation. The CISA Known Exploited Vulnerabilities catalogue records vulnerabilities known to be exploited; it is one input, not a complete answer for every system. Set assessment and remediation times according to service criticality. If a patch cannot safely ship at once, consider temporary protection and track it. After repair verify the version and actual application behavior. Clarify whether ordinary security maintenance is included in a retainer and who approves a larger intervention. Do not confuse a scanner finding with proof that a particular installation is exposed.
Give backup and restoration their own commitment
An application SLA is incomplete without a data plan. State who makes backups, where they live, how long they are kept and who may restore them. Define acceptable data loss and time to return. The operating team should regularly prove that a backup yields a usable application with its required files, not merely that an archive was created. Check restoration especially after database migrations. A copy on the same server may not protect against its loss. Keep recovery access secure without making one person indispensable. Include the outcome of the last restoration drill in the service report.
During an incident distinguish quick resumption from full data repair. A temporary version may let people work while missing records still need checking. Document who decides to restore, how change history is preserved and who tells users about possible data loss. A rehearsal produces a real number for contractual expectations. If the test takes longer, repair the procedure or adjust the promise; pretending the target was met is dangerous. For a small system, a simple recurring recovery test may be more useful than complex infrastructure without rehearsal. Keep evidence of what data were restored.
Make escalation and reporting support decisions
For each incident level provide a responsible contact and substitute. State when the product owner, security specialist or infrastructure provider joins. AWS Well-Architected recommends a procedure for each alert and escalation paths based on impact. During a significant outage set an update frequency and a place where the customer can see status. After recovery explain what happened, its effect and what will change. Do not present technical detail without explaining user impact. Communication is part of support rather than an optional courtesy. Give the customer one route for an urgent issue even when several suppliers participate.
A regular report can show availability of main journeys, incidents by priority, response and recovery times, unresolved problems, backups, security updates and capacity use. Add a proposed decision: what to repair, postpone or accept as residual risk. A green table without checking user outcomes says little. When the same fault returns, maintenance cannot consist only of repeated restarts. Connect technical condition with cost and business impact. A concise report that somebody reads is better than a large document with no owner. Agree on who reviews it and when the resulting action will be checked.
Keep planned development distinct from on-call response
Support needs capacity for unexpected events; planned development needs a brief, priority and approval. When both compete for the same time without rules, a critical repair displaces improvement and rushed catch-up creates another defect. Define how small changes are priced, who orders them and how they are tested. Give larger work its own scope. Maintenance can include reducing technical debt when it demonstrably lowers operating risk; describe that benefit concretely. Customers should see why capacity went to security rather than a new feature. Reserve a route for urgent fixes that does not bypass all review.
For each release check data compatibility, tests, backup and return procedure. A maintenance contract alone does not ensure every change is safe. Name who approves production deployment and when it occurs. The urgent-fix path should be quick while still recording the action and a later check. Track external service changes in the same way as your own releases. If incidents rise after routine deployments, revisit the release process rather than only shortening the support response time. Make planned maintenance visible to affected users ahead of its window.
Test a proposal against a concrete scenario
Ask a supplier to describe its response to a broken contact form, unavailable database, incorrect invoice and suspected data leak. Who receives the report, when do they log in, how do they establish impact and when do they inform the customer? What can they repair themselves and what needs approval? How can they prove restoration from backup? Ask about real on-call cover and substitutes. A price without these activities cannot be compared fairly. Confirm that the customer owns accounts, domain, source code and documentation. Ask to see a sample incident report and a recent recovery-test result if available.
Compare the total cost and risk: retainer, extra work, licences, monitoring, backups, nighttime intervention and transition to another supplier. EXCOIN can offer maintenance for a specific system, but response times and repair scope cannot be promised responsibly without an inventory. The first step is a review of the service, responsibilities and recent incidents. Only then can support and price be defined sensibly. A good agreement lets customers know what happens when something breaks and choose operating changes from measured evidence. Keep exclusions as visible as included services.
A checklist before signing
Confirm the service list, owners, support window, incident priorities, response and communication times, maintenance versus development boundary, backups, restoration and escalation. Check access, measurement and report format. For every promised number ask how it is calculated and what evidence shows it is technically achievable. State the procedure for an external provider outage and for ending the agreement. Legal effects, remedies and exclusions belong to the actual contract and should be reviewed by a lawyer. A technical checklist helps ask the right questions; it does not replace legal review. Try one realistic incident scenario with the named contacts.
After the first month compare actual incident count, response time, communication quality and recovery tests with assumptions. Adjust priority definitions or capacity from evidence. If support repeatedly fights the same defect, reserve work on its root cause. Predictable maintenance is shared work: the product owner defines the importance of services, while the supplier shows the technical state and risks. A useful SLA creates a clear response and a way to verify it, not an illusion that software never fails. Record the first review date in the agreement rather than leaving it to chance.