A website technical support contract: what to put inside the document

How support differs from warranty fixes

Warranty fixes belong to the period after launch and cover errors that appeared because of the development. These are usually bugs that prevent the correct operation of what has already been built and approved.

Technical support works more broadly. It includes the regular tasks that appear in any living system:

• updates to the CMS, modules and dependencies
• availability monitoring and responding to outages
• recovery after errors, including from backups
• change requests and changes requested by the business
• work with infrastructure and integrations, if that's within the support scope

Because of this, it's important not to mix warranty and support into one vague block. If you don't separate these modes, you'll get a dispute in the very first week after launch.

When a contract is especially important for a business

A contract is always needed, but there are situations where without it the business loses money and time:

• the site brings in leads and sales — any downtime immediately hits revenue and reputation
• there are integrations: payments, CRM, telephony, online booking, delivery, analytics — any failure needs a clear process and responsible people
• different people work on the site: marketing, a content team, advertising contractors — without a procedure they easily break settings and argue about who should fix them
• there is personal data and access: forms, a user account, user databases — you need to describe security and the incident procedure in advance
• the site changes regularly: promos, new pages, new services — support without rules quickly turns into chaos

What counts as the site and the prod, stage, dev environments

In the contract the word 'site' often sounds too broad, so the contractor and the client understand differently what exactly needs to be supported. Describe the site as a set of components: the public part and the admin panel, the database, the server side and integrations. This often also includes lead forms, the user account, the catalog, the cart and payment, and analytics and notification services. If there are subdomains, multilingual content, a mobile version or a PWA, list those too.

Next, fix the environments. Prod is the working environment where the site is available to users. Stage is the environment for the final check before release. Dev is the development environment. It's important to state directly which environments are covered by support and what exactly the contractor does in each of them.

Another frequent source of conflict is infrastructure. If the server, domain, SSL certificate, CDN or mail sit with third parties, note this. Specify who is responsible for payment, renewal and access, and who makes settings if hosting or security parameters need to change.

What an incident, bug, change request and update are

An incident is a failure that affects the site or part of it: the site doesn't open, forms aren't sent, payment doesn't go through, the user account breaks, an integration fails. An incident requires a response under the SLA because the business loses leads, money or data.

A bug is an error in existing logic that appears during correct use. It's important to fix what counts as a bug relative to the agreed behavior. If that behavior wasn't in the spec and acceptance, a dispute is almost inevitable.

A change request is a change or extension of functionality: a new filter in the catalog, a new report, a new notification type, a new role in the admin panel. A change request almost always requires estimation, agreeing on deadlines and separate acceptance.

An update is planned work that keeps the site current and secure. An update preserves the system's behavior, while a change request alters it. If third-party services are used, add a rule: a failure at a third-party provider is an incident for the business, but not always the contractor's responsibility.

How priorities and severity levels are fixed

Without prioritization rules, support turns into a queue of urgent tasks. Start with a principle: priority depends on the impact on money, leads and key scenarios. The second factor is the number of affected users. The third is whether a workaround exists.

It's convenient to fix several levels: critical (the site is unavailable or a key function doesn't work), high (a scenario is badly broken but the site stays available), medium (there's a defect but the business operates with limitations), low (the issue affects convenience or appearance but doesn't block the process).

Next, the contract must say who assigns the priority and how it's changed. Be sure to specify how you count time: by working hours or by the calendar. If the business needs a 24/7 mode, it can't be implied — it has to be fixed separately.

What site maintenance usually includes

Maintenance is a set of regular and reactive work. Its goal is simple: the site must run reliably, stay secure and evolve without chaos. It usually includes:

• availability monitoring and quick analysis of failures
• fixing bugs and restoring the operation of forms, pages and integrations
• CMS and module updates within agreed rules
• security monitoring, backups and recovery after a failure
• minor edits: texts, banners, contact details, blocks on a page, analytics metrics
• monitoring the links with CRM, payment, delivery and mail services

And finally, reporting. Even simple support should leave a trail: the contractor provides a list of completed tasks and the status of open requests for the period.

What's not included and how additional tasks are handled

Next to the list of work included in maintenance, you need a separate list of what's not included. Usually that's everything that changes the product or business logic: new pages and sections, new functionality and integrations, a design overhaul, migration to another stack, filling the site with content, working with ad accounts.

So that additional tasks don't turn into conflict, write a simple three-step process. The client submits a task in the agreed channel with a goal, a link and an acceptance criterion. The contractor classifies the request — a bug or a change request — and gives an estimate of time and cost. The client confirms, after which the task enters the work plan and gets a priority.

Add a rule about urgent unplanned work: an urgent task proceeds only after a separate approval and may be billed at a different rate or in a different time window.

