Mã lỗi complaint tóc giả: chuẩn hóa defect code để đọc xu hướng và mở CAPA đúng chỗ

Complaint data chỉ có giá trị khi cùng một vấn đề được gọi bằng cùng một tên. Nếu một khách báo “rụng tóc”, nhân viên A chọn mã “hair issue”, nhân viên B chọn “quality”, nhân viên C nhập text tự do “rụng nhiều”, dashboard sẽ không biết đây có phải cùng một pattern hay không. Khi volume tăng, dữ liệu complaint bị phân mảnh và CAPA dễ ưu tiên sai.

Defect code taxonomy là hệ thống mã hóa giúp chuyển mô tả complaint thành dữ liệu có cấu trúc. Nó không thay root-cause investigation; defect code ghi triệu chứng hoặc defect được quan sát/xác nhận, còn cause code chỉ được gán khi investigation có evidence.

Trong tóc giả, complaint có thể liên quan hair, base, fit, appearance, color, shedding, tangling, knot, attachment, label, packaging hoặc order identity. Taxonomy tốt cần đủ chi tiết để hành động nhưng không quá nhiều mã khiến người dùng chọn ngẫu nhiên.

1. Defect code khác cause code

Defect code trả lời khách hoặc inspector thấy gì. Cause code trả lời vì sao nó xảy ra.

Ví dụ defect là excessive shedding. Cause có thể là knot process parameter, material issue, damage during use hoặc unknown pending investigation.

Không nên gán cause ngay lúc nhận complaint nếu chưa điều tra. Tách hai lớp giúp data trung thực.

2. Tại sao text tự do chưa đủ?

Text tự do giữ câu chuyện chi tiết nhưng khó trend. “Màu không giống mẫu”, “lệch tone”, “color mismatch” có thể cùng family nhưng search text không ổn định.

Giải pháp là giữ cả structured defect code, verbatim customer description, photo/evidence và analyst notes.

Không bỏ text; chỉ bổ sung structure.

3. Bắt đầu bằng defect family

Family ở level cao có thể gồm: - HAIR; - BASE; - FIT; - APPEARANCE; - COLOR; - WORKMANSHIP; - ATTACHMENT; - LABEL/IDENTITY; - PACKAGING; - ORDER/LOGISTICS.

Family giúp dashboard tổng quan. Sau đó level 2 hoặc 3 chi tiết hơn.

4. Hair family

Các subcode có thể gồm shedding, tangling, matting, dryness, breakage, texture mismatch, length mismatch và density issue.

Phải có định nghĩa để phân biệt tangling và matting, shedding và breakage. Nếu không, coders sẽ dùng tùy ý.

Một example photo có thể hỗ trợ nhưng không thay definition.

5. Base family

Có thể gồm lace tear, seam issue, base dimension, edge lifting, poly separation, stretch/deformation và component detachment.

Location field bổ sung: front, temple, crown, nape, side.

Không tạo code riêng cho mọi location nếu có thể dùng attribute riêng.

6. Appearance và workmanship

Ví dụ: - hairline density; - visible knot; - crown direction; - asymmetry; - uneven cut; - flyaway hoặc excess short hair; - curl pattern inconsistency.

Visual standard nên hỗ trợ coding.

Mã không nên thay acceptance criteria.

7. Color

Tách overall shade mismatch, root color mismatch, highlight/blend issue, lace/base tone và color transfer/fading claim.

Nếu khách dùng ngôn ngữ chủ quan, record customer statement và evidence trước khi xác nhận defect.

Không tự kết luận manufacturing defect chỉ từ code.

8. Fit complaint

Fit có thể liên quan cap too tight, cap too loose, ear tab alignment, nape fit, circumference/size và pressure point.

Một số fit complaint có thể do size selection hoặc usage, không nhất thiết manufacturing.

Cause investigation sẽ phân biệt.

9. Label và identity

Nhóm này nên high visibility: - wrong SKU label; - wrong color label; - wrong barcode; - mixed customer artwork; - missing label; - duplicate hoặc conflicting label.

Identity issue có thể cần severity cao hơn tùy impact.

10. Packaging

Có thể gồm box damage, product deformation from pack, missing insert/accessory, moisture, seal issue và wrong pack configuration.

