Cổng phê duyệt chỉ tốt bằng chất lượng quyết định của người duyệt. Nếu họ bị dội hàng trăm yêu cầu mơ hồ mỗi ngày, họ sẽ bấm "Duyệt" theo phản xạ — và gate của bạn trở thành sân khấu, không phải kiểm soát. Bài này bàn về con người trong vòng lặp.
Mệt mỏi phê duyệt (approval fatigue) là kẻ thù số một
Khi khối lượng duyệt quá lớn hoặc yêu cầu thiếu thông tin, não người chuyển sang chế độ tự động: duyệt tất. Đây là lý do nhiều hệ thống có gate vẫn xảy ra sự cố. Mục tiêu thiết kế: mỗi lần duyệt là một quyết định thật, mất ít công sức.
Hai đòn bẩy chính:
- Giảm số lượng yêu cầu tới người (chỉ thứ thực sự cần).
- Tăng chất lượng mỗi yêu cầu (đủ ngữ cảnh, gợi ý sẵn).
Giảm số lượng: lọc và gộp
- Auto-approve có điều kiện: hành động khớp mẫu an toàn đã lặp lại nhiều lần và từng được duyệt → hạ mức, cho tự động kèm audit.
- Gộp theo lô (batch): 20 hoàn tiền tương tự trình thành một màn duyệt lô với tùy chọn "Duyệt tất / Duyệt chọn lọc".
- Định tuyến theo chuyên môn: yêu cầu pháp lý tới bộ phận pháp chế, tài chính tới kế toán — đúng người quyết nhanh hơn.
Tăng chất lượng: khung một màn duyệt tốt
Mỗi màn duyệt nên trả lời bốn câu trong vài giây:
1. Agent muốn làm GÌ? -> "Hoàn 3.000.000đ cho đơn #4821"
2. VÌ SAO? -> lý do + bằng chứng (link ảnh/chat)
3. RỦI RO/hệ quả? -> "Không undo. Nếu sai, mất 3tr."
4. Gợi ý HÀNH ĐỘNG? -> "Đề xuất: Duyệt (khớp 47 ca tương tự)"
Cung cấp cả khuyến nghị của hệ thống kèm độ tin cậy giúp người duyệt nhanh, nhưng phải để họ dễ dàng không đồng ý — nếu không sẽ thành duyệt mù.
Ví dụ cụ thể: cấu hình định tuyến duyệt
approval_routing:
- match: { action: send_refund, amount: "<1000000" }
decision: auto # rủi ro thấp, bỏ qua người
- match: { action: send_refund, amount: "1000000..10000000" }
approvers: [cs_lead]
sla_minutes: 60
batchable: true
- match: { action: send_refund, amount: ">10000000" }
approvers: [cs_lead, finance] # cần cả hai
sla_minutes: 30
notify: [manager]
Cấu hình tách rời như thế này cho phép chỉnh ai duyệt cái gì mà không đụng code agent.
Các bước thiết kế trải nghiệm người duyệt
- Đo baseline: hiện mỗi người nhận bao nhiêu yêu cầu/ngày, tỉ lệ từ chối là bao nhiêu.
- Cắt bớt bằng auto-approve cho các mẫu an toàn đã được chứng minh.
- Thiết kế màn duyệt trả lời được 4 câu hỏi cốt lõi trong ~30 giây.
- Thêm khuyến nghị + độ tin cậy, nhưng đặt nút "Từ chối" ngang tầm nút "Duyệt".
- Định tuyến theo chuyên môn và SLA; gộp lô nơi hợp lý.
- Theo dõi chỉ số sức khỏe gate: thời gian duyệt trung bình, tỉ lệ từ chối, tỉ lệ duyệt-rồi-phải-undo.
- Điều chỉnh ngưỡng khi thấy quá tải hoặc để lọt.
Checklist chống approval fatigue
- [ ] Người duyệt nhận số lượng yêu cầu hợp lý (không phải hàng trăm/ngày)?
- [ ] Mỗi yêu cầu đủ ngữ cảnh để quyết trong 30 giây?
- [ ] Có khuyến nghị hệ thống nhưng dễ phản đối?
- [ ] Nút Từ chối không bị chôn dưới nút Duyệt?
- [ ] Có đo tỉ lệ "duyệt rồi phải undo" để phát hiện duyệt mù?
Sai lầm thường gặp
- Đưa mọi thứ cho một người. Không phân tuyến khiến một người thành nút thắt cổ chai và kiệt sức.
- Nút Duyệt to đẹp, nút Từ chối bé xíu. Thiết kế thiên vị dẫn tới duyệt theo quán tính.
- Khuyến nghị hệ thống trình bày như "chân lý". Người duyệt ngừng suy nghĩ, gate thành hình thức.
- Không đo sức khỏe gate. Nếu không theo dõi tỉ lệ từ chối và undo, bạn không biết gate còn tác dụng hay đã thành nghi thức.
- Quên SLA. Yêu cầu treo quá lâu làm hỏng trải nghiệm khách và tạo áp lực duyệt vội.