The client's duties: access, content, approvals

Support breaks not because of development, but because of a lack of access, responsible people and approval rules. Assign a single product owner on the client side: they accept work, agree priorities and give the final go-ahead for releases.

Spell out access. The client provides access to the admin panel, hosting or server, domain, mail, analytics, the repository and third-party services, and is responsible for keeping credentials current and for the order in which access is granted. Clarify who prepares content and who is responsible for its correctness and the rights to materials.

Write the approval rules: how much time the client gives to respond on mockups, edits and releases, and what happens if there's no response. And separately — the client notifies about any change made by a third party, otherwise support turns into searching for causes in the dark.

Response time, resolution time, recovery time

Response time is how long passes from the request to the first reply and taking the task into work. It's confirmation that the incident was seen and the analysis has begun.

Resolution time is how long it takes to eliminate the cause and close the incident. It may include development, testing and deployment, and depends on the type of problem and the availability of environments.

Recovery time is how long it takes to restore a critical function even if the root of the problem still remains: you enabled a temporary workaround, rolled back a release or disabled a conflicting module. It's important to describe how you count time and what counts as a pause, for example waiting for access or for the client's reply.

Incident priorities and the planned-work window

A priority matrix is needed so the team doesn't argue about importance and the business understands why some tasks go first. Tie criteria, not emotions, to each level:

• critical: the site is unavailable, payment or lead submission doesn't work, authorization is broken, there's a leak or a suspicion of a breach
• high: the error affects a noticeable share of users, a key scenario breaks but there's a workaround
• medium: there's an error but it doesn't block the scenario, one block works incorrectly
• low: minor edits, cosmetics, text clarifications, improvements with no impact on operation

Fix the planned-work window — the time when you roll out updates, do maintenance and check backups, so releases don't happen at random moments. And add an escalation rule: who raises the priority and how, and who makes the decision.

How to measure the SLA and what counts as a breach

First, agree on the units of measurement. Fix the support working hours, the time zone and public holidays, and state whether the SLA applies outside working hours. Describe from which event the count starts and what counts as confirmation — for example the contractor's reply in a ticket with the task number.

Define the timer-stop rules in advance: when the client hasn't granted access, hasn't confirmed changes, hasn't provided reproduction data, or when an inaccessible external service breaks the site. Describe what exactly counts as an SLA breach: exceeding the response time or the recovery time for critical incidents, and only for a correctly submitted request.

Add a control method: all requests go through a single task list with required fields — subject, description, reproduction steps, screenshots or logs, priority, environment, contacts. That way you can build SLA reports and see the bottlenecks.

The procedure for server, admin and repository access

Describe the access format. Individual accounts are better than shared ones: they provide control and an action log. The client grants access to specific people or roles, and access is closed when someone leaves or the team changes.

Specify which access is needed to start support — usually hosting or the server, the admin panel, and the repository if support touches the code. If there's no repository, fix where the source code is stored. Add a rule about environments: ideally you use stage for checks and only then release to prod.

Define who has the right to deploy and how you record the fact of a release — for example a ticket entry with the date and a list of changes. This helps to investigate incidents and disputes.

Handling personal data and confidentiality

Define what you consider confidential: commercial documents, access credentials, logs, client data, user databases, financial information. State that the contractor uses them only to perform the work, without passing them to third parties and without publishing them.

If the site collects personal data through forms, a user account or payment, fix the basic rules: who is responsible for the content of forms and consent texts, who stores the data and where, and who has access. The fewer people see the data, the lower the risk.

Describe how you work with logs and exports: when they're needed, where they're stored and when they're deleted. Choose one secure channel for transferring secrets — for example a password manager — and specify who has the right to request such data.

Actions during a security incident and notifications

Describe what you consider a security incident: a breach of the admin panel, content substitution, a database leak, suspicious activity, unexpected new administrators, mass mailings from the site. Such definitions help to switch on the right mode of work without disputes.

Fix the order of actions: who receives the request, who launches the first measures — changing passwords, revoking tokens, blocking access, enabling maintenance mode, checking logs. The decision on public communications always stays the client's zone, but support can provide the technical facts.

Describe the notification deadlines and the escalation order: whom to call if the incident is critical and which contacts work outside working hours. A short report afterward is useful: what happened, when it started, what was done, which data could be affected and what will reduce the chance of recurrence.

Backup frequency and retention periods

Fix what exactly goes into the backup: the database, site files, user uploads, configurations and key settings. If the site uses third-party services, note that their data can't always be recovered from the site backup — then a separate export policy is needed.