Tách packaging defect khỏi logistics damage nếu evidence cho phép.

Nếu chưa rõ, dùng pending classification thay vì đoán.

11. Severity là field riêng

Đừng nhúng severity vào defect name như “critical shedding”.

Severity nên là field có rule như critical, major, minor hoặc hệ thống riêng của doanh nghiệp.

Cùng defect type có thể severity khác tùy phạm vi và impact.

12. Status của code

Complaint intake có thể dùng CUSTOMER_REPORTED, VERIFIED, NOT_VERIFIED, DUPLICATE và INFORMATION_ONLY.

Defect code khi chưa verified vẫn có thể được lưu nhưng dashboard cần phân biệt.

Không nên trộn customer allegation với confirmed factory defect.

13. Unknown là mã hợp lệ

Ép người nhập chọn một mã sai chỉ để form complete làm data xấu hơn.

Cho phép UNKNOWN_PENDING_REVIEW hoặc OTHER_WITH_NOTE nhưng theo dõi tỷ lệ dùng.

Nếu OTHER quá cao, taxonomy cần cải tiến hoặc training.

14. Multi-defect complaint

Một complaint có thể có nhiều lỗi: tangling và label sai.

Data model nên cho multiple defect records dưới một complaint ID thay vì chọn một mã duy nhất.

Mỗi defect có severity/status riêng. Complaint count và defect count vì thế khác nhau.

15. Defect location

Location là dimension hữu ích: - front; - temple; - crown; - nape; - full length; - packaging; - not applicable.

Ví dụ shedding tại nape và shedding toàn đầu có pattern khác.

Không cần nhân số code bằng cách tạo mã riêng theo từng location nếu field location làm được.

16. Timing và use stage

Ghi khi issue được thấy: - upon opening; - first wear; - after wash; - after styling; - after một số ngày hoặc tuần; - unknown.

Timing giúp investigation nhưng không tự xác định cause.

Một complaint after wash cần hỏi routine, product, heat và attachment context.

17. Product attributes

Trend nên có SKU/model, color, length, density, base, production lot và supplier/material lot khi có.

Nếu defect code tốt nhưng lot missing, root-cause vẫn khó.

Complaint intake cần capture serial, lot hoặc order nếu customer có.

18. Taxonomy hierarchy

Ví dụ: - H — Hair - H01 Shedding - H02 Tangling - H03 Breakage - B — Base - B01 Lace tear - B02 Seam - I — Identity - I01 Wrong label - I02 Wrong barcode

Code ngắn nhưng label và definition mới là quan trọng.

Không encode quá nhiều meaning vào chuỗi dài.

19. Definition sheet

Mỗi code cần name, definition, include, exclude, example, required evidence, allowed status và owner.

Ví dụ H01 Shedding: sợi rời khỏi attachment/base; exclude breakage giữa thân sợi nếu đó là H03.

Definition giảm coder variation.

20. Training người nhập complaint

Customer service không cần trở thành QC nhưng cần biết câu hỏi chuẩn và code level intake.

Có thể intake ở family level, sau đó QA recode sau review evidence.

Không bắt CS kết luận kỹ thuật quá sâu. Role-based coding tốt hơn một form khổng lồ.

21. Photo và evidence link

Nếu complaint có ảnh, link image ID vào defect record.

Image cần privacy và commercial handling phù hợp.

QA có thể dùng evidence để verify hoặc reclassify.

Không lưu ảnh rời không biết complaint ID.

22. Reclassification có audit trail

Khi QA đổi từ OTHER sang H01 Shedding, giữ history gồm old code, new code, reason, user và timestamp.

Data trend dùng current verified code nhưng investigation có thể xem history.

Không overwrite âm thầm.

23. Pareto complaint

Khi coding ổn, Pareto có thể theo defect family, verified defect, model, lot, time, market/customer và severity.

Nhưng luôn xem denominator. 20 complaints trên 100 units khác 20 trên 10.000.

Complaint rate cần shipment hoặc sales volume phù hợp.

24. Trigger CAPA

Không phải complaint nào cũng mở CAPA. Trigger có thể dựa trên critical severity, repeat verified defect, threshold rate, same lot cluster, trend tăng hoặc customer requirement.

