Trạng thái phiếu bảo hành: theo dõi từ tiếp nhận đến trả máy

Khi trung tâm bảo hành còn ít phiếu, kỹ thuật viên có thể nhớ trong đầu máy nào đang ở đâu. Nhưng khi số phiếu tăng lên, mỗi máy lại đi qua nhiều tay – quầy tiếp nhận, kỹ thuật kiểm tra, kho linh kiện, kỹ thuật sửa, quầy trả – thì việc chỉ ghi “đang sửa” hay “xong” trên phần mềm không còn đủ để trả lời câu hỏi của khách: máy tôi đến đâu rồi, bao giờ lấy được? Bài viết này đi sâu vào mô hình trạng thái của phiếu bảo hành dưới góc nhìn vận hành, dành cho người quản lý trung tâm, kỹ thuật viên và người thiết lập phần mềm. Tên các trạng thái trong bài chỉ mang tính minh họa, mỗi doanh nghiệp có thể điều chỉnh cho phù hợp với quy trình thực tế của mình.

Vì sao chỉ có “đang sửa” và “xong” là không đủ

Hai trạng thái nghe có vẻ gọn, nhưng thực chất “đang sửa” gom tất cả những gì xảy ra giữa lúc nhận máy và lúc giao máy. Trong khoảng đó, máy có thể đang nằm chờ kỹ thuật kiểm tra, chờ linh kiện về, chờ khách xác nhận chi phí ngoài bảo hành, hoặc đã sửa xong nhưng khách chưa đến lấy. Nếu tất cả đều hiện là “đang sửa”, người quản lý không biết phiếu nào thực sự có người đang làm, phiếu nào đang đứng yên.

Hệ quả dễ thấy nhất là khách gọi hỏi tiến độ, nhân viên phải đi hỏi lại kỹ thuật, kỹ thuật phải nhớ hoặc tìm máy trên kệ. Mỗi lần như vậy là một lần mất thời gian và dễ trả lời sai. Một điểm khác là phần mềm không thể tự gửi thông báo cho khách khi không có mốc trạng thái rõ ràng để làm sự kiện kích hoạt. Các giải pháp bảo hành điện tử có tích hợp Zalo thường gửi tin đúng lúc phiếu sửa chữa đổi trạng thái, với nội dung báo máy đã được tiếp nhận, đang sửa, đã sửa xong và hẹn ngày lấy máy. Muốn làm được điều đó, phiếu phải có đủ các mốc tương ứng.

Ngoài ra, có một lý do mang tính pháp lý mà nhiều trung tâm bỏ qua: theo quy định về bảo hành sản phẩm, hàng hóa, linh kiện, phụ kiện áp dụng từ ngày 01/7/2024, khoảng thời gian thực hiện bảo hành không được tính vào thời hạn bảo hành của sản phẩm. Để tính đúng, phần mềm cần biết chính xác thời điểm nhận máy và thời điểm trả máy – tức là cần hai mốc trạng thái rõ ràng ở đầu và cuối chuỗi.

Chuỗi trạng thái cơ bản và ý nghĩa từng bước

Một chuỗi trạng thái hợp lý nên phản ánh đúng việc máy đang ở chỗ ai và đang chờ gì. Dưới đây là chuỗi sáu bước thường gặp ở trung tâm bảo hành điện thoại, laptop, camera – những nơi cần tra từng máy theo IMEI hoặc serial ngay tại quầy.

Những bước dễ bị bỏ sót

Chờ kiểm tra thường bị gộp vào “đã nhận” hoặc “đang sửa”, nhưng đây lại là nơi máy đứng yên lâu nhất khi kỹ thuật quá tải. Tách riêng bước này giúp quản lý thấy ngay lượng máy đang xếp hàng.

Chờ linh kiện là trạng thái quan trọng vì máy không có lỗi của kỹ thuật viên mà kẹt do nguồn cung. Một màn hình tổng quan hiển thị con số kiểu “38 phiếu chờ linh kiện” cho người quản lý biết phải làm việc với bộ phận mua hàng chứ không phải giục kỹ thuật.

Chờ trả tách khỏi “đã trả” để phân biệt máy đã xong việc nhưng vẫn chiếm chỗ trong tủ với máy đã thực sự rời cửa hàng. Nhiều trung tâm chỉ dùng một trạng thái “xong” nên không biết có bao nhiêu máy khách chưa đến lấy, và cũng không có mốc để gửi tin nhắc khách.