Describe the frequency by category — database, files and media, configurations — not with the vague words 'we do it regularly' but with a concrete schedule. Describe the retention periods and tie them to business risk: for accounting and legal data the period is usually longer, for a promo site it can be shorter.

Fix the storage location: a single server next to prod often doesn't help in case of a disk failure or a breach. And add backup verification — a copy without a test restore often turns out to be an empty formality.

The recovery procedure and responsibility for downtime

Recovery always follows a scenario. Describe it in simple steps:

• who records the incident and through which channel
• who decides on recovery and rollback
• which recovery point you roll back to
• how you check operation after recovery
• who gives the go-ahead to return traffic and open the site

Write down the boundaries of responsibility for downtime: the site can go down because of hosting, the domain, external APIs, payments or the actions of the client's staff. Specify who bears the risk of data loss during an agreed rollback — if the business chooses a fast rollback to yesterday's copy, it accepts the loss of some new data.

What the instruction should contain and who updates it

The contract needs appendices, otherwise it stays a declaration. For backups and recovery it's useful to have a short instruction you can open at the moment of an outage. Fix the minimum in it:

• a list of systems and components that need to be backed up
• where the backups are and how to get there, who has access
• the step-by-step recovery procedure and how to bring the site up on stage for a check
• how to check the key scenarios: home page, forms, payment, user account, admin panel
• escalation contacts on the client's and the contractor's side

Define the document's owner: who updates the instruction after releases and infrastructure changes. A frequent mistake is that the instruction goes stale after two months and during an outage no one understands where everything is.

How to tell a bug from new functionality

A bug is a deviation from agreed behavior. It was in the spec, the prototype or the accepted version of the site, but works differently. For example: the form sends a lead but the email doesn't arrive; a button can't be tapped on mobile even though it should.

New functionality is a change of requirements. There was no such scenario before, and you want it to appear: add a new payment method, build a user account, connect a new CRM. In the contract it's convenient to fix the decision criteria:

• is there a description of the desired behavior in the project's source materials — the spec, prototypes, mockups, confirmed correspondence
• was this scenario in acceptance and did it work in production before the changes
• have external conditions changed — the provider changed an API, hosting updated versions, browsers changed requirements
• who initiated the change — if the business changes the rules, it's almost always a new task

The Change Request process: estimation, approval, prioritization

A Change Request is a controlled way to change the scope of work. It protects both sides: the business gets transparency on deadlines and price, the team gets a clear priority and acceptance criteria. The minimum composition of a request: a description and goal, links to pages and scenarios, the expected result, the business criticality, constraints and acceptance criteria.

Then fix the approval cycle: registering the request in a single channel, an initial estimate and a check of dependencies, an estimate of time and effort, choosing a payment model, agreeing the priority and a release plan.

Separately, fix the prioritization rule. Incidents and security usually go above development. Changes that affect money and leads get a high priority. Cosmetic edits are planned into regular releases.

Accepting changes, testing and release

Without clear acceptance, changes stall: the business says it's not ready, the team says it's already done. A simple scheme usually works: the team shows the result on a test environment, the client checks against the agreed criteria and gives a list of remarks in one place, the team fixes them and shows it again, and after acceptance the changes are rolled out to production in the agreed window.

In testing, split the responsibility zones. The team checks the technical part: layout, forms, integrations, basic scenarios. The client checks the business meaning: texts, prices, terms, legal wording and the correctness of content.

Write down what a release includes: deployment to the server, a basic operability check, updating dependencies and the instruction if the changes touched the admin panel. And state that urgent releases are possible but require separate approval of the window and the priority.

Payment models: subscription, hour package, time and materials

Subscription. You pay a fixed amount per period and get an agreed service level and scope of work. This model suits when predictability matters and there are regular tasks. The contract needs to describe clearly what the subscription includes.

Hour package. You buy a certain number of support hours per month or quarter, and the team deducts them as work is done. It's important to write down whether unused hours carry over, how the minimum billing unit is counted and how effort is confirmed.

Time and materials. You pay for actual effort at an agreed rate. This model suits tasks with an uncertain scope: complex change requests, integrations, migrations. Businesses often combine models: a subscription or hour package covers basic support and the SLA, while large changes go as separate estimates.

Licenses, hosting, third-party services: who pays

Site support is almost always paid separately from infrastructure and service costs. List the mandatory costs in the contract: domain and DNS, hosting or server, SSL certificates, mail services, backups, CDN, paid modules, analytics and mailing services, payment gateways. For each item, specify who owns the account and who pays.

It's safer when the key accounts are registered to the client, with the contractor working through granted access. Write down the procedure for paying and confirming costs, the limits, and what counts as an additional cost requiring separate budget approval.

