Tạo hướng dẫn quy trình làm việc với tác nhân của bạn

Bạn không cần viết hướng dẫn quy trình từ trang trắng. Hãy bắt đầu bằng cách hoàn thành một nhiệm vụ thực tế với tác nhân của bạn. Khi kết quả đã hữu ích, hãy yêu cầu tác nhân chuyển phương pháp bạn cùng phát triển thành một quy trình có thể tái sử dụng.

Tác nhân sẽ tạo bản nháp đầu tiên. Vai trò của bạn là rà soát các giả định và quyết định nơi quy trình cần các giới hạn rõ ràng hơn để đồng đội khác có thể nhận được kết quả đáng tin cậy.

Mỗi quy trình thuộc về một tác nhân. Tác nhân cung cấp vai trò và năng lực tổng thể; quy trình ghi lại thủ tục và các giới hạn cho một nhiệm vụ lặp lại.

Bắt đầu từ một lần chạy thành công

Việc tạo quy trình sẽ dễ dàng hơn sau khi tác nhân đã thấy nhiệm vụ, tài liệu nguồn, phản hồi của bạn và một kết quả chấp nhận được.

1. Giao cho tác nhân một nhiệm vụ thực tế cùng dữ liệu đầu vào thực tế cần thiết.
2. Rà soát kết quả và chỉnh sửa các ngữ cảnh thiếu, lý luận yếu hoặc định dạng sai.
3. Khi kết quả đã tốt, yêu cầu tác nhân trích xuất phương pháp có thể lặp lại.
4. Để tác nhân phác thảo tên quy trình, mô tả, hướng dẫn và bất kỳ tệp tham khảo nào mà nó đề xuất.
5. Rà soát bản nháp cùng nhau trước khi công khai quy trình.

Bạn có thể hỏi:

Hãy chuyển những gì chúng ta vừa làm thành một quy trình có thể tái sử dụng cho nhóm. Phác thảo tên, mô tả và hướng dẫn. Tách biệt phương pháp có thể lặp lại khỏi các chi tiết chỉ áp dụng cho trường hợp này. Trước khi hoàn thiện, hãy liệt kê các giả định và giới hạn tôi nên rà soát.

Điều này giao cho tác nhân nhiệm vụ phác thảo. Bạn sẽ quyết định phần nào cần kiểm soát.

Hướng dẫn là nơi phổ biến để đặt giới hạn

Hướng dẫn quy trình đi kèm với quy trình và áp dụng mỗi lần quy trình được thực hiện. Đây là một trong những nơi phổ biến nhất để xác định các giới hạn như đầu vào bắt buộc, nguồn được phê duyệt, định dạng đầu ra, tiêu chuẩn chất lượng và các hành động cần xác nhận.

Đây không phải là lớp kiểm soát duy nhất:

Đừng chỉ dựa vào văn bản hướng dẫn để thay thế kiểm soát truy cập. Nếu một hành động cần bị giới hạn về mặt kỹ thuật, hãy sử dụng cả ủy quyền và quyền tác nhân cùng với hướng dẫn rõ ràng.

Rà soát bản nháp đầu tiên của tác nhân

Bạn không cần viết lại từng câu. Hãy tập trung rà soát vào các quyết định quan trọng với nhóm.

Khi nào nên sử dụng?

• Yêu cầu hoặc tình huống nào nên chọn quy trình này?
• Khi nào tác nhân không nên sử dụng quy trình này?
• Mô tả có đủ cụ thể để phân biệt với các quy trình tương tự không?

Đầu vào nào là bắt buộc?

• Đồng đội cần cung cấp gì trước khi bắt đầu?
• Thiếu đầu vào nào thì tác nhân nên hỏi lại?
• Chi tiết nào thuộc về từng lần chạy thay vì hướng dẫn cố định?

Nguồn và quy tắc nào ưu tiên?

• Hệ thống lưu trữ chính là gì?
• Tệp đính kèm nào chứa tiêu chí hoặc mẫu được phê duyệt?
• Nếu hai nguồn mâu thuẫn, nguồn nào ưu tiên?
• Tác nhân nên gắn nhãn các thông tin không xác minh được như thế nào?

Đầu ra cần có hình thức gì?

• Phần hoặc trường nào là bắt buộc?
• Mức độ chi tiết nào là hữu ích?
• Đầu ra có cần trích dẫn, liên kết hoặc nhãn độ tin cậy không?
• Kết quả nên chuyển đến đâu khi có điểm đến?

Tác nhân phải dừng ở đâu?

• Hành động nào cần xác nhận?
• Tác nhân nên tạo bản nháp thay vì gửi hoặc công khai?
• Dữ liệu nào không được xuất hiện trong quy trình công khai hoặc kết quả chia sẻ?

Đây là các giới hạn nên làm rõ. Để tác nhân xử lý câu chữ, sau đó xác nhận rằng nội dung phản ánh đúng quyết định của bạn.

