Một yêu cầu của khách hàng đến qua email.
Nhân viên đọc nội dung, mở CRM để kiểm tra thông tin khách hàng, tìm một file Excel để đối chiếu dữ liệu, vào hệ thống nội bộ để kiểm tra trạng thái, tìm thêm tài liệu liên quan, sau đó quay lại email để trả lời.
Cuối cùng, nhân viên lại mở CRM để cập nhật kết quả xử lý.
Không có bước nào trong quy trình này đặc biệt khó.
Nhưng nếu nó diễn ra hàng chục hoặc hàng trăm lần mỗi tuần, doanh nghiệp đang sử dụng một lượng đáng kể thời gian của nhân viên cho một công việc ít được nhìn thấy:
chuyển thông tin thủ công giữa các hệ thống.
Đây là một trong những bài toán đáng quan tâm khi doanh nghiệp tìm kiếm cơ hội tự động hóa.
Tuy nhiên, điều đó không có nghĩa giải pháp mặc định phải là AI Agent.
Một số bước chỉ cần API.
Một số bước phù hợp với workflow automation.
Một số hệ thống cũ có thể cần RPA.
Và chỉ một số bước thực sự cần khả năng xử lý ngôn ngữ, tài liệu hoặc ngữ cảnh của AI.
Vì vậy, câu hỏi quan trọng không phải:
“Có thể dùng AI Agent để tự động hóa quy trình này không?”
Mà là:
“Trong toàn bộ quy trình này, bước nào thực sự cần AI và bước nào nên được giải quyết theo cách đơn giản hơn?”
Khi con người trở thành “API” giữa các hệ thống
Hãy xem một ví dụ đơn giản.
Bộ phận kinh doanh nhận được email:
Khách hàng muốn biết tình trạng xử lý của yêu cầu đã gửi tuần trước và hỏi thêm liệu có thể thay đổi một số nội dung trước khi tiếp tục hay không.
Để trả lời, nhân viên có thể phải:
đọc email;
xác định khách hàng;
tìm lịch sử trao đổi;
mở CRM;
kiểm tra trạng thái;
tìm thông tin trong một file Excel;
tra cứu quy định hoặc tài liệu liên quan;
trao đổi với bộ phận phụ trách;
chuẩn bị câu trả lời;
gửi email;
cập nhật CRM.
Nhìn riêng từng bước, đây không phải một workflow phức tạp.
Nhưng hãy thử nhân nó với 50, 100 hoặc 500 yêu cầu.
Lúc đó, một phần đáng kể thời gian làm việc không được dành cho việc đưa ra quyết định hay giải quyết vấn đề khó.
Nó được dành cho:
mở → tìm → copy → kiểm tra → chuyển → nhập → cập nhật.
Nói cách khác, nhân viên đang làm nhiệm vụ mà lẽ ra các hệ thống nên hỗ trợ tốt hơn.
Con người đang trở thành lớp tích hợp thủ công giữa các phần mềm.
Đây thường là một tín hiệu đáng để doanh nghiệp phân tích workflow.
Vấn đề không nằm ở việc doanh nghiệp đang sử dụng nhiều phần mềm
Một phản ứng dễ hiểu là:
“Có quá nhiều hệ thống. Chúng ta cần gom tất cả vào một hệ thống.”
Nhưng điều này không phải lúc nào cũng khả thi hoặc cần thiết.
CRM có nhiệm vụ của CRM.
ERP có nhiệm vụ của ERP.
Email vẫn cần thiết.
Excel vẫn hữu ích cho nhiều loại công việc.
Các SaaS chuyên biệt tồn tại vì chúng giải quyết những nghiệp vụ khác nhau.
Do đó, mục tiêu không nhất thiết là loại bỏ tất cả các công cụ để xây một hệ thống duy nhất.
Vấn đề thực sự xuất hiện khi con người phải chịu trách nhiệm kết nối những hệ thống đó bằng thao tác thủ công.
Ví dụ:
Hệ thống A đã có thông tin khách hàng.
Nhưng nhân viên phải copy thông tin đó sang Excel.
Sau đó lại lấy dữ liệu từ Excel để nhập vào hệ thống B.
Cuối ngày, một người khác lấy dữ liệu từ hệ thống B để tạo báo cáo.
Nếu các bước này hoàn toàn dựa trên quy tắc cố định, đây trước hết là bài toán integration hoặc workflow automation.
Chưa cần AI.
Trước khi nói về AI, hãy vẽ lại workflow hiện tại
Một trong những việc hữu ích nhất doanh nghiệp có thể làm là chọn một công việc cụ thể và vẽ lại cách nó thực sự được hoàn thành.
Không cần bắt đầu bằng một sơ đồ kỹ thuật phức tạp.
Chỉ cần trả lời:
Trigger là gì?
Công việc bắt đầu từ đâu?
Một email?
Một form?
Một đơn hàng?
Một yêu cầu nội bộ?
Một lịch họp?
Tiếp theo:
Nhân viên phải mở những hệ thống nào?
Email?
CRM?
Excel?
ERP?
Database?
Google Drive?
SharePoint?
Phần mềm nội bộ?
Sau đó:
Ở mỗi bước, nhân viên thực sự làm gì?
Đọc?
Tìm kiếm?
Copy dữ liệu?
So sánh?
Tính toán?
Phân loại?
Ra quyết định?
Xin phê duyệt?
Gửi thông tin?
Cuối cùng:
Output của quy trình là gì?
Một email?
Một báo cáo?
Một cập nhật CRM?
Một quyết định?
Một hồ sơ hoàn chỉnh?
Khi workflow được nhìn thấy rõ ràng, doanh nghiệp thường phát hiện rằng không phải toàn bộ quy trình đều cần cùng một công nghệ.
Bước nào chỉ cần API?
Giả sử nhân viên đang thực hiện:
CRM → lấy mã khách hàng → nhập mã đó vào hệ thống khác → lấy trạng thái đơn hàng.
Nếu cả hai hệ thống đều cung cấp API phù hợp, AI có thể hoàn toàn không cần thiết.
Hệ thống có thể tự động gửi và nhận dữ liệu theo logic xác định trước.
API đặc biệt phù hợp khi:
dữ liệu có cấu trúc;
nguồn và đích rõ ràng;
logic ổn định;
không cần hiểu ngôn ngữ tự nhiên;
không cần suy luận dựa trên ngữ cảnh.
Ví dụ:
Khi đơn hàng được tạo → cập nhật CRM.
Khi thanh toán hoàn tất → thay đổi trạng thái.
Khi có khách hàng mới → tạo record ở hệ thống liên quan.
Khi trường dữ liệu A thay đổi → đồng bộ sang hệ thống B.
Đây là những công việc máy tính truyền thống đã có thể xử lý rất tốt.
Đưa AI vào chỉ làm kiến trúc phức tạp hơn mà chưa chắc tạo thêm giá trị.
Bước nào phù hợp với Workflow Automation?
Có những quy trình không chỉ chuyển dữ liệu mà gồm nhiều bước cố định.
Ví dụ:
Nhận form
→ kiểm tra trường bắt buộc
→ tạo record
→ gửi thông báo
→ yêu cầu phê duyệt
→ cập nhật trạng thái
→ gửi email xác nhận.
Nếu logic có thể mô tả rõ bằng các điều kiện như:
Nếu A → làm B.
Nếu C → làm D.
workflow automation thường là lựa chọn tự nhiên.
Nó dễ kiểm soát.
Kết quả có tính xác định cao.
Và doanh nghiệp có thể biết tương đối rõ hệ thống sẽ làm gì trong từng trường hợp.
AI Agent không nên thay thế loại automation này chỉ vì Agent là công nghệ mới hơn.
Khi nào RPA vẫn có giá trị?
Không phải hệ thống doanh nghiệp nào cũng có API.
Đặc biệt với các hệ thống cũ, phần mềm desktop hoặc một số ứng dụng nội bộ, cách duy nhất để thao tác có thể vẫn là thông qua giao diện người dùng.
Ví dụ, nhân viên phải:
mở phần mềm;
đăng nhập;
chọn menu;
nhập mã;
copy kết quả;
đóng cửa sổ.
Nếu thao tác có tính lặp lại cao và giao diện tương đối ổn định, RPA có thể là một lựa chọn.
Điểm cần lưu ý là RPA thường phụ thuộc vào giao diện. Khi giao diện thay đổi, automation có thể cần được điều chỉnh.
Do đó, nếu API hoặc phương thức integration ổn định tồn tại, doanh nghiệp thường nên đánh giá chúng trước.
Nhưng với legacy system, RPA vẫn có thể đóng vai trò thực tế.
Một lần nữa, không phải mọi bài toán tự động hóa đều cần AI.
Vậy AI bắt đầu tạo ra khác biệt ở đâu?
Hãy quay lại email khách hàng.
Một API có thể lấy dữ liệu từ CRM.
Nhưng trước khi lấy dữ liệu, hệ thống cần hiểu:
Khách hàng đang hỏi điều gì?
Đây là lúc bài toán thay đổi.
Email không phải một bảng dữ liệu có cấu trúc cố định.
Một khách hàng có thể viết:
“Cho tôi kiểm tra đơn hàng.”
Người khác viết:
“Hàng bên tôi đặt tuần trước vẫn chưa thấy thông báo, nhờ kiểm tra giúp.”
Người khác nữa có thể gửi một email dài với nhiều câu hỏi khác nhau.
Ý định tương tự nhưng cách diễn đạt khác nhau.
Đây là nơi AI có thể bổ sung khả năng mà automation truyền thống khó xử lý linh hoạt:
hiểu ngôn ngữ;
phân loại nội dung;
trích xuất thông tin;
đọc tài liệu;
tóm tắt;
tìm kiếm theo ngữ nghĩa;
tổng hợp nhiều nguồn;
đánh giá ngữ cảnh;
chuẩn bị nội dung bằng ngôn ngữ tự nhiên.
AI đặc biệt hữu ích khi input không còn là:
Field A = X
mà là:
“Hãy hiểu người này đang muốn gì.”
Một workflow thực tế có thể kết hợp nhiều công nghệ
Giả sử doanh nghiệp muốn cải thiện quy trình xử lý email yêu cầu của khách hàng.
Thay vì xây một Agent chịu trách nhiệm tất cả mọi thứ, workflow có thể được thiết kế như sau.
Bước 1 — Email đến
AI đọc nội dung và xác định loại yêu cầu.
Bước 2 — Xác định khách hàng
Hệ thống sử dụng thông tin từ email để tìm customer record.
Bước 3 — Lấy dữ liệu
API truy vấn CRM hoặc hệ thống liên quan.
Bước 4 — Kiểm tra business rule
Logic truyền thống kiểm tra trạng thái, điều kiện hoặc quyền hạn.
Bước 5 — Tìm tài liệu
Nếu cần, AI tìm thông tin liên quan từ knowledge base.
Bước 6 — Tổng hợp
AI chuẩn bị câu trả lời dựa trên dữ liệu đã được cung cấp.
Bước 7 — Kiểm soát
Nếu thuộc nhóm thông thường và rủi ro thấp, hệ thống có thể xử lý theo policy.
Nếu có ngoại lệ hoặc tác động quan trọng, chuyển cho nhân viên.
Bước 8 — Cập nhật
API ghi lại kết quả vào CRM.
Như vậy, AI không phải toàn bộ hệ thống.
AI đảm nhận những bước mà khả năng xử lý ngôn ngữ và ngữ cảnh tạo ra giá trị.
Những bước có thể xử lý chính xác bằng logic truyền thống vẫn được giao cho logic truyền thống.
Đây thường là kiến trúc thực tế hơn.
AI Agent nằm ở đâu trong workflow này?
Khi một workflow có nhiều bước và hệ thống cần lựa chọn công cụ hoặc hành động dựa trên ngữ cảnh, AI Agent bắt đầu trở nên đáng xem xét.
Ví dụ, sau khi đọc email, Agent có thể cần xác định:
Yêu cầu này có cần truy vấn CRM không?
Có cần tìm tài liệu không?
Có cần kiểm tra hệ thống đơn hàng không?
Có đủ dữ liệu để trả lời chưa?
Có cần yêu cầu thêm thông tin không?
Có phải trường hợp cần chuyển cho con người không?
Agent có thể đóng vai trò điều phối một số hành động dựa trên thông tin hiện có.
Nhưng điều này không có nghĩa Agent phải được quyền làm mọi thứ.
Trong môi trường doanh nghiệp, quyền của Agent nên được thiết kế theo phạm vi rõ ràng.
Đọc dữ liệu và thay đổi dữ liệu là hai mức quyền rất khác nhau.
Chuẩn bị email và tự động gửi email cũng khác nhau.
Đề xuất điều chỉnh giá và tự thay đổi giá lại càng khác.
Mức độ tự động hóa phải tương xứng với rủi ro.
Một cách đơn giản để phân loại từng bước trong workflow
Khi phân tích một quy trình, doanh nghiệp có thể chia các bước thành bốn nhóm.
Nhóm 1: Move
Các bước chủ yếu chuyển dữ liệu.
Ví dụ:
lấy dữ liệu từ A;
ghi sang B;
đồng bộ record;
tạo thông báo.
Ưu tiên xem xét API hoặc workflow automation.
Nhóm 2: Read
Các bước cần hiểu dữ liệu phi cấu trúc.
Ví dụ:
đọc email;
đọc tài liệu;
phân loại yêu cầu;
trích xuất nội dung.
Đây là khu vực AI có thể tạo giá trị.
Nhóm 3: Think
Các bước cần tổng hợp thông tin hoặc lựa chọn dựa trên context.
Ví dụ:
xác định thông tin nào liên quan;
so sánh nhiều nguồn;
đề xuất bước tiếp theo;
chuẩn bị phương án xử lý.
AI hoặc AI Agent có thể phù hợp, nhưng cần guardrail rõ ràng.
Nhóm 4: Decide / Act
Các bước tạo ra hành động có tác động.
Ví dụ:
gửi thông tin cho khách hàng;
cập nhật record;
phê duyệt;
thay đổi giá;
thực hiện giao dịch.
Ở đây cần xác định rõ:
AI được phép tự làm hay phải có Human-in-the-loop?
Framework này giúp tránh việc nhìn toàn bộ workflow như một khối duy nhất.
Đừng tự động hóa một quy trình chỉ vì nhân viên đang phàn nàn về nó
Có một giả định cần kiểm tra trước khi đầu tư.
Một công việc nhiều thao tác chưa chắc vấn đề nằm ở automation.
Ví dụ, nhân viên phải nhập cùng một thông tin vào ba hệ thống.
Có hai cách nhìn.
Cách thứ nhất:
“Hãy xây automation nhập cả ba hệ thống.”
Cách thứ hai:
“Tại sao cùng một dữ liệu phải được lưu ở ba nơi?”
Nếu nguyên nhân là kiến trúc hệ thống không hợp lý, automation chỉ xử lý phần biểu hiện.
Hoặc một báo cáo phải đi qua năm bước phê duyệt.
Thay vì hỏi:
“Có thể tự động hóa năm bước này không?”
nên hỏi trước:
“Có thực sự cần năm bước không?”
Đây là lý do process redesign nên xuất hiện trước hoặc song song với automation.
Nếu không, doanh nghiệp có nguy cơ:
tự động hóa một quy trình vốn không nên tồn tại theo cách hiện tại.
Excel không phải lúc nào cũng là vấn đề cần loại bỏ
Excel thường bị xem là dấu hiệu của hệ thống cũ hoặc vận hành thủ công.
Cách nhìn này quá đơn giản.
Excel vẫn rất hữu ích khi cần phân tích linh hoạt, xử lý dữ liệu ad hoc hoặc làm việc với những nhu cầu thay đổi thường xuyên.
Vấn đề không phải:
“Doanh nghiệp vẫn đang dùng Excel.”
Mà là:
“Excel đang đóng vai trò gì trong workflow?”
Nếu nhân viên dùng Excel để phân tích dữ liệu theo nhu cầu, đó có thể hoàn toàn hợp lý.
Nhưng nếu Excel trở thành database trung gian bắt buộc giữa CRM và ERP, hoặc nhiều người copy cùng một dữ liệu vào nhiều file khác nhau, doanh nghiệp nên xem lại kiến trúc quy trình.
Tương tự với email.
Email không phải vấn đề.
Nhưng nếu email là nơi duy nhất lưu trạng thái của một quy trình quan trọng, rủi ro vận hành sẽ tăng lên.
Tự động hóa tốt không nhất thiết phải loại bỏ mọi thao tác của con người
Giả sử hiện tại một yêu cầu cần 12 thao tác thủ công.
Doanh nghiệp triển khai automation và giảm còn 3 thao tác.
Ba thao tác còn lại là:
kiểm tra trường hợp bất thường;
phê duyệt;
trao đổi trực tiếp với khách hàng.
Đây có thể đã là một kết quả rất tốt.
Không cần cố giảm từ 3 xuống 0 chỉ để đạt “100% automation”.
Thực tế, chi phí và rủi ro của những phần trăm automation cuối cùng có thể cao hơn đáng kể giá trị mà chúng mang lại.
Do đó, mục tiêu nên là:
giảm những thao tác không tạo giá trị và giữ con người ở những điểm cần judgment.
Đây cũng là nguyên tắc quan trọng khi triển khai AI Agent.
Human-in-the-loop nên được thiết kế ngay từ đầu
Nếu Agent tham gia vào workflow, câu hỏi về con người không nên được để đến cuối dự án.
Ngay từ khi thiết kế cần xác định:
Agent được tự động thực hiện bước nào?
Bước nào cần phê duyệt?
Khi thiếu thông tin thì chuyển cho ai?
Khi confidence thấp thì làm gì?
Nếu có exception thì quy trình fallback ra sao?
Ai chịu trách nhiệm với output cuối cùng?
Ví dụ, trong Sales:
Agent có thể tự động tổng hợp customer history.
Có thể tạo meeting brief.
Có thể đề xuất follow-up email.
Nhưng thay đổi điều khoản thương mại có thể vẫn cần Sales Manager.
Trong Customer Service:
Agent có thể xử lý những câu hỏi thông thường.
Nhưng khiếu nại phức tạp hoặc trường hợp có rủi ro cao có thể cần con người.
Thiết kế tốt không phải là trao quyền tối đa cho Agent.
Thiết kế tốt là trao đúng quyền cho đúng loại công việc.
Làm sao biết một workflow có đáng để tự động hóa?
Sau khi mapping workflow, doanh nghiệp không nên chỉ hỏi:
“Có làm được không?”
Cần hỏi thêm:
Tần suất có đủ lớn không?
Một quy trình xảy ra 1.000 lần mỗi tháng khác với một quy trình xảy ra hai lần.
Mỗi lần đang mất bao nhiêu thời gian?
Có bao nhiêu người tham gia?
Tỷ lệ lỗi thủ công hiện tại là bao nhiêu?
Bottleneck có ảnh hưởng đến khách hàng không?
Nếu rút ngắn thời gian xử lý, business outcome nào thay đổi?
Chi phí integration và vận hành có hợp lý không?
Một workflow technically automatable chưa chắc economically worthwhile.
Đây là lý do nên đánh giá business value trước khi xây PoC.
Hãy tìm “điểm nối thủ công” trong doanh nghiệp
Nếu muốn tìm cơ hội automation mà chưa biết bắt đầu từ đâu, có một câu hỏi tương đối hiệu quả:
“Ở đâu nhân viên đang lấy thông tin từ một nơi rồi nhập, chuyển hoặc diễn giải nó sang một nơi khác?”
Ví dụ:
Email → Excel
Excel → CRM
CRM → báo cáo
PDF → hệ thống nội bộ
Meeting note → CRM
Customer request → ticket
ERP → Excel → báo cáo quản lý
Tài liệu nội bộ → email trả lời khách hàng
Những điểm nối này không mặc nhiên là use case AI.
Nhưng chúng là nơi rất đáng để phân tích.
Sau khi hiểu bản chất từng bước, doanh nghiệp mới có thể xác định:
Process redesign?
API?
Workflow automation?
RPA?
AI?
AI Agent?
Hay kết hợp nhiều phương pháp?
Vai trò của FDE: Không bắt đầu bằng câu hỏi “Muốn xây Agent nào?”
Đây cũng là nơi cách tiếp cận FDE – Forward Deployed Engineer trở nên phù hợp.
Nếu doanh nghiệp chỉ mô tả:
“Nhân viên của chúng tôi mất rất nhiều thời gian chuyển dữ liệu giữa các hệ thống.”
thì chưa thể biết ngay giải pháp là gì.
FDE cần đi sâu hơn vào workflow.
Nhân viên thực sự thao tác như thế nào?
Hệ thống nào đang được sử dụng?
Dữ liệu nằm ở đâu?
Hệ thống có API không?
Bước nào deterministic?
Bước nào cần hiểu ngôn ngữ?
Bước nào cần judgment?
Bước nào tạo ra bottleneck?
Sau đó mới thiết kế phương án.
Có thể kết quả cuối cùng là AI Agent.
Nhưng cũng có thể 70% vấn đề được giải quyết bằng API và workflow automation, còn AI chỉ cần cho 30% liên quan đến email và tài liệu.
Nếu phương án thứ hai đơn giản, ổn định và kinh tế hơn, đó mới là phương án đáng ưu tiên.
Đừng hỏi “AI có thể thay nhân viên làm quy trình này không?”
Hãy đổi câu hỏi thành:
“Trong quy trình này, bước nào máy nên làm và bước nào con người nên tiếp tục làm?”
Đây là một thay đổi nhỏ nhưng quan trọng.
Một workflow có thể được thiết kế như:
Machine → Machine → AI → Machine → Human → Machine.
Con người không cần xuất hiện ở mọi bước.
Nhưng AI cũng không cần xuất hiện ở mọi bước.
Mục tiêu không phải xây một quy trình “nhiều AI nhất”.
Mục tiêu là xây một quy trình:
ít thao tác thủ công hơn;
ít chuyển đổi hệ thống không cần thiết hơn;
dữ liệu nhất quán hơn;
dễ kiểm soát hơn;
và tạo ra kết quả nhanh hơn.
Bắt đầu bằng một workflow mà đội ngũ đang thực hiện mỗi ngày
Nếu nhân viên của bạn đang phải liên tục chuyển giữa Email, Excel, CRM, tài liệu và nhiều hệ thống nội bộ để hoàn thành một công việc, đó là một nơi đáng để bắt đầu phân tích.
Nhưng chưa cần quyết định ngay rằng doanh nghiệp cần AI Agent.
Synora có thể cùng đội ngũ mapping lại workflow hiện tại, xác định những điểm nối thủ công và phân loại:
bước nào nên được loại bỏ hoặc thiết kế lại;
bước nào phù hợp với API;
bước nào nên dùng workflow automation hoặc RPA;
bước nào thực sự cần khả năng của AI;
và bước nào cần giữ con người kiểm soát.
Từ đó mới đánh giá liệu AI Agent có cần thiết và business value có đủ lớn để đầu tư hay không.
AI Agent × FDE
Chưa biết nên bắt đầu AI Agent từ đâu?
Bạn không cần bắt đầu bằng việc chọn AI model hay xây ngay một AI Agent.
Hãy bắt đầu từ một công việc đang khiến đội ngũ mất nhiều thời gian:
- Xử lý email
- Tìm kiếm thông tin
- Tổng hợp báo cáo
- Cập nhật dữ liệu giữa nhiều hệ thống
- Quy trình còn nhiều thao tác thủ công
Synora có thể cùng đội ngũ của bạn rà soát quy trình hiện tại, xác định điểm nghẽn và đánh giá use case phù hợp — bao gồm cả việc xác định phần nào thực sự cần AI Agent và phần nào nên giải quyết bằng API, workflow automation hoặc phương án đơn giản hơn.
Bạn có một quy trình muốn thử tự động hóa?
Hãy chia sẻ với Synora cách công việc đó đang được thực hiện hiện nay. Chúng tôi sẽ cùng bạn xem xét đâu là điểm phù hợp để bắt đầu.
Hãy bắt đầu từ một quy trình đang khiến nhân viên phải chuyển qua quá nhiều hệ thống — không cần bắt đầu từ một requirement AI hoàn chỉnh.
Tìm hiểu AI Agent × FDE