Bảo hành website sau thiết kế nên được hiểu là cam kết sửa các lỗi thuộc phạm vi đã triển khai và nghiệm thu, trong một khoảng thời gian hoặc theo điều kiện được thỏa thuận trước. Bảo hành không đồng nghĩa với bảo trì định kỳ, nhập nội dung, tối ưu SEO liên tục hay phát triển thêm chức năng mới.
Điểm cần kiểm tra không phải chỉ là “bảo hành bao lâu”, mà là lỗi nào được bảo hành, lỗi nào không, thời gian phản hồi ra sao, ai cung cấp bằng chứng và khi nào một yêu cầu được chuyển thành change request có tính phí.
Bảo hành, bảo trì và phát triển thêm khác nhau thế nào?
| Nhóm | Mục tiêu | Ví dụ | Cách tính thường gặp |
|---|---|---|---|
| Bảo hành | Sửa lỗi thuộc scope đã triển khai và nghiệm thu | Form không gửi, layout sai so với bản duyệt, chức năng đã có hoạt động sai | Trong thời hạn/phạm vi cam kết |
| Bảo trì | Duy trì website ổn định sau launch | Backup, update, monitoring, kiểm tra bảo mật, form, performance | Gói định kỳ hoặc SLA riêng |
| Hỗ trợ vận hành | Giúp người dùng/admin xử lý tình huống sử dụng | Hướng dẫn nhập nội dung, reset quyền, kiểm tra cấu hình | Theo gói hỗ trợ hoặc số giờ |
| Phát triển thêm | Thay đổi hoặc mở rộng sản phẩm | Thêm booking, thêm ngôn ngữ, redesign trang, tích hợp CRM mới | Báo giá/change request mới |
Bài bảo trì website WordPress gồm những gì đi sâu vào phần vận hành định kỳ. S06 này chỉ tập trung vào ranh giới bảo hành sau khi website đã được bàn giao.
Vì sao chỉ hỏi “bảo hành mấy tháng?” là chưa đủ?
Thị trường hiện sử dụng nhiều cách gọi khác nhau. Có đơn vị công bố bảo hành sau launch 30 ngày, có nơi 60 ngày, có nơi dùng cụm “bảo hành trọn đời” nhưng kèm điều kiện phạm vi cụ thể. Vì vậy, thời lượng tự nó không cho biết chất lượng chính sách.
Một chính sách 12 tháng nhưng chỉ ghi “hỗ trợ kỹ thuật” mơ hồ có thể kém hữu ích hơn một chính sách ngắn hơn nhưng định nghĩa rõ:
- Lỗi nào được coi là defect.
- Mức độ ưu tiên sự cố.
- Kênh tiếp nhận.
- Thời gian phản hồi mục tiêu.
- Cách tái hiện lỗi.
- Điều kiện không thuộc bảo hành.
- Quy trình escalate và rollback.
Vì vậy khi so sánh nhà cung cấp, hãy đọc scope + exclusions + response process, không chỉ nhìn số ngày.
Những lỗi nào thường hợp lý để đưa vào phạm vi bảo hành?
Phạm vi chính xác phải theo hợp đồng, nhưng về logic nghiệm thu, các nhóm sau thường nên được làm rõ:
1. Chức năng đã nghiệm thu nhưng hoạt động sai
- Form không gửi dữ liệu như thiết kế.
- Email xác nhận không được tạo đúng luồng.
- Booking, cart hoặc checkout sai logic đã duyệt.
- Search hoặc filter không trả kết quả theo rule đã thống nhất.
- Phân quyền không đúng scope.
Điểm quan trọng là chức năng đó phải nằm trong scope và có tiêu chí nghiệm thu trước launch.
2. Lỗi giao diện so với bản thiết kế đã duyệt
- Layout vỡ trên breakpoint đã nằm trong scope.
- Component hiển thị sai trạng thái.
- Typography hoặc spacing sai rõ rệt so với design system.
- Nút hoặc menu không thao tác được trên thiết bị đã xác định.
Không nên dùng bảo hành để yêu cầu redesign mới sau khi đã duyệt UI.
3. Lỗi do phần mã custom được triển khai trong dự án
Nếu một module custom hoạt động sai với requirement đã chốt, đây thường là nhóm cần được xác định rõ trong bảo hành. Tuy nhiên nếu lỗi phát sinh do API bên thứ ba thay đổi hoặc dependency bên ngoài không còn tương thích, cách xử lý có thể thuộc maintenance/change request tùy thỏa thuận.
4. Lỗi phát hiện sau launch nhưng có nguyên nhân từ bản build đã bàn giao
Một số lỗi chỉ xuất hiện khi có traffic thật, dữ liệu thật hoặc tình huống mà QA không tái hiện trước launch. Chính sách tốt nên quy định cách xác minh nguyên nhân thay vì tự động mặc định mọi lỗi sau launch là lỗi bảo hành.
Những việc thường không nên mặc định là bảo hành
1. Thêm chức năng mới
Ví dụ sau launch doanh nghiệp muốn thêm loyalty, booking, chatbot, tài khoản thành viên hoặc tích hợp ERP. Đây là thay đổi phạm vi, không phải defect của bản đã nghiệm thu.
2. Thay đổi giao diện theo ý tưởng mới
Nếu UI đã được duyệt và hoạt động đúng, việc đổi layout, màu sắc, cấu trúc section hoặc CTA thường thuộc cải tiến.
3. Nhập hoặc chỉnh sửa nội dung thường xuyên
Thay banner, đăng sản phẩm, cập nhật bài viết hoặc viết landing page mới là công việc vận hành/content, trừ khi hợp đồng bảo hành ghi rõ bao gồm.
4. Lỗi do người dùng hoặc bên thứ ba thay đổi hệ thống
Ví dụ cài plugin mới, sửa source, đổi DNS, thay theme, chỉnh cấu hình server hoặc xoá dữ liệu. Chính sách cần quy định rõ việc thay đổi ngoài quy trình có thể ảnh hưởng phạm vi bảo hành.
5. Lỗi do dịch vụ bên thứ ba thay đổi
Payment gateway, API, plugin SaaS, browser hoặc nền tảng khác có thể thay đổi mà đơn vị thiết kế không kiểm soát. Trách nhiệm lúc này cần được phân loại thành vendor support, maintenance hoặc change request tùy nguyên nhân.
6. Sự cố bảo mật không xuất phát từ defect trong scope
Không nên dùng bảo hành như cam kết website “không bao giờ bị hack”. Nếu phát hiện incident, cần chuyển sang quy trình phản ứng sự cố và phân tích nguyên nhân. Bài website WordPress bị hack cần làm gì mô tả workflow xử lý riêng.
Phân loại yêu cầu sau launch bằng 4 câu hỏi
| Câu hỏi | Nếu “Có” | Nhóm xử lý có khả năng |
|---|---|---|
| Yêu cầu này đã nằm trong scope được duyệt? | Có | Đi tiếp kiểm tra defect |
| Hệ thống hiện đang khác tiêu chí nghiệm thu? | Có | Có thể là bảo hành |
| Nguyên nhân do thay đổi mới hoặc bên thứ ba? | Có | Maintenance/change request |
| Yêu cầu tạo hành vi hoặc đầu ra mới? | Có | Phát triển thêm |
Ma trận này không thay thế hợp đồng, nhưng giúp đội support tránh tranh luận theo cảm tính.
Severity và response time nên được định nghĩa thế nào?
Không nên nhầm thời gian phản hồi với thời gian sửa xong. Response time là lúc đội hỗ trợ xác nhận đã nhận ticket và bắt đầu phân loại. Resolution time phụ thuộc nguyên nhân, mức độ phức tạp và dependency.
Một mô hình có thể tham khảo:
| Mức | Ví dụ | Kỳ vọng quy trình |
|---|---|---|
| P1 – Critical | Website down, checkout hỏng hoàn toàn, mất dữ liệu đang diễn ra | Tiếp nhận ngay theo kênh khẩn; ưu tiên khôi phục dịch vụ trước |
| P2 – High | Luồng chính lỗi nhưng có workaround | Phân loại nhanh, xác định impact và owner |
| P3 – Normal | Lỗi UI cục bộ, chức năng phụ | Xử lý trong hàng đợi bình thường |
| P4 – Request | Yêu cầu thay đổi hoặc cải tiến | Chuyển sang estimate/change request |
Không nên tự ghi một SLA số giờ nếu doanh nghiệp và nhà cung cấp chưa thực sự thống nhất nguồn lực. Điều cần thiết là hợp đồng phải nói rõ giờ hỗ trợ, kênh tiếp nhận, mức ưu tiên và response target.
Ticket bảo hành nên có bằng chứng gì?
Một ticket tốt giúp rút ngắn thời gian tái hiện lỗi. Nên có:
- URL bị lỗi.
- Thời điểm phát hiện.
- Thiết bị và trình duyệt.
- Tài khoản/role nếu liên quan.
- Các bước tái hiện.
- Kết quả kỳ vọng.
- Kết quả thực tế.
- Ảnh hoặc video nếu phù hợp.
- Request ID / order ID nếu có, nhưng không gửi secret hoặc dữ liệu nhạy cảm qua kênh không an toàn.
Đội support sau đó cần ghi thêm nguyên nhân, phạm vi ảnh hưởng, bản sửa, cách test và trạng thái deploy.
Khi nào một ticket nên trở thành change request?
Một yêu cầu nên chuyển khỏi bảo hành khi nó tạo ra scope mới. Ví dụ:
- Thêm field mới vào form và thay cả quy trình CRM.
- Thêm phương thức thanh toán.
- Thêm language version.
- Đổi logic giá.
- Thêm loại tài khoản.
- Redesign lại trang sau khi đã nghiệm thu.
Change request nên ghi rõ: mô tả thay đổi, lý do, page/module bị ảnh hưởng, effort, ảnh hưởng timeline, test scope và chi phí nếu có.
Bài quy trình thiết kế website có phần riêng về change control và Definition of Done từng giai đoạn.
Bảo hành nên bắt đầu từ mốc nào?
Không có một mốc bắt buộc áp dụng cho mọi dự án. Các lựa chọn thường gặp gồm:
- Ngày go-live production.
- Ngày ký biên bản nghiệm thu.
- Ngày hoàn tất bàn giao.
Quan trọng là hợp đồng phải ghi rõ một mốc duy nhất để tránh tranh luận. Nếu go-live trước nghiệm thu vài ngày, cần biết giai đoạn đó thuộc hypercare, UAT hay đã tính vào bảo hành.
Hypercare sau launch có khác bảo hành không?
Hypercare là giai đoạn theo dõi sát ngay sau launch, khi đội dự án ưu tiên kiểm tra lỗi, dữ liệu và hành vi thực tế. Nó có thể nằm trong bảo hành nhưng không đồng nghĩa với toàn bộ thời hạn bảo hành.
Trong hypercare, nên kiểm tra:
- Uptime và lỗi 5xx.
- Form, email, CRM, booking hoặc checkout.
- Analytics/tracking.
- Search Console và indexability.
- Error log.
- Backup và restore readiness.
Website đã nghiệm thu trước launch vẫn cần theo dõi thực tế vì một số vấn đề chỉ xuất hiện khi production nhận traffic và dữ liệu thật.
Bảo hành có cần backup và rollback không?
Có. Sửa bug trực tiếp trên production mà không có snapshot hoặc rollback plan có thể biến một lỗi nhỏ thành sự cố lớn hơn.
Với thay đổi có rủi ro:
- Xác định version hiện tại.
- Tạo backup/snapshot.
- Tái hiện lỗi.
- Sửa trên staging hoặc branch phù hợp nếu có thể.
- Test regression.
- Deploy theo change log.
- Read-back/verify sau deploy.
- Rollback nếu phát sinh lỗi nghiêm trọng.
Ai chịu phí license, hosting và dịch vụ bên thứ ba trong thời gian bảo hành?
Không nên mặc định phí hạ tầng và license nằm trong bảo hành. Domain, hosting, plugin, theme, font, API, email, CDN hoặc SaaS có chu kỳ thanh toán riêng.
Hợp đồng nên ghi:
- Dịch vụ nào do doanh nghiệp đứng tên.
- Dịch vụ nào do agency đứng tên.
- Ngày renewal.
- Phí có bao gồm trong gói hay không.
- Điều gì xảy ra nếu license hết hạn.
Bài quyền sở hữu domain, hosting, source code và dữ liệu sau bàn giao có ma trận sâu hơn về owner và license.
Bảo hành có bao gồm SEO không?
Không nên dùng bảo hành để cam kết thứ hạng. Tuy nhiên nếu scope bàn giao có các tiêu chí kỹ thuật cụ thể như canonical, sitemap, noindex, internal link hoặc tracking, và cấu hình đó sai so với tiêu chí nghiệm thu do lỗi triển khai, thì có thể xử lý như defect kỹ thuật theo hợp đồng.
Việc phát triển nội dung, tăng authority, tối ưu search task hoặc cải thiện thứ hạng là hoạt động SEO liên tục, không phải “bảo hành website”.
Bảo hành có bao gồm bảo mật không?
Bảo hành có thể bao gồm việc sửa một lỗ hổng hoặc lỗi cấu hình do phần triển khai custom nếu điều đó nằm trong trách nhiệm đã thỏa thuận. Nhưng không nên hiểu là bảo đảm website không bao giờ gặp tấn công, credential theft, zero-day hoặc sự cố từ bên thứ ba.
Bảo mật dài hạn thuộc vận hành/bảo trì: update, backup, quyền truy cập, monitoring và incident response.
Checklist điều khoản bảo hành nên có trong hợp đồng
- Mốc bắt đầu và kết thúc bảo hành.
- Module/page/function thuộc phạm vi.
- Định nghĩa defect.
- Nhóm excluded request.
- Giờ/kênh hỗ trợ.
- Severity và response target.
- Quy trình cung cấp bằng chứng.
- Cách xử lý third-party dependency.
- Quy trình backup/rollback.
- Quyền truy cập vendor trong thời gian bảo hành.
- Cách chuyển ticket thành change request.
- Điều kiện kết thúc hoặc vô hiệu bảo hành.
- Cách bàn giao khi đổi nhà cung cấp.
Bảng phân loại nhanh 12 tình huống sau launch
| Tình huống | Khả năng phân loại |
|---|---|
| Form đã nghiệm thu nhưng không gửi được | Bảo hành nếu lỗi thuộc bản build |
| Muốn thêm field mới vào form | Change request |
| Plugin cần cập nhật phiên bản mới | Bảo trì |
| Trang vỡ trên breakpoint đã nằm trong QA scope | Bảo hành nếu do triển khai |
| Muốn đổi toàn bộ hero | Cải tiến/content |
| API bên thứ ba đổi schema | Maintenance/change request tùy hợp đồng |
| Website bị down do hosting | Hosting/support, không mặc định là warranty code |
| Checkout sai logic đã duyệt | Bảo hành nếu defect của implementation |
| Thêm phương thức thanh toán | Phát triển thêm |
| Thay text và ảnh sản phẩm | Content operation |
| Sửa canonical cấu hình sai từ lúc bàn giao | Có thể là bảo hành kỹ thuật |
| Muốn SEO từ khóa mới | SEO/content scope riêng |
Cách nghiệm thu để sau này bảo hành không tranh cãi
Bảo hành chỉ rõ khi nghiệm thu rõ. Trước launch, mỗi luồng quan trọng nên có expected result và evidence.
- Form: test case, người nhận, dữ liệu lưu.
- Checkout: case thành công/thất bại.
- Booking: rule ngày, slot, email.
- UI: breakpoint và browser nằm trong scope.
- Tracking: event nào được xác nhận.
- SEO technical: canonical, noindex, sitemap, status.
- Admin: role nào làm được gì.
Bộ checklist nghiệm thu và bàn giao website giúp tạo baseline trước khi thời hạn bảo hành bắt đầu.
Câu hỏi thường gặp
Bảo hành website bao lâu là hợp lý?
Không có một thời hạn chung phù hợp mọi dự án. Website nhỏ, website custom và hệ thống có nhiều tích hợp có risk profile khác nhau. Hãy đánh giá phạm vi, exclusions, support process và bằng chứng trước khi nhìn số ngày.
Bảo hành trọn đời có nghĩa là mọi lỗi đều sửa miễn phí?
Không nên hiểu như vậy nếu chưa đọc điều kiện. Cụm “trọn đời” thường vẫn có scope và exclusions. Cần xem chính xác defect nào được cover, dependency nào bị loại và có điều kiện hosting/maintenance hay không.
Hết bảo hành thì website có ngừng được hỗ trợ không?
Không nhất thiết. Sau bảo hành, doanh nghiệp có thể dùng hợp đồng bảo trì, support theo giờ hoặc change request tùy nhu cầu.
Agency có thể từ chối bảo hành nếu bên khác đã sửa source không?
Điều này phụ thuộc hợp đồng. Về kỹ thuật, thay đổi ngoài kiểm soát có thể làm khó xác định nguyên nhân. Chính sách nên quy định rõ module nào bị ảnh hưởng và cách đánh giá thay vì từ chối chung cho toàn website.
Bảo hành có bao gồm tốc độ website không?
Chỉ nên coi là bảo hành nếu có tiêu chí performance cụ thể trong scope và lỗi hiện tại xuất phát từ implementation đã bàn giao. Traffic, hosting, script bên thứ ba và nội dung mới có thể làm hiệu năng thay đổi sau launch.
Kết luận
Bảo hành website sau thiết kế nên tập trung vào defect của phạm vi đã nghiệm thu. Bảo trì giữ hệ thống ổn định theo thời gian; hỗ trợ giúp vận hành; phát triển thêm tạo scope mới. Ba nhóm này có thể do cùng một nhà cung cấp thực hiện nhưng phải được tách bằng điều khoản, ticket và bằng chứng rõ ràng.
Nếu đang chuẩn bị dự án tại Nha Trang, xem dịch vụ thiết kế website Nha Trang để đối chiếu phạm vi từ QA đến bàn giao; còn trước khi ký nghiệm thu, hãy dùng checklist bàn giao để tạo baseline cho giai đoạn bảo hành.
Nguồn tham khảo
Nhận tư vấn website và SEO theo mục tiêu kinh doanh
Chúng tôi giúp bạn xác định vấn đề ưu tiên, hướng triển khai và cách đo lường hiệu quả.
Nhận tư vấn miễn phí →
Đoàn Trình Dục
Chia sẻ kiến thức thực tế về SEO, nội dung và thiết kế website phục vụ tăng trưởng doanh nghiệp.
Xem hồ sơ tác giả →