Ghi nhận gì ở mỗi lần chuyển bước

Mỗi lần chuyển trạng thái nên lưu kèm thời điểm, người thực hiện và ghi chú ngắn. Riêng khi sửa xong, trạm bảo hành cần ghi lại lần sửa thứ mấy, linh kiện đã thay và nguyên nhân hỏng. Những thông tin này có hai giá trị: thứ nhất, thời hạn bảo hành của linh kiện thay thế được tính lại từ thời điểm thay, nên phần mềm phải gắn thời hạn riêng cho từng linh kiện đã thay thay vì dùng chung hạn của máy; thứ hai, quy định hiện hành cho phép người tiêu dùng yêu cầu đổi sản phẩm hoặc nhận lại tiền khi đã bảo hành từ 03 lần trở lên trong thời hạn bảo hành mà vẫn không khắc phục được lỗi. Không đếm được số lần sửa theo từng IMEI, trung tâm sẽ không biết mình đang đứng ở đâu so với ngưỡng này.

Ai được chuyển trạng thái nào

Chuỗi trạng thái chỉ đáng tin khi việc chuyển bước gắn với đúng người làm việc đó. Nếu ai cũng có thể đổi trạng thái bất kỳ, dữ liệu sẽ nhanh chóng lệch với thực tế: quầy đổi sang “đang sửa” để trả lời khách cho yên tâm, trong khi máy vẫn nằm trên kệ chờ.

• Quầy tiếp nhận: tạo phiếu ở trạng thái “Đã nhận”; chuyển sang “Chờ kiểm tra” khi bàn giao máy vào khu kỹ thuật; chuyển “Chờ trả” sang “Đã trả” khi khách ký nhận.
• Kỹ thuật viên: chuyển “Chờ kiểm tra” sang “Đang sửa” khi bắt đầu mở máy; chuyển sang “Chờ linh kiện” khi xác định thiếu linh kiện; chuyển “Chờ linh kiện” về “Đang sửa” khi linh kiện đã được gắn vào phiếu; chuyển “Đang sửa” sang “Chờ trả” sau khi kiểm tra lại đạt.
• Kho linh kiện: không đổi trạng thái phiếu, nhưng cập nhật linh kiện đã về và gắn vào phiếu để kỹ thuật viên nhận được thông báo.
• Quản lý: có quyền chuyển ngược trạng thái hoặc hủy phiếu, nhưng mọi thao tác ngược đều phải có ghi chú lý do.

Cách phân quyền này tương tự mô hình mà một số hãng lớn áp dụng cho dịch vụ sửa chữa gửi qua bưu điện, trong đó phiếu đi từ “Đã yêu cầu” sang “Đã chỉ định kỹ sư”, rồi “Đang sửa chữa” và cuối cùng là “Đã sửa chữa và gửi đi” – mỗi mốc do một bộ phận khác nhau xác nhận. Điểm chung là trạng thái chỉ tiến lên khi người chịu trách nhiệm ở bước đó thực sự làm xong việc.

Phân biệt trạng thái phiếu với trạng thái IMEI

Một nhầm lẫn thường gặp khi thiết lập phần mềm là trộn trạng thái của phiếu sửa chữa với trạng thái của chiếc máy trong kho. Hệ thống quản lý hàng hóa theo IMEI thường chia máy thành các trạng thái như mới nhập, đã bán, đang vận chuyển, lỗi, bảo hành, hàng demo. Đó là trạng thái tồn kho, trả lời câu hỏi “máy này có bán được không”. Còn trạng thái phiếu trả lời “công việc sửa máy này đang đến đâu”. Hai chuỗi nên tồn tại song song: khi phiếu được tạo, máy chuyển sang trạng thái IMEI “bảo hành”; khi phiếu “Đã trả”, máy quay lại trạng thái phù hợp. Gộp hai chuỗi làm một sẽ khiến danh sách trạng thái phình to và rối.

Phát hiện phiếu kẹt lâu ở một trạng thái

Lợi ích lớn nhất của chuỗi trạng thái chi tiết là biến câu hỏi “phiếu nào đang có vấn đề” thành một bộ lọc. Cách làm gồm ba lớp.

Lớp 1: Lọc theo trạng thái