Fix what happens if infrastructure payment is overdue: if the domain or hosting isn't paid, the site can stop. The contractor isn't responsible for downtime if a third party blocked access to services because of non-payment.

Acts and reports: which metrics and how often

Acts and reports make support manageable. They're usually prepared once a month; with frequent releases you add interim reports once a week or two. The composition of a work report: a list of tasks, the type of work, the date and time of completion, the actual time spent, the result and a link to confirmation.

Ask for metrics that genuinely help, not statistics for the sake of statistics:

• the number of incidents by priority
• response time and recovery time for each critical incident
• the share of requests completed on time by agreed priority
• the remaining hours in the package or actual hours under the time-and-materials model
• a list of risks and technical debt: outdated plugins, vulnerabilities, stale backups, performance problems

Write down the acceptance form: who on the client's side accepts the work and within what period, and what counts as acceptance — for example a signed act or the absence of remarks within an agreed period.

Who owns the change requests and design materials

It's best to make this clause as specific as possible. Provide a list of artifacts:

• source code and scripts
• design files and prototypes
• content and texts, if they were created as part of the work
• documentation, instructions, diagrams, specifications
• settings and configurations created for your project

Define the moment rights transfer — usually after payment and acceptance. If payment is monthly, it's convenient to fix the transfer of rights to the results of each reporting period after the act is signed. If the project involves personal data, separately state that the contractor doesn't acquire rights to the data and can't use it outside support.

Repository access and the order of artifact transfer

The repository and handover artifacts are your insurance. The contract should answer three questions: where the code is, who has access and what you get in the end. The practical option for the client is a repository in their account, with the contractor getting access by role. Forbid shared accounts and use individual logins.

Besides the repository you need access to the server and hosting panel, to the CMS and admin panel, a list of domains and DNS, a list of third-party services, deploy and rollback instructions, a backup-restore instruction and a file with environment variables. Specify the transfer deadlines on termination and who accepts the handover on the client's side.

Fix the right to a copy: even if the repository is the client's, the contractor must export an archive of the code and documentation on request. This helps in force majeure and speeds up an audit.

What to provide for continuity when the contractor changes

Changing the support team always carries a risk of downtime. Describe which artifacts you transfer and in what form: access, a list of integrations, the environment scheme, deploy instructions, backup rules. If there's no documentation, fix that too — and add a duty to keep it current during support.

Fix the order of access transfer: who creates the accounts, who grants rights, how passwords change, how the fact of transfer is recorded. This helps avoid the situation where access exists but doesn't work.

Describe how support continues during the transition period. A common practice: the current contractor closes critical incidents until the handover date and takes no new large change requests, while the new contractor joins the diagnostics and gradually takes over responsibility.

Notice periods and the transition period

Specify the notice period for termination. It's needed by both sides: the client gets time to find a new team, the contractor gets time to close critical tasks and prepare the handover. Describe what work the contractor performs during the transition period: handling incidents under the current SLA, planned updates only by agreement, consultations for the new team.

Clarify how prioritization changes on the way out. Usually during the transition stability matters more to the business than development, so the contract should allow freezing change requests and focusing on supporting the prod environment.

Write down when the contractor's access to the systems ends. Don't do it instantly if the contractor is still responsible for stability, but don't leave access indefinitely either — fix a date after which access is disabled or switched to read-only.

A checklist for handing over access, data, documentation

Add a handover checklist appendix to the contract. It saves time and reduces the risk of forgetting something important, covering three layers — access, data and documentation.

• access: server and hosting panel, domain and DNS, SSL certificates, CMS and admin panel, database, repository and task system, analytics and third-party services
• data: current database dumps, site files and user uploads, environment configurations, a list of integrations and API keys, provider contacts
• documentation: a description of the architecture and the prod, stage, dev environments, deploy and rollback instructions, the backup schedule and recovery scenario, a description of critical modules and points of failure

In the checklist it's important to name the responsible people and the form of confirming the handover: a handover act, an email to the corporate inbox or an entry in the task system. Then the business is left with a clear trail.

What happens to unfinished tasks and payment

The contract should determine in advance what to do with tasks in progress at the moment of termination. Split them into three groups: incidents affecting availability and key functions are usually carried through to restored operation; planned work can be stopped at a clear point and handed over with its status, source and comments; tasks not yet started are recorded as canceled or passed to the new contractor.

Describe the billing rules. For a subscription and an hour package, specify how unused hours are counted and what happens to carryover. For time and materials — that the contractor invoices for actually completed work with a report and a task list.

Fix what happens to access when there's outstanding debt. The compromise is often built like this: the client keeps access to critical infrastructure, while the contractor can suspend new work until the debt is paid. This reduces the risk of the site stopping because of a financial dispute.