Taxonomy giúp trigger nhất quán.

Nhưng CAPA decision vẫn cần risk judgement.

25. Complaint cluster

Nếu nhiều complaints cùng defect code, model và lot trong thời gian ngắn, hệ thống có thể alert.

Cluster giúp containment sớm.

Đừng đợi monthly Pareto nếu severity cao.

26. Cause taxonomy sau investigation

Cause code có thể theo material, method/process, training, equipment/tool, measurement, packaging/logistics, use condition, no fault found và unknown.

Nhưng chỉ gán khi evidence đủ.

Defect và cause không nên dùng chung taxonomy.

27. Corrective action link

Complaint defect record có thể link NCR, CAPA hoặc 8D.

Sau action, theo defect rate để verify effectiveness.

Nếu code đổi taxonomy, cần mapping cũ-mới để trend không đứt.

28. Version control taxonomy

Taxonomy cũng là controlled master data.

Khi thêm, merge hoặc retire code cần effective date, mapping, training, dashboard update và historical handling.

Không rename code cũ theo cách làm history mất nghĩa.

29. Multilingual coding

Label có thể hiển thị Việt, Anh, Trung hoặc Hàn nhưng code ID nên ổn định.

Translation phải giữ same definition.

Nếu locale tạo code riêng, data khó merge.

30. Ví dụ giả định

Trong tháng có 18 complaint được gắn family HAIR. Sau QA, 12 verified H01 Shedding, 3 H02 Tangling, 1 H03 Breakage và 2 unverified.

12 H01 tập trung 9 ở cùng model và 7 cùng production lot. Alert cluster mở containment và investigation.

Nếu trước đó tất cả chỉ ghi “quality issue”, pattern này không hiện.

31. Kiểm chất lượng coding

Định kỳ chọn sample complaint, cho hai reviewers code độc lập.

Đo agreement. Nếu thấp, definition cần cải thiện.

Audit tỷ lệ OTHER, UNKNOWN và reclassification.

Taxonomy tốt phải usable, không chỉ logic trên giấy.

32. Data governance cho dashboard

Dashboard nên công bố rõ đang đếm complaint, defect records hay verified defects. Nếu một complaint có ba defect, số liệu có thể khác rất nhiều.

Bộ lọc mặc định cũng cần rõ: verified only hay gồm customer-reported. Không nên để hai team cùng dùng chữ “complaint rate” nhưng denominator hoặc status khác nhau.

Khi export data cho buyer review, giữ version taxonomy và time snapshot để tháng sau có thể tái dựng con số.

33. Mapping complaint sang process owner

Mỗi defect family nên có default triage owner: hair process, base, packaging, logistics hoặc commercial. Đây không phải kết luận root cause; nó chỉ xác định ai lead review ban đầu.

Nếu investigation cho thấy defect thuộc upstream khác, owner có thể chuyển với audit trail.

Mapping owner giúp complaint không nằm chờ vì “không biết gửi ai”.

34. Những lỗi thường gặp

- Một code “Quality”. - Defect và cause trộn. - Không có unknown. - Mỗi location thành code riêng. - Severity nhúng vào name. - Customer report coi như verified. - Multi-defect chỉ chọn một. - Không capture lot. - Reclassify không history. - Taxonomy đổi không mapping. - Dashboard không rõ denominator. - Không có triage owner.

35. Checklist xây defect code

1. Family. 2. Subcode. 3. Definition. 4. Include/exclude. 5. Example. 6. Location field. 7. Severity field. 8. Verification status. 9. Evidence. 10. Product/lot. 11. Multi-defect support. 12. Audit trail. 13. Pareto denominator. 14. CAPA trigger. 15. Version control. 16. Triage owner.

Kết luận

Defect code tốt làm complaint data có thể hành động. Nó giữ nguyên lời khách, nhưng thêm family, defect, location, severity và verification status đủ để trend.

Khi defect tách khỏi cause, unknown được cho phép, reclassification có history và taxonomy được version control, Pareto và CAPA sẽ dựa trên dữ liệu sạch hơn. Mục tiêu không phải tạo nhiều mã, mà tạo đúng mức chi tiết để thấy pattern và ưu tiên rủi ro.