Kiến thức / Văn phòng – Hành chính / Nhân sự văn phòng

Workflow AI Hành chính từ yêu cầu đến báo cáo

Workflow từ yêu cầu nội bộ đến hồ sơ, lịch và báo cáo dành cho Hành chính

Tình huống thật khi một yêu cầu đi qua nhiều hệ thống

Một sáng thứ Hai, bộ phận Hành chính nhận tin Zalo xin đổi phòng họp, email đề nghị cấp thẻ ra vào, cuộc gọi báo hỏng máy in và phiếu mua văn phòng phẩm từ Google Forms. Người phụ trách nhập lại vào Google Sheets, tạo nhiệm vụ trên Base.vn, kiểm tra lịch rồi chuyển chứng từ phù hợp sang MISA. Nếu người gửi bấm form hai lần hoặc kết nối retry sau khi chậm, cùng một yêu cầu có thể tạo hai nhiệm vụ và hai thông báo.

Workflow AI cho Hành chính cần giải quyết cả đường đi và độ tin cậy của từng bước. Mỗi yêu cầu có mã nguồn, khóa chống trùng, trạng thái, SLA và người chịu trách nhiệm. AI hỗ trợ kiểm tra dữ liệu, phân tuyến, tạo hồ sơ cùng lịch nháp và chuẩn bị dòng báo cáo; con người duyệt hành động. Khi một hệ thống lỗi, luồng không tiếp tục như thể đã thành công mà chuyển sang hàng lỗi có thể xử lý lại. Bài này đi sâu lifecycle phiếu sau khi use case đã được chọn, kết thúc bằng proof từ hệ thống đích và dữ liệu báo cáo truy về từng request_id.

Việc giao cho AI trong lifecycle phiếu

AI có thể đọc phiếu, chuẩn hóa tên trường, phát hiện dữ liệu thiếu, so danh mục, đề xuất loại việc, tạo email xác nhận, dựng checklist và chuẩn bị dòng lịch có phòng, múi giờ, thời điểm cùng người phụ trách. Sau khi hệ thống đích trả proof, Agent lập bảng báo cáo gồm trạng thái, thời gian chờ, SLA, lỗi và nguồn; nó không tự sửa log hoặc tính DONE cho bản ghi chưa xác nhận.

AI không được tự mua hàng, xác nhận chi phí, chọn nhà cung cấp, ghi lịch thật hoặc phát hành văn bản khi chưa có APPROVED. Nó không tự đổi SLA, tự gộp hai phiếu nghi trùng, retry hành động ghi vô hạn hoặc biến ERROR thành số liệu hoàn tất. Nếu không thấy quy tắc, Agent chuyển người phụ trách. Hành động ghi vào Base.vn, Calendar hoặc MISA cần khóa idempotency và kiểm tra kết quả; báo cáo chỉ đọc log đã xác nhận. Mọi email hay tin Zalo gửi ra ngoài bước thử nghiệm đều phải đi qua người có trách nhiệm.

Dữ liệu cần chuẩn bị và state machine

Phiếu đầu vào nên có source_event_id, request_id, người gửi, phòng ban, loại việc, mô tả, mức ưu tiên, ngày cần, tệp, người xử lý và người duyệt. Dòng lịch cần resource_id, start_at, end_at, timezone, attendee scope và conflict status. Danh mục tham chiếu gồm phòng họp, tài sản, nhà cung cấp được phép, hạn mức, SLA và nhóm quyền. Với mỗi lần ghi hệ thống, lưu idempotency_key, attempt_count, thời điểm thử, kết quả và mã bản ghi đích để kiểm tra trước khi chạy lại.

State machine tối thiểu gồm NEW, NEED_INFO, READY, DRAFT, REVIEW, APPROVED, DONE và ERROR. Chỉ định chuyển trạng thái hợp lệ, ví dụ DRAFT không đi thẳng DONE; ERROR chỉ quay lại sau khi nguyên nhân được xử lý. SLA có hai mốc: thời gian xử lý nghiệp vụ và thời gian chờ duyệt. Schema báo cáo cần request_id, request_type, created_at, approved_at, completed_at, SLA_status, target_proof, error_code và report_period. Luồng quá hạn tạo cảnh báo cho owner chứ không tự nâng ưu tiên; dữ liệu cá nhân không cần thiết bị loại khỏi bảng báo cáo.

Workflow sáu bước có idempotency và nhánh lỗi

Bước 1 — Thu nhận: tạo request_id từ source_event_id và kênh; nếu khóa đã tồn tại, trả bản ghi cũ thay vì tạo mới. Bước 2 — Xác thực: kiểm tra schema, quyền người gửi, tệp và danh mục; thiếu trường chuyển NEED_INFO, tệp lỗi chuyển ERROR_INPUT. Bước 3 — Phân tuyến: áp rule đã duyệt để chọn owner, SLA và người duyệt; không khớp chuyển REVIEW_ROUTING.

Bước 4 — Tạo hồ sơ và lịch nháp: Agent soạn email, checklist hoặc dòng lịch kèm request_id, resource_id, timezone và nguồn; chưa ghi hệ thống đích. Bước 5 — Duyệt và thực thi: nhân viên đối chiếu xung đột lịch, người có thẩm quyền duyệt; adapter kiểm tra idempotency_key trước khi ghi. Bước 6 — Xác nhận và báo cáo: tra mã bản ghi đích, lưu proof, cập nhật DONE rồi tạo dòng báo cáo có source_ref. Nếu ghi một phần, chuyển ERROR_PARTIAL, loại khỏi số hoàn tất, khóa retry tự động và giao checklist phục hồi cho người vận hành.

Workflow AI Hành chính sáu bước có khóa idempotency SLA và hàng lỗi — Sơ đồ minh họa đường chính cùng các nhánh NEED_INFO, REVIEW và ERROR_PARTIAL.

Năm prompt mẫu cho từng cổng kiểm soát

Prompt 1 kiểm tra phiếu đầu vào và tạo câu hỏi bổ sung. Prompt 2 phân tuyến từ danh mục, không tự tạo owner. Prompt 3 soạn hồ sơ hoặc lịch nháp có nguồn. Prompt 4 đối chiếu trước phê duyệt. Prompt 5 lập bảng dữ liệu báo cáo và tóm tắt kỳ từ log đã xác nhận, tách DONE, chờ duyệt, quá SLA và ERROR_PARTIAL. Không prompt nào tự ghi lịch, sửa trạng thái hoặc phát hành báo cáo.

Chạy prompt trên một phiếu giả lập trước, sau đó thử trường hợp trùng, thiếu tệp, xung đột lịch, quá SLA, người duyệt vắng và adapter chỉ ghi được một hệ thống. Báo cáo thử phải truy ngược mỗi dòng về request_id cùng target_proof và ghi số liệu là minh họa. AI không chạy retry hoặc câu lệnh; người phát triển workflow cùng chủ quy trình xác nhận state transition, công thức SLA và rule loại lỗi trước môi trường thử.

Công cụ phù hợp và kiến trúc kết nối

Google Forms là cửa vào, Google Sheets có thể làm hàng đợi cùng bảng báo cáo thử nghiệm, Base.vn giữ nhiệm vụ, Google Calendar giữ lịch, MISA nhận dữ liệu nghiệp vụ đã duyệt và Zalo gửi thông báo trạng thái tối thiểu. Một orchestration layer đọc sự kiện, tạo request_id, gọi AI ở vùng DRAFT rồi đợi phê duyệt. Adapter chịu trách nhiệm kiểm tra khóa chống trùng và trả mã kết quả; lớp báo cáo chỉ đọc log cùng proof đã xác nhận.

Không dùng một tài khoản cá nhân cho tất cả kết nối. Mỗi adapter có quyền thấp nhất, secret trong kho bảo mật, timeout, retry có giới hạn và circuit breaker nếu lỗi lặp. Hàng lỗi lưu payload đã giảm dữ liệu, mã phiếu, bước thất bại và hướng phục hồi. Dashboard tách lỗi đầu vào, lỗi rule, lỗi phê duyệt và lỗi kết nối để không gộp mọi vấn đề thành “AI sai”.

Giao diện hàng đợi Hành chính theo request id SLA và trạng thái lỗi — Giao diện minh họa hàng đợi và lỗi; số liệu không phải dữ liệu vận hành thực tế.

AI làm gì và người duyệt làm gì

AI kiểm tra cấu trúc, trích thông tin, áp rule được cung cấp, tạo hồ sơ hoặc lịch nháp và lập dòng báo cáo từ log đã xác nhận. Nó không sở hữu state machine, không thay khóa chống trùng, không tự sửa SLA và không tính bản ghi thiếu proof là hoàn tất. Khi nguồn mâu thuẫn hoặc rule báo cáo thiếu, kết quả là REVIEW với câu hỏi cụ thể.

Nhân viên Hành chính xác nhận thực tế, lịch, tài sản và cách diễn đạt. Trưởng bộ phận duyệt khoản chi, ngoại lệ và văn bản. IT sở hữu adapter, idempotency, retry và log; chủ dữ liệu quyết định phạm vi lưu; kế toán kiểm tra chứng từ. Người vận hành hàng lỗi xác định có chạy lại không, dựa trên trạng thái hệ thống đích. AI không được quyết định retry một hành động có thể tạo bản ghi kép.

Sai lầm và rủi ro cần tránh

Sai lầm đầu tiên là chống trùng bằng tên người gửi và thời gian gần nhau; cần source_event_id hoặc khóa nghiệp vụ ổn định. Sai lầm thứ hai là coi timeout là thất bại chắc chắn rồi ghi lại ngay, trong khi hệ thống đích có thể đã nhận. Sai lầm thứ ba là dùng một SLA cho mọi loại việc hoặc tự nâng ưu tiên khi quá hạn. Mỗi quyết định phải dựa trên rule và owner.

Rủi ro lớn nhất của luồng nhiều hệ thống là partial failure. Ví dụ nhiệm vụ đã tạo nhưng lịch chưa ghi, hoặc email đã gửi nhưng trạng thái chưa cập nhật. Nếu báo cáo đếm trạng thái nội bộ thay vì target_proof, số hoàn tất sẽ sai. Hãy dùng bước xác nhận, trạng thái ERROR_PARTIAL và checklist bù trừ; không xóa log sau xử lý tay. Khi có dữ liệu nhạy cảm, chỉ lưu mã tham chiếu trong hàng lỗi và bảng báo cáo.

Triển khai cá nhân, đội và doanh nghiệp

Cá nhân có thể thử một loại việc, một Sheet và chế độ chỉ tạo nháp. Dùng 20 phiếu giả lập gồm phiếu trùng, thiếu trường và quá hạn. Đội nhỏ thêm Base.vn hoặc Calendar, chỉ mở một adapter ghi và duyệt mọi hành động. Mỗi ngày rà hàng lỗi, nguyên nhân retry và các bản ghi nghi trùng.

Doanh nghiệp tách môi trường, quản lý schema, state machine, lịch và prompt theo phiên bản. Release cần test idempotency, xung đột lịch, timeout, permission, partial failure, công thức SLA và đối soát báo cáo. Theo dõi số phiếu trùng bị chặn, thời gian chờ duyệt, lịch ghi thành công, ERROR theo bước và bản ghi đích không khớp. Chỉ mở rộng khi chủ nghiệp vụ, IT cùng chủ dữ liệu nghiệm thu cả đường chính, đường lỗi và báo cáo.

Kết quả đầu ra mẫu và FAQ

Kết quả minh họa: request_id HC-2026-0187 có lịch nháp P.401, timezone Asia/Ho_Chi_Minh và idempotency_key CAL-HC-2026-0187. Base.vn đã tạo B-311 nhưng Calendar timeout nên trạng thái ERROR_PARTIAL, không được tính DONE trong báo cáo tuần DEMO-W29. Dòng báo cáo giữ target_proof thiếu, error_code và owner ROLE-HC-OPS để đối soát trước retry.

Timeout có nghĩa là hệ thống đích chưa ghi không?

Không. Phải tra idempotency key hoặc mã tham chiếu trước khi retry để tránh tạo bản ghi kép.

SLA quá hạn có nên tự nâng ưu tiên?

Không, trừ khi rule đã được duyệt. Mặc định workflow cảnh báo owner và giữ dấu vết.

Báo cáo có tính phiếu ERROR_PARTIAL là hoàn tất không?

Không. Phiếu giữ nhóm lỗi riêng cho tới khi có target_proof và transition DONE được người vận hành xác nhận.

AI có được tự chạy lại bước lỗi?

Không với hành động ghi hoặc gửi. Retry phải theo policy, budget, idempotency và quyền người vận hành.

Để rà state machine và nhánh lỗi, hãy liên hệ NganAds tại trang tư vấn hoặc số 0983543063.

Workflow

Bước 1: Thu nhận có khóa chống trùng — Tạo request_id từ sự kiện; nếu khóa tồn tại thì trả bản ghi cũ, không tạo mới.
Bước 2: Xác thực đầu vào — Kiểm schema, quyền, tệp và danh mục; thiếu chuyển NEED_INFO, tệp lỗi chuyển ERROR_INPUT.
Bước 3: Phân tuyến và gắn SLA — Áp rule để chọn owner, SLA và approver; không khớp chuyển REVIEW_ROUTING.
Bước 4: Tạo bản nháp — Soạn email, checklist hoặc lịch nháp kèm request_id và nguồn; chưa ghi hệ thống đích.
Bước 5: Duyệt và thực thi — Người có quyền duyệt; adapter kiểm tra idempotency_key trước khi ghi hoặc gửi.
Bước 6: Xác nhận, báo cáo hoặc chuyển hàng lỗi — Có target proof mới ghi DONE và tạo dòng báo cáo; partial failure vào ERROR_PARTIAL, không tính hoàn tất.

Prompt mẫu

Kiểm tra phiếu đầu vào

MỤC TIÊU: Kiểm tra một phiếu Hành chính trước khi vào state machine.
[ĐẦU VÀO]: source_event_id, request_id, người gửi, loại việc, mô tả, ngày cần, tệp, schema và quyền người gửi.
ĐỊNH DẠNG ĐẦU RA: PASS/NEED_INFO/ERROR_INPUT; trường hợp lệ, trường thiếu, lỗi định dạng, câu hỏi bổ sung và stop_reason; không suy đoán.
VÍ DỤ ĐIỀN SẴN: FORM-8841; HC-2026-0187; đổi phòng họp; thiếu thiết bị; tệp lịch mở được.

Phân tuyến theo rule

MỤC TIÊU: Đề xuất owner, SLA và người duyệt từ danh mục được phê duyệt.
[ĐẦU VÀO]: Phiếu hợp lệ, bảng loại việc, owner, SLA, hạn mức, người duyệt và ngoại lệ.
ĐỊNH DẠNG ĐẦU RA: loại, owner, SLA, approver, rule_id, evidence và REVIEW_ROUTING nếu không khớp; không tự tạo owner.
VÍ DỤ ĐIỀN SẴN: Cấp thẻ khách ngoài giờ; Lễ tân xử lý; SLA 4 giờ; Trưởng Hành chính duyệt.

Tạo bản nháp có nguồn

MỤC TIÊU: Tạo email, checklist hoặc sự kiện nháp cho phiếu đã phân tuyến.
[ĐẦU VÀO]: request_id, dữ liệu đã xác thực, mẫu, người nhận, thời hạn, thông tin cấm và nguồn.
ĐỊNH DẠNG ĐẦU RA: draft_type, draft_content, source_refs, missing_fields, restricted_actions và status=DRAFT; chưa gửi hoặc ghi.
VÍ DỤ ĐIỀN SẴN: HC-2026-0187; đề xuất P.401; chờ xác nhận máy chiếu; owner ROLE-HC-OPS.

Kiểm tra trước phê duyệt

MỤC TIÊU: Đối chiếu bản nháp với phiếu, lịch, danh mục và rule trước khi duyệt.
[ĐẦU VÀO]: Bản nháp, nguồn, lịch hiện tại, SLA, hạn mức, người duyệt và dữ liệu nhạy cảm.
ĐỊNH DẠNG ĐẦU RA: Checklist PASS/REVIEW, trích nguồn, lỗi, hành động cấm, câu hỏi và approver; không sửa dữ kiện thiếu nguồn.
VÍ DỤ ĐIỀN SẴN: P.401 trống 14:00–15:00; chưa xác nhận máy chiếu; Calendar chưa được phép ghi.

Lập dữ liệu báo cáo có nguồn

MỤC TIÊU: Tạo bảng báo cáo vận hành từ log và target proof đã xác nhận, không sửa trạng thái nguồn.
[ĐẦU VÀO]: report_period, request log, state transitions, SLA rule version, Calendar/Base.vn target proof, error queue và owner.
ĐỊNH DẠNG ĐẦU RA: Bảng request_id | loại | created_at | approved_at | completed_at | SLA_status | target_proof | error_code | owner; kèm tóm tắt DONE/WAITING/ERROR và source_refs.
VÍ DỤ ĐIỀN SẴN: DEMO-W29 có 20 phiếu minh họa; HC-2026-0187 ở ERROR_PARTIAL vì thiếu Calendar proof, không tính DONE.

Câu hỏi thường gặp

Timeout có nghĩa hệ thống đích chưa ghi không?

Không. Phải tra idempotency key hoặc mã tham chiếu trước khi retry.

SLA quá hạn có nên tự nâng ưu tiên?

Không, trừ khi rule đã được duyệt; mặc định chỉ cảnh báo owner.

Báo cáo có tính phiếu ERROR_PARTIAL là hoàn tất không?

Không; phiếu ở nhóm lỗi cho tới khi có target_proof và transition DONE được xác nhận.

AI có được tự chạy lại bước lỗi?

Không với hành động ghi hoặc gửi; retry cần policy, budget, idempotency và người có quyền.

Bài liên quan

Muốn cài AI Agent cá nhân 499K (support 7 ngày)? Inbox / Zalo 0983543063.