Tạo hướng dẫn Quy trình làm việc với Okou

Bạn không cần viết hướng dẫn quy trình làm việc từ một trang trắng. Hãy bắt đầu bằng cách hoàn thành một tác 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 biến phương pháp hai bên đã phát triển thành một quy trình làm việc 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à xem lại các giả định của nó và quyết định chỗ nào quy trình làm việc cần ràng buộc rõ hơn để một đồng đội khác có thể đạt được kết quả đáng tin cậy.

Với My Okou, hướng dẫn cá nhân (Instructions) chứa các sở thích của từng thành viên; quy trình làm việc của không gian làm việc chứa quy trình lặp lại và các tiêu chuẩn của nhóm. Quy trình làm việc riêng tư thuộc về người dùng hiện tại, còn quy trình làm việc công khai được chia sẻ trong không gian làm việc. Việc thực thi sử dụng hướng dẫn cá nhân, bộ nhớ, tài khoản và quyền của thành viên đang thực thi. Trong Legacy Agents, quy trình làm việc vẫn gắn với một tác nhân. Xem Instructions and experience modes.

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

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

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

Bạn có thể hỏi:

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

Điều này giao cho tác nhân nhiệm vụ soạn thảo. Nó giao cho bạn nhiệm vụ quyết định những phần nào cần được kiểm soát.

Hướng dẫn là nơi thường dùng để đặt ràng buộc

Hướng dẫn của quy trình làm việc đi kèm với quy trình làm việc và được áp dụng mỗi khi nó chạy. Điều đó khiến đây là một trong những nơi phổ biến nhất để xác định các ràng buộc như đầu vào bắt buộc, nguồn đã được chấp thuận, đị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 dựa vào văn bản hướng dẫn để thay thế cho các 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 dùng cả ủy quyền trình kết nối thực tế và quyền được đặt tên rõ ràng, cùng với một hướng dẫn rõ ràng.

Xem lại 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 xem xét những quyết định quan trọng đối với nhóm.

Khi nào nên dùng nó?

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

Cần đầu vào nào?

• Đồng đội phải cung cấp gì trước khi công việc bắt đầu?
• Những đầu vào nào bị thiếu thì tác nhân nên hỏi lại?
• Chi tiết nào thuộc về mỗi lần chạy thay vì hướng dẫn vĩnh viễn?

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

• Hệ thống ghi nhận chính là gì?
• Tệp đính kèm nào chứa rubric hoặc mẫu đã được chấp thuận?
• Nếu hai nguồn mâu thuẫn, nguồn nào được ưu tiên?
• Tác nhân nên gắn nhãn các факт mà nó không thể xác minh như thế nào?

Đầu ra cần trông như thế nào?

• Những mục 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?
• Khi có đích đến được cung cấp, kết quả nên đi đâu?

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

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

Đây là những ràng buộc đáng để nêu rõ. Hãy để tác nhân lo phần diễn đạt, rồi xác nhận rằng cách diễn đạt phản ánh quyết định của bạn.

Một cấu trúc để cùng xem lại

Tác nhân có thể dùng cấu trúc sau cho bản nháp đầu tiên. Hãy xem nó như một khung xem xét, không phải một 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 workflow đơn giản có thể chỉ cần vài phần. Một workflow có rủi ro cao có thể cần các quy tắc nguồn, xác thực và phê duyệt rõ ràng hơn. Hãy yêu cầu tác nhân giữ hướng dẫn ngắn nhất có thể mà không che giấu một quyết định mà nhóm phụ thuộc vào.

Ví dụ: cùng tạo workflow đánh giá lead

Giả sử bạn yêu cầu tác nhân nghiên cứu một lead inbound và soạn một phản hồi. Trong lần chạy, bạn sửa quy mô công ty, giải thích rằng CRM là hệ thống ghi nhận chính, áp dụng rubric ICP của nhóm, và yêu cầu một email ngắn hơn.

Sau khi kết quả được phê duyệt, hãy yêu cầu tác nhân biến cuộc trò chuyện thành một workflow. Tác nhân soạn quy trình. Sau đó bạn thêm các ràng buộc cần tồn tại lâu hơn lead này:

• kiểm tra CRM trước khi thực hiện nghiên cứu công khai;
• dùng rubric ICP đính kèm để chấm điểm;
• trích dẫn nguồn cho quy mô công ty, địa điểm và vai trò hiện tại;
• gắn nhãn một факт bắt buộc chưa được xác minh là Không rõ;
• trả về Account summary, Evidence, ICP score, Risks, Recommended next step, và Reply draft;
• tạo bản nháp email và không bao giờ gửi nếu không có xác nhận.

Giờ đây tác nhân có thể kết hợp những quyết định đó vào hướng dẫn. Bạn không cần quy định mọi bước nghiên cứu. Bạn cần làm cho nguồn của nhóm, hợp đồng đầu ra và ranh giới phê duyệt trở nên rõ ràng, không mơ hồ.

Góp ý về ràng buộc bằng ngôn ngữ bình thường

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

• “Hãy yêu cầu bản ghi CRM trước khi bắt đầu nếu nó bị thiếu.”
• “Hãy xem CRM là hệ thống ghi nhận chính khi tên công ty mâu thuẫn.”
• “Mọi khẳng định thực tế trong bản tóm tắt đều cần một liên kết nguồn.”
• “Giữ câu trả lời dưới 150 từ, nhưng điều chỉnh giọng điệu theo tin nhắn inbound.”
• “Hãy tạo email dưới dạng bản nháp. Đừng bao giờ tự động gửi.”
• “Workflow này không nên chạy cho các cơ hội hiện có.”

Yêu cầu tác nhân cập nhật workflow và tóm tắt ràng buộc nào mà mỗi thay đổi đang xử lý. Điều đó giúp dễ phát hiện quy tắc nào đã bị hiểu sai hoặc đặt nhầm vào phần không đúng.

Giữ những điều đúng chỗ bên ngoài hướng dẫn

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

• tên khách hàng, hạn chót một lần, và đích đến cụ thể theo từng trường hợp thuộc về yêu cầu chạy;
• mật khẩu, token và thông tin xác thực riêng không thuộc về hướng dẫn hay tệp đính kèm;
• lịch trình và sự kiện thuộc về một automation;
• ranh giới truy cập kỹ thuật thuộc về ủy quyền trình kết nối và quyền được đặt tên;
• phản hồi cá nhân chỉ áp dụng cho một kết quả có thể ở lại trong cuộc chat đó.

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

Cùng kiểm thử và tinh chỉnh

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

• Workflow có kích hoạt đúng tác vụ không?
• Nó có yêu cầu những đầu vào cần thiết không?
• Nó có tuân theo mức ưu tiên nguồn dự kiến không?
• Đầu ra có nhất quán mà không trở nên cứng nhắc không?
• Nó có dừng ở ranh giới phê duyệt được yêu cầu không?
• Vấn đề này có lặp lại được không, hay nó chỉ áp dụng cho trường hợp này?

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