Post-Launch Warranty Terms
Document ID: WBL-DEL-WT-[ID]-v1.0 Project: [PROJECT NAME] Client: [CLIENT NAME] Launch Date: [DATE] Warranty Period: [30] days — from [LAUNCH DATE] to [LAUNCH DATE + 30 DAYS] Warranty Support Contact: [SUPPORT EMAIL] | [PHONE]
Purpose: This document defines the scope, limitations, and process for the post-launch warranty included with every Webility project delivery. It supplements and is governed by the terms of the applicable contract (WBL-CTR-[TYPE]-[ID]-v1.0 or WBL-MSA-v1.0 + WBL-SOW-[ID]-v1.0).
1. Warranty Period
The warranty period is [30] calendar days, beginning on the launch date (the date the project was made publicly accessible or handed over to the Client, whichever is earlier).
| Item | Date |
|---|---|
| Launch date | [DATE] |
| Warranty end date | [DATE + 30 DAYS] |
| Support contact during warranty | [EMAIL] / [PHONE] |
Extension: The warranty period cannot be extended without a written amendment signed by both Parties. Requests for extension must be submitted before the warranty expiry date.
2. What Is Covered
The warranty covers defects — defined as failures in functionality or display that were not present at the time of launch sign-off and are attributable to Webility's work.
2.1 Covered Defects
| Category | Examples | Covered? |
|---|---|---|
| Functionality failures | Form that stops working; button that doesn't submit; navigation link that 404s when it worked at launch | ✅ Yes |
| Display/rendering issues | Section overlapping on mobile at a viewport that passed testing; incorrect font loading; image not appearing | ✅ Yes |
| Integration failures | Automation workflow that stops processing new submissions without any change from Client; CRM not receiving form data | ✅ Yes |
| Post-launch data errors | Database error that appeared after launch with no changes made | ✅ Yes |
| Browser-specific regression | Feature works in Chrome but breaks in a browser that was included in the testing scope | ✅ Yes (within browsers listed in the launch checklist) |
| Configuration errors | Incorrect server or DNS configuration by Webility that causes issues discovered post-launch | ✅ Yes |
2.2 Warranty Conditions
For a defect to be covered under warranty, all of the following conditions must be met:
(a) The defect must be reported in writing within the warranty period; (b) The defect must be reproducible and verified by Webility; (c) The defect must exist in the deliverable as launched — not in content or configuration added by the Client after handover; (d) The defect must not fall under Section 3 (Exclusions); (e) The Client's invoice account must be in good standing (no outstanding overdue invoices).
3. What Is NOT Covered — Warranty Exclusions
The following are explicitly not covered by the warranty and will be quoted as separate billable work if the Client wishes to proceed:
3.1 New Feature Requests
Requests to add functionality, pages, content sections, or capabilities that were not in the agreed deliverable scope. These are Change Orders, not warranty issues.
Example: "Can we add a live chat widget?" — This is a new feature, not a warranty defect.
3.2 Client-Introduced Changes
Any defect or issue that results from changes made by the Client (or by a third party acting on the Client's behalf) after launch sign-off. This includes:
- Editing or deleting code, CSS, or template files directly
- Installing or updating plugins, themes, or extensions without Webility's involvement
- Changing hosting server settings, PHP versions, or server configurations
- Changing DNS records not authorized in writing by Webility
- Modifying automation workflow logic, mappings, or triggers
- Uploading malformed or oversized media that causes performance degradation
- Changing database records directly
The Client assumes full responsibility for any issues arising from unauthorized modifications.
3.3 Third-Party Platform Changes
Issues caused by changes, deprecations, outages, or API modifications made by third-party platforms (e.g., Google, Meta, HubSpot, Stripe, Cloudflare, a payment gateway, a CRM provider, a plugin developer, a theme developer). These are outside Webility's control.
Example: A plugin developer releases an update that breaks a feature — this is not a Webility warranty defect; it may be addressed under a Maintenance Plan.
3.4 Content and Data
- Broken links caused by the Client updating internal links or deleting pages
- Images that disappear because the Client deleted them from the media library
- Incorrect text, missing copy, or content errors introduced by the Client
- Data entered by the Client that causes display issues (e.g., an extremely long product title that breaks a layout not designed for it)
3.5 Hosting Environment Issues
Issues caused by the hosting environment not managed by Webility (if the Client uses their own hosting provider):
- Server outages or downtime at the Client's hosting provider
- Resource overuse causing PHP crashes or timeouts
- SSL expiry if the Client manages their own SSL
- Domain expiry or DNS misconfiguration at the Client's registrar
If Webility manages the hosting, server infrastructure issues are resolved at no charge during warranty. Application-layer issues remain subject to Section 3.2 and 3.3.
3.6 Scope Not Included in the Project
Any issue in a system, page, feature, or integration that was explicitly excluded from scope (documented in the SOW or contract Exclusions table). Issues in out-of-scope systems are not warranty items.
3.7 Performance Variability Within Agreed Targets
If the project included agreed performance targets (e.g., Lighthouse score ≥ 75 mobile), performance variation within a reasonable margin due to content changes or third-party scripts added by the Client is not a warranty issue.
3.8 Browser or Device Not Tested
Issues in browsers, browser versions, or devices not listed in the testing scope of the Launch Checklist (WBL-DEL-LC-[ID]-v1.0). The Client may request additional browser support via Change Order.
3.9 Security Incidents Caused by Client
Malware, hacking, or data exposure resulting from:
- Compromised CMS credentials (weak password, phishing, unauthorized sharing)
- Null/pirated plugins or themes installed by the Client
- Application-layer vulnerabilities introduced by the Client
- Third parties given access by the Client
3.10 Issues Reported After Warranty Expiry
Issues reported after [WARRANTY END DATE], regardless of when they originated. We recommend the Client review the system thoroughly during the warranty period and not wait until the last day to report issues.
4. Warranty Claim Process
4.1 How to Submit a Warranty Claim
All warranty claims must be submitted in writing to: [SUPPORT EMAIL]
Subject line format: WARRANTY — [CLIENT NAME] — [Brief description of issue]
Required information for each claim:
| Field | Details |
|---|---|
| Description | What is broken / not working as expected |
| Expected behavior | What should happen |
| Actual behavior | What is happening instead |
| URL(s) affected | Specific page URL(s) where the issue occurs |
| Steps to reproduce | Step-by-step instructions to see the issue |
| Browser and device | E.g., "Chrome 121 on macOS Ventura" or "Safari on iPhone 15" |
| First observed | When did you first notice this issue? |
| Screenshot / recording | Attach or link (tools like Loom, CleanShot, or a simple screenshot) |
Incomplete claims will be returned to the Client with a request for the missing information. The clock on our response time starts from when we receive a complete claim.
4.2 Response Times
| Priority | Description | Acknowledgement | Resolution Target |
|---|---|---|---|
| P1 — Critical | Site is completely inaccessible or primary conversion feature is broken | 2 hours | 4 hours |
| P2 — High | Significant feature broken (forms, checkout, major sections) | 4 business hours | 1 business day |
| P3 — Medium | Feature broken but has a workaround; visual issue affecting experience | 1 business day | 3 business days |
| P4 — Low | Cosmetic issue; minor display discrepancy | 2 business days | 5 business days |
Response times apply during business hours [Monday–Friday, 9am–6pm, Agency timezone]. P1 issues are handled outside business hours on best-effort basis.
4.3 Issue Triage
Upon receiving a warranty claim, Webility will:
- Acknowledge receipt in writing
- Assess whether the issue falls within warranty scope (per Section 2 and 3)
- If in scope: Reproduce the issue, develop a fix, deploy to staging, notify Client for verification, then deploy to production
- If out of scope: Notify the Client in writing with the reason and, if applicable, provide a quote to address it as billable work
Disputed triage decisions: If the Client believes an issue has been incorrectly excluded from warranty scope, they may escalate to the Agency's Account Director within [3] business days of receiving the exclusion notice.
5. Warranty Delivery
All warranty fixes will be:
(a) Tested by Webility before deployment to production (b) Deployed to the production environment by Webility (not the Client) (c) Confirmed in writing as resolved, with the Client given [2] business days to verify (d) Documented in a Warranty Resolution Log (maintained internally and available to the Client on request)
If a warranty fix is rejected by the Client as unresolved, Webility will re-examine and provide an updated resolution within the original timeline. If Webility and the Client cannot agree that an issue is resolved, either party may escalate per the contract dispute resolution clause.
6. Limitations
6.1 Number of warranty incidents: There is no limit on the number of covered warranty claims submitted during the warranty period, provided each claim is a distinct issue that meets the covered criteria.
6.2 Root cause, not symptoms: Webility will address the root cause of a covered defect, not just the symptom. If the same root cause generates multiple symptoms, this counts as one warranty incident.
6.3 No liability for business losses: Webility's warranty obligation is limited to remediation of covered defects. Webility is not liable for lost revenue, missed opportunities, data loss, or reputational harm occurring during a warranty-covered outage or defect period.
6.4 Warranty is not a Maintenance Plan: The warranty covers defects in the delivered work. It is not ongoing support, content updates, plugin management, security monitoring, or proactive maintenance. For those services, see Webility's Maintenance Plans.
7. Post-Warranty Support Options
After the warranty period ends, the following options are available:
| Option | Description | Contact |
|---|---|---|
| Website Care Plan — Starter | Monthly plugin updates, security monitoring, backups, minor content hours | [EMAIL] |
| Website Care Plan — Professional | All Starter + priority support, performance monitoring, [X] content hours/month | [EMAIL] |
| Website Care Plan — Business | All Professional + proactive audits, dedicated support SLA, expanded content hours | [EMAIL] |
| Automation Retainer | Ongoing AI/automation monitoring, optimization, and support | [EMAIL] |
| Ad-hoc Support | Billable at [RATE]/hour; no SLA commitment | [EMAIL] |
8. Acknowledgement
By signing the Project Handover document (WBL-DEL-HR-[ID]-v1.0) or the Launch Checklist (WBL-DEL-LC-[ID]-v1.0), the Client acknowledges receipt of this warranty document and agrees to its terms.
Webility — WBL-DEL-WT-[ID]-v1.0 | Post-Launch Warranty Terms This document supplements and does not replace the applicable contract. In case of conflict, the contract governs.