Baseline là "ảnh chụp" hiện trạng trước khi agent xuất hiện. Không có baseline, mọi con số cải thiện sau này đều là phỏng đoán. Đây là bước bị bỏ qua nhiều nhất và cũng là lý do lớn nhất khiến ROI không thuyết phục.
Baseline gồm những gì
Một baseline tốt trả lời được: Ai làm việc này, mất bao lâu, tốn bao nhiêu, chất lượng ra sao, khối lượng bao nhiêu. Năm chiều đó phải có số, không chỉ mô tả.
| Chiều | Ví dụ chỉ số |
|---|---|
| Con người | 2 nhân viên, 0,5 FTE |
| Thời gian | 8 phút/ticket |
| Chi phí | 150.000đ/giờ nhân sự |
| Chất lượng | 6% ticket phải mở lại |
| Khối lượng | 1.200 ticket/tháng |
Ví dụ cụ thể: quy trình duyệt hoàn tiền
Trước khi làm agent, một fintech đo quy trình duyệt hoàn tiền thủ công trong 2 tuần:
- Trung bình 6 phút xử lý/yêu cầu.
- 900 yêu cầu/tháng.
- Tỷ lệ duyệt sai (phải thu hồi) 3%.
- Chi phí nhân sự quy đổi 140.000đ/giờ.
Các bước dựng baseline
- Chọn cửa sổ đo đủ dài để vượt biến động ngắn hạn — tối thiểu 2 tuần, lý tưởng 1 tháng.
- Đo bằng dữ liệu thật, không hỏi cảm tính. Log hệ thống, timestamp, bảng chấm công.
- Ghi cả chất lượng, không chỉ tốc độ. Tỷ lệ lỗi, tỷ lệ làm lại, mức hài lòng.
- Tách biến động mùa vụ. Nếu tháng đo là cao điểm, ghi chú để không so lệch.
- Lưu snapshot bất biến. Đóng băng con số baseline, sau này không sửa.
Đoạn ghi baseline dạng cấu trúc
baseline:
use_case: "Duyệt hoàn tiền"
window: "2026-05-01 -> 2026-05-31"
volume_per_month: 900
minutes_per_item: 6
labor_rate_vnd_per_hour: 140000
error_rate: 0.03
monthly_labor_cost_vnd: 12600000
frozen: true # không chỉnh sau khi chốt
Khung checklist baseline
- [ ] Có số volume theo tháng?
- [ ] Có thời gian trung bình mỗi đơn vị công việc?
- [ ] Có đơn giá lao động quy đổi?
- [ ] Có ít nhất một chỉ số chất lượng?
- [ ] Cửa sổ đo ≥ 2 tuần và đại diện?
- [ ] Snapshot đã được đóng băng và lưu lại?
Vì sao đóng băng baseline lại quan trọng
Khi agent chạy tốt, người ta có xu hướng "nhớ lại" quy trình cũ tệ hơn thực tế để ROI đẹp hơn. Baseline đóng băng chống lại thiên kiến này. Nó cũng giúp bạn phân biệt cải thiện do agent với cải thiện do đội ngũ tự tối ưu quy trình cùng lúc.
Sai lầm thường gặp
- Ước lượng baseline sau khi đã có agent. Ký ức không đáng tin; số liệu sẽ bị bẻ cong.
- Chỉ đo tốc độ, bỏ chất lượng. Agent nhanh hơn nhưng sai nhiều hơn thì baseline một chiều sẽ giấu điều đó.
- Đo trong tuần bất thường (Tết, sự cố hệ thống) rồi coi là bình thường.
- Trộn nhiều quy trình vào một baseline, khiến không quy được cải thiện về đúng nguyên nhân.
Xử lý khi không có dữ liệu sạch sẵn có
Thực tế nhiều đội không log gì trước đó. Đừng vì thế bỏ baseline. Ba cách lấy số nhanh mà vẫn đáng tin:
- Time-and-motion study: ngồi bấm giờ 20–30 ca thực tế, lấy trung vị (median) thay vì trung bình để tránh ca cá biệt kéo lệch.
- Đối chiếu chéo: hỏi 3 nhân sự độc lập ước lượng, nếu lệch quá 30% thì phải đo lại bằng bấm giờ.
- Lấy mẫu log gián tiếp: dùng timestamp mở/đóng ticket, thời gian giữa hai email, lịch sử chỉnh sửa tài liệu để suy ra thời lượng.
Baseline chất lượng, không chỉ tốc độ
Một cạm bẫy tinh vi: baseline chỉ ghi thời gian sẽ làm agent trông luôn thắng vì máy nhanh hơn người. Nhưng nếu quy trình cũ có tỷ lệ lỗi 2% còn agent 9%, phần chênh lỗi đó là chi phí thật phải trừ vào ROI. Vì vậy baseline BẮT BUỘC có ít nhất một chỉ số chất lượng đối xứng để so công bằng ở Bài 4.
Baseline vững là nền của toàn bộ phép tính ROI. Bài 3 sẽ đào sâu phần khó nhất: chi phí ẩn.