Một cấu trúc để cùng rà soát

Tác nhân có thể sử dụng cấu trúc sau cho bản nháp đầu tiên. Xem đây là khung rà soát, không phải biểu mẫu bạn phải tự điền:

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

Một quy trình đơn giản có thể chỉ cần vài phần. Quy trình quan trọng có thể cần quy tắc nguồn, xác thực và phê duyệt rõ ràng hơn. Yêu cầu tác nhân giữ hướng dẫn ngắn nhất có thể mà không bỏ sót quyết định nhóm cần.

Ví dụ: đồng tạo quy trình đánh giá khách hàng tiềm năng

Giả sử bạn yêu cầu tác nhân nghiên cứu một khách hàng tiềm năng mới và soạn thảo phản hồi. Trong quá trình chạy, bạn chỉnh lại quy mô công ty, giải thích rằng CRM là hệ thống lưu trữ chính, áp dụng tiêu chí ICP của nhóm và yêu cầu email ngắn hơn.

Sau khi kết quả được duyệt, hãy yêu cầu tác nhân chuyển cuộc trò chuyện thành quy trình. Tác nhân sẽ phác thảo thủ tục. Bạn bổ sung các giới hạn cần duy trì lâu dài hơn trường hợp này:

• kiểm tra CRM trước khi nghiên cứu công khai;
• dùng tiêu chí ICP đính kèm để chấm điểm;
• trích dẫn nguồn cho quy mô công ty, vị trí và vai trò hiện tại;
• gắn nhãn thông tin bắt buộc chưa xác minh là Không xác định;
• trả về Tóm tắt tài khoản, Bằng chứng, Điểm ICP, Rủi ro, Bước tiếp theo đề xuất và Bản nháp phản hồi;
• tạo bản nháp email và không bao giờ gửi đi nếu chưa xác nhận.

Tác nhân giờ có thể tích hợp các quyết định đó vào hướng dẫn. Bạn không cần chỉ định từng bước nghiên cứu. Bạn cần làm rõ nguồn, hợp đồng đầu ra và phạm vi phê duyệt của nhóm.

Đưa phản hồi về giới hạn bằng ngôn ngữ đơn giản

Bạn có thể siết chặt bản nháp bằng cách nói rõ cho tác nhân điều gì phải thay đổi:

• “Hỏi bản ghi CRM trước khi bắt đầu nếu chưa có.”
• “Coi CRM là hệ thống lưu trữ chính khi tên công ty mâu thuẫn.”
• “Mỗi thông tin thực tế trong bản tóm tắt cần liên kết nguồn.”
• “Giữ phản hồi dưới 150 từ, nhưng điều chỉnh giọng điệu phù hợp với tin nhắn đến.”
• “Tạo email dưới dạng bản nháp. Không bao giờ gửi tự động.”
• “Quy trình này không nên chạy cho các cơ hội đã có.”

Yêu cầu tác nhân cập nhật quy trình và tóm tắt mỗi thay đổi nhằm giải quyết giới hạn nào. Như vậy sẽ dễ phát hiện quy tắc bị hiểu sai hoặc đặt nhầm chỗ.

Để thông tin phù hợp ngoài hướng dẫn

Một số thông tin không nên trở thành văn bản quy trình vĩnh viễn:

• tên khách hàng, hạn chót một lần và điểm đến cụ thể nên nằm trong yêu cầu chạy;
• mật khẩu, token và thông tin đăng nhập riêng không nên xuất hiện trong hướng dẫn hoặc tệp đính kèm;
• lịch trình và sự kiện thuộc về một tự động hóa;
• giới hạn truy cập kỹ thuật thuộc về ủy quyền và quyền tác nhân;
• phản hồi cá nhân chỉ áp dụng cho một kết quả có thể giữ trong cuộc trò chuyện đó.

Hướng dẫn nên mang phương pháp có thể tái sử dụng và các giới hạn hành vi, không phải mọi chi tiết xung quanh công việc.

Kiểm thử và hoàn thiện cùng nhau

Chạy quy trình với ít nhất hai đầu vào thực tế, tốt nhất là với một đồng đội khác. Sau mỗi lần chạy, hãy hỏi:

• Quy trình có kích hoạt đúng nhiệm vụ không?
• Có yêu cầu đủ đầu vào cần thiết không?
• Có tuân thủ đúng thứ tự ưu tiên nguồn không?
• Đầu ra có nhất quán mà không quá cứng nhắc không?
• Có dừng đúng phạm vi phê duyệt không?
• Vấn đề có lặp lại được không, hay chỉ áp dụng cho trường hợp này?

Yêu cầu tác nhân chỉnh lại hướng dẫn cho các lỗ hổng lặp lại. Giữ các chỉnh sửa một lần trong lần chạy. Khi phương pháp hoạt động với người khác ngoài người tạo ban đầu, chia sẻ quy trình với nhóm của bạn.