Phần mềm nên cho phép chọn nhiều trạng thái cùng lúc trong bộ lọc, ví dụ lọc đồng thời “Chờ kiểm tra” và “Chờ linh kiện” để nhìn toàn bộ máy đang đứng yên. Đây là danh sách người quản lý nên xem đầu mỗi ca.

Lớp 2: Tính số ngày nằm ở trạng thái hiện tại

Vì mỗi lần chuyển bước đều có dấu thời gian, phần mềm có thể hiển thị cột “đã ở trạng thái này bao lâu”. Doanh nghiệp tự đặt ngưỡng cảnh báo cho từng trạng thái tùy năng lực của mình – ngưỡng cho “Chờ kiểm tra” thường ngắn hơn “Chờ linh kiện” vì kiểm tra là việc nội bộ, còn linh kiện phụ thuộc nhà cung cấp. Phiếu vượt ngưỡng được tô màu hoặc đẩy lên đầu danh sách.

Lớp 3: Đọc nguyên nhân từ vị trí kẹt

• Nhiều phiếu kẹt ở Chờ kiểm tra: thiếu kỹ thuật viên hoặc phân việc chưa đều.
• Nhiều phiếu kẹt ở Chờ linh kiện: cần rà lại danh mục linh kiện tồn kho tối thiểu và nhà cung cấp.
• Nhiều phiếu kẹt ở Đang sửa: có thể kỹ thuật viên nhận quá nhiều máy cùng lúc, hoặc ca sửa khó cần chuyển cấp.
• Nhiều phiếu kẹt ở Chờ trả: khách chưa được thông báo, hoặc thông báo gửi nhưng không nhắc lại.

Với trường hợp cuối, tin nhắn tự động qua Zalo khi phiếu chuyển sang “Chờ trả” – báo máy đã sửa xong và hẹn ngày lấy – là cách giảm tồn kho máy đã sửa mà không cần nhân viên gọi từng người. Đồng thời, cho khách tự tra hạn bảo hành và tiến độ theo IMEI cũng giảm số cuộc gọi hỏi thăm vào quầy.

Tránh thiết kế quá nhiều trạng thái gây rối

Sau khi thấy lợi ích của việc chia nhỏ, nhiều trung tâm đi quá đà: thêm “chờ khách duyệt chi phí”, “chờ chuyển hãng”, “chờ kỹ thuật cấp cao”, “chờ kiểm tra lại”, “đã gọi khách lần 1”, “đã gọi khách lần 2”… Danh sách dài khiến nhân viên chọn sai, và báo cáo trở nên khó đọc. Vài nguyên tắc để giữ chuỗi gọn:

1. Mỗi trạng thái phải trả lời được “máy đang chờ ai”. Nếu hai trạng thái cùng chờ một bộ phận, hãy gộp lại và dùng ghi chú để phân biệt.
2. Việc lặp lại không phải là trạng thái. “Đã gọi khách lần 2” là một hành động, nên ghi vào lịch sử phiếu chứ không tạo trạng thái mới.
3. Nhánh ngoại lệ dùng cờ, không dùng trạng thái. Máy ngoài bảo hành cần khách duyệt chi phí có thể giữ nguyên ở “Chờ kiểm tra” hoặc “Đang sửa” kèm cờ “chờ khách xác nhận”, thay vì sinh thêm trạng thái.
4. Giới hạn số trạng thái mà một người được thấy. Kỹ thuật viên chỉ cần thấy các trạng thái mình có quyền chuyển; quầy chỉ cần thấy đầu và cuối chuỗi.
5. Thử nghiệm với phiếu thật trước khi chốt. Chạy chuỗi trên vài chục phiếu trong một tuần, xem trạng thái nào không ai dùng thì bỏ.

Một lưu ý về danh mục: thời hạn bảo hành thường khác nhau theo nhóm sản phẩm, ví dụ danh mục máy mới áp dụng 365 ngày còn máy cũ áp dụng 90 ngày. Những khác biệt này thuộc về cấu hình danh mục và thời hạn, không nên biến thành trạng thái phiếu. Chuỗi trạng thái nên giống nhau cho mọi loại máy để nhân viên không phải nhớ nhiều luồng.

Cách rà soát định kỳ chuỗi trạng thái

Chuỗi trạng thái không phải thiết lập một lần rồi để yên. Nó cần được soát lại theo nhịp vận hành để bảo đảm dữ liệu trên phần mềm khớp với máy trên kệ.

Rà soát hằng ngày

• Đầu ca: lọc tất cả phiếu đang ở trạng thái chờ, sắp xếp theo thời gian nằm lâu nhất, phân việc cho kỹ thuật.
• Cuối ca: đối chiếu số máy trong tủ “Chờ trả” với số phiếu đang ở trạng thái này. Lệch một máy là dấu hiệu có phiếu chưa được cập nhật.

Rà soát hằng tuần

• Thống kê số phiếu đã qua mỗi trạng thái và thời gian trung bình ở từng bước; bước nào tăng bất thường cần xem nguyên nhân.
• Kiểm tra những phiếu có thao tác chuyển ngược trạng thái; nếu lặp lại ở cùng một người hoặc cùng một bước, có thể quy trình đang bị hiểu sai.
• Rà các IMEI có nhiều phiếu trong thời hạn bảo hành để chủ động xử lý trước khi chạm ngưỡng 03 lần theo quy định về đổi, trả.

Rà soát khi thay đổi quy trình

Khi mở thêm dịch vụ (ví dụ nhận sửa ngoài bảo hành, hoặc gửi máy về hãng), hãy hỏi: nhánh mới này có thể đi qua chuỗi hiện tại kèm cờ phân loại không, hay thật sự cần một trạng thái mới? Chỉ thêm trạng thái khi có một bộ phận mới chịu trách nhiệm cho máy ở bước đó.

Nhìn rộng hơn, việc vận hành chuỗi trạng thái minh bạch cũng là cách doanh nghiệp thực hiện đúng và đủ trách nhiệm bảo hành với sản phẩm mình cung cấp, như luật về bảo vệ quyền lợi người tiêu dùng yêu cầu. Khách hàng thấy được máy mình đang ở đâu, trung tâm biết phiếu nào cần đẩy, và lịch sử mỗi IMEI được giữ nguyên để dùng khi cần đối chiếu.

Câu hỏi thường gặp

Chuỗi sáu trạng thái có bắt buộc phải dùng đúng tên như trong bài không?
Không. Tên trạng thái chỉ là ví dụ minh họa. Điều quan trọng là mỗi trạng thái phải cho biết máy đang chờ bộ phận nào, và việc chuyển bước do đúng người thực hiện.

Trạng thái phiếu có liên quan gì đến thời hạn bảo hành không?
Có. Mốc “Đã nhận” và “Đã trả” giúp xác định khoảng thời gian thực hiện bảo hành, khoảng này không tính vào thời hạn bảo hành của sản phẩm theo quy định hiện hành. Ngoài ra, khi phiếu ghi linh kiện đã thay, phần mềm cần gắn thời hạn bảo hành riêng cho linh kiện đó tính từ ngày thay.

Làm sao biết một phiếu đang “kẹt” nếu không đặt ngưỡng cố định?
Hãy sắp xếp danh sách phiếu theo thời gian đã nằm ở trạng thái hiện tại, từ lâu nhất đến mới nhất. Những phiếu nằm trên cùng là nơi cần xem trước. Ngưỡng cảnh báo cụ thể do doanh nghiệp tự đặt theo năng lực của mình.

Có nên tạo trạng thái riêng cho máy ngoài bảo hành?
Thường không cần. Máy ngoài bảo hành vẫn đi qua các bước nhận, kiểm tra, sửa, trả như máy trong bảo hành; chỉ khác ở khâu khách xác nhận chi phí. Nên dùng cờ phân loại hoặc ghi chú thay vì thêm trạng thái.

Phần mềm gửi tin Zalo dựa vào trạng thái nào?
Các giải pháp tích hợp Zalo thường gửi tin khi phiếu đổi trạng thái: tiếp nhận, đang sửa, đã sửa xong và hẹn ngày lấy máy; một số còn gửi tin trước ngày bảo hành hết hạn. Vì vậy chuỗi trạng thái cần có đủ các mốc tương ứng thì tin mới đi đúng lúc.

Nếu bạn đang thiết lập hoặc rà soát lại chuỗi trạng thái cho trung tâm bảo hành của mình và cần một công cụ theo dõi phiếu theo từng IMEI, hãy liên hệ đội ngũ SoftAZ qua phanmembaohanh.vn để được tư vấn mô hình phù hợp với quy mô và cách vận hành thực tế của bạn.