Automation fail: Những lần tôi chi tiền triệu xây AI mà khách muốn... xóa đi
- Bài toán: Tác giả từng chi tiền triệu xây automation nhưng khách muốn xóa đi vì nó gây bực bội thay vì giúp ích.
- Giải pháp: Mổ xẻ 4 sai lầm thật — quên con người, không đo giá trị, bỏ qua change management, thiếu phương án dự phòng.
- Kết quả: Automation thành công cần được xem là partnership dài hạn, không phải "bắn một phát là xong".
Automation fail: Những lần tôi chi tiền triệu xây AI mà khách muốn... xóa đi
Hôm nay tôi sẽ kể những lần "tự bắn vào chân" của mình — những dự án automation mà tôi nghĩ là "phát minh ra bánh xe" nhưng kết quả khách gọi: "Châu ơi, bỏ cái này đi, nó tệ hơn làm tay."
Những câu chuyện này có thể làm bạn cười, nhưng nó đắt giá lắm. Mong nó giúp bạn tránh những lỗi tương tự.
TL;DR (Executive Summary)
- Bài toán: Tác giả từng chi tiền triệu xây automation nhưng khách muốn xóa đi vì nó gây bực bội thay vì giúp ích.
- Giải pháp: Mổ xẻ 4 sai lầm thật — quên con người, không đo giá trị, bỏ qua change management, thiếu phương án dự phòng.
- Kết quả: Automation thành công cần được xem là partnership dài hạn, không phải "bắn một phát là xong".
Sai lầm #1: "Automation mà quên mất người" — Lần đầu tôi làm document processing
Năm 2019, tôi tham gia dự án cho một công ty bảo hiểm nhỏ. Khách say: "Châu ơi, mỗi ngày nhân viên phải gõ tay hóa đơn khách từ giấy vào máy, mệt lắm. Làm cái gì tự động được không?"
Tôi hăng hái: "Vâng ơi! Tôi sẽ xây OCR, tự động nhận diện hóa đơn, tự động điền vào database. Không cần gõ tay nữa!"
Kết quả?
Hệ thống tôi xây đúng kỹ thuật, OCR chạy chuẩn 99%... nhưng khi triển khai, nhân viên phản ứng: "Phần mềm nó mới tốt, chứ để lại những chỗ sai sót để chúng tôi fix. Giờ chúng tôi phải check lại tất cả, mệt hơn lúc trước!"
Lỗi của tôi:
- ❌ Tôi chỉ tối ưu hóa độ chính xác của AI (99%)
- ❌ Tôi không hỏi: "Khi AI sai, quy trình fix như thế nào?"
- ❌ Tôi không design UX cho những lỗi sai, chỉ design cho "happy path"
Cách tôi fix:
Tôi quay lại, dành 2 tuần hỏi chi tiết:
- "Khi hóa đơn mà OCR không đọc được, bạn làm gì?"
- "Lỗi sai phổ biến nhất là gì?"
- "Nếu AI 95% chính xác thì bạn còn phải fix 5% kia, mất bao lâu?"
Kết quả tôi thiết kế lại UX:
- AI gợi ý thông tin, nhân viên chỉ cần confirm (chứ không gõ lại)
- Nếu AI không chắc, nó sẽ highlight để nhân viên review tập trung
- Tạo "fast-track" cho hóa đơn chuẩn, "slow-track" cho hóa đơn lạ
Lần này, nhân viên hạnh phúc lắm: "Châu ơi, nó giúp việc nhiều đấy!" — và công ty tiết kiệm được 30% thời gian. Không phải 100% automation, mà là "smart assistance".
Sai lầm #2: "Automation mà không đo lường giá trị" — Lần tôi xây email bot vô dụng
Một khách bảo: "Châu ơi, khách hàng của mình gửi email hỏi tương tự nhau. Mình có thể dùng AI để reply tự động không?"
Tôi lại hăng hái: "Tuyệt! Tôi sẽ dùng LLM, train nó trên các email cũ, nó sẽ reply tự động."
Kết quả?
Xây xong, deploy lên... 2 tuần sau khách bảo bỏ cái bọn nó.
Lỗi của tôi:
- ❌ Tôi không hỏi: "Bao nhiêu % email là có thể reply tự động?"
- ❌ Tôi không đo: "Bao nhiêu email bot reply sai mà khách phải fix thủ công?"
- ❌ Tôi chỉ focus vào "nó chạy được", không focus vào "nó tạo ra giá trị gì?"
Sự thật: Trong 100 email, chỉ có ~20% là chuẩn, có thể reply tự động. 80% còn lại là edge case — bot reply sai, khách phải fix, thay vì tiết kiệm, nó lại tốn thêm công.
Cách tôi fix:
Trước khi xây automation gì, tôi sẽ hỏi 3 câu:
- "Bao nhiêu % case bạn muốn automation hỗ trợ?" (Không phải 100%, mà realistic 40-60%)
- "Nếu AI sai, cost để fix thủ công bao nhiêu so với lợi ích tiết kiệm?" (phải dương)
- "Làm sao đo được automation này thực sự giúp được giảm công việc?" (baseline + after metrics)
Lần sau, khách khác hỏi tương tự, tôi trả lời: "Mình chỉ làm automation cho 30% email pattern phổ biến. 70% còn lại, AI sẽ giúp nhân viên sắp xếp ưu tiên + suggest draft, họ chỉ cần fix 1-2 chỗ rồi gửi."
Kết quả: Nhân viên vui, khách vui, tôi cũng vui 🎉
Sai lầm #3: "Change management? Không cần!" — Lần tôi deploy automation mà khách ngán
Có một lần, tôi implement chatbot tư vấn sản phẩm tự động. Code chạy chuẩn, chatbot trả lời customer tốt. Tôi tự hào: "Bàn giao xong, bạn sử dụng ngay được!"
Kết quả?
1 tháng sau, cô quản lý team support gọi: "Châu ơi, team chúng tôi bảo cái chatbot này nó che mất cơ hội tương tác với khách. Bây giờ khách toàn hỏi chatbot, ít nhắn cho chúng tôi nên không hiểu khách cần gì. Tắt nó đi."
Lỗi của tôi:
- ❌ Tôi chỉ code + deploy, không train team sử dụng nó
- ❌ Tôi không hỏi: "Support team sẽ cảm thấy như thế nào khi chatbot "lấy" việc của họ?"
- ❌ Tôi không có plan để change management — làm sao team accept công nghệ mới
Cách tôi fix:
Trước khi deploy automation, tôi sẽ:
Workshop với team: "Cái này không phải để thay bạn, mà để giải phóng bạn khỏi việc lặp lại. Bạn sẽ có thời gian handle khách VIP hơn."
Pilot ngầm: Deploy cho 20% khách, measure kết quả thực tế trước khi rollout full.
Feedback loop: Hỏi team: "Cái này giúp bạn không? Điểm nào cần sửa?" và actually fix it, chứ không coi như "training problem".
Lần sau, khi tôi deploy chatbot khác, tôi invite support team tham gia thiết kế từ đầu. Kết quả, họ chủ động promote: "Anh chị các bạn, chat với bot trước nếu cấp tính. Muốn nói chuyện với tôi thì để lại số điện thoại." — Chatbot trở thành asset, không phải threat.
Sai lầm #4: "Automation mà không có contingency plan" — Lần system down và bóng đè
Tôi xây một hệ thống OCR xử lý hợp đồng tự động. System chạy 99.9% thời gian... nhưng có một ngày, server bị down 4 tiếng.
Kết quả?
Khách tích tụ 500+ hợp đồng không được xử lý, deadline bị vỡ, khách gọi tôi ra mắt lên: "Tại sao bạn không cảnh báo cho tôi? Bây giờ phải gọi 50 người ngồi xử lý thủ công!"
Lỗi của tôi:
- ❌ Tôi focus vào uptime 99.9%, quên rằng 1 lần down = catastrophic
- ❌ Tôi không có fallback process — khi hệ thống down, làm sao xử lý?
- ❌ Tôi không có alert system — khách không biết system down khi nào
Cách tôi fix:
Mỗi automation project sau đó, tôi sẽ plan:
Fallback process: "Nếu system down, bạn sẽ làm gì?" — document rõ ràng
Alert system: Khi OCR fail, system sẽ tự động email alert cho team, không chờ khách phát hiện
Batch processing: Thay vì process realtime, tôi design nó process batch buổi sáng buổi chiều, có buffer time để fix nếu có lỗi
Manual override: Team có thể force-process hợp đồng thủ công nếu cần gấp (contingency)
Kết quả: Khách yên tâm, automation vẫn chạy, nhưng nếu lỗi thì có "plan B".
Bài học lớn nhất: Automation không phải "bắn phát là hạ", mà là "partnership"
Sau 15+ lần implement, tôi nhận ra:
Automation thất bại không phải vì AI kém, mà vì tôi quên mất nó phải serve con người.
Những project thành công:
- ✅ Tôi hỏi kỹ trước khi code (pain point thực tế là gì?)
- ✅ Tôi đo lường kết quả (giảm công việc bao nhiêu % thực tế?)
- ✅ Tôi involve team (họ cảm thấy có quyền nói)
- ✅ Tôi plan contingency (khi fail thì làm gì?)
Những project thất bại:
- ❌ Tôi code trước, hỏi sau
- ❌ Tôi focus vào "AI chạy đúng", không focus vào "nó tạo ra giá trị gì"
- ❌ Tôi assume team sẽ thích công nghệ mới (ai cũng sợ mất việc)
- ❌ Tôi quên mất contingency, khi lỗi thì khách "chịu đựng"
Lời khuyên cho bạn
Nếu bạn đang định implement automation (AI, chatbot, automation workflow, etc.), đừng vội code. Trước hết, hãy đọc AI cho SME: đừng để mất tiền vào chatbot giá rẻ để chọn đúng bài toán — và nếu gốc rễ vấn đề là quy trình thủ công rời rạc, thì cái cần xây trước có khi là một hệ thống nội bộ "Source of Truth" chứ chưa phải automation. Hãy hỏi:
- "Bạn chắc không phải chỉ muốn nó 'có', mà chắc muốn nó 'mang lại giá trị'?" → Measure trước/sau
- "Ai sẽ dùng nó mỗi ngày? Họ có hợp tác không?" → Involve them early
- "Khi nó sai, bạn sẽ làm gì?" → Plan fallback
- "ROI bạn expect là bao nhiêu?" → Cụ thể, không vague
Nếu bạn đang có automation project nhưng cảm thấy nó "awkward", cứ kết nối với tôi để cùng trao đổi. Tôi hay nghĩ về 3 câu hỏi này:
- Nó thực sự tạo ra giá trị không?
- Team buy-in được không?
- Cần pivot strategy gì?
Automation là công cụ tuyệt vời, nhưng nó chỉ tuyệt vời khi phục vụ con người, chứ không phải chỉ "chứng minh bạn giỏi tech" 😊
Nguyễn Phúc Nguyên Châu
Delivery Manager
14 năm kinh nghiệm Delivery (Website, Hệ thống, AI Automation) cho thị trường Việt - Nhật