สร้างคำแนะนำเวิร์กโฟลว์ด้วย Okou

คุณไม่จำเป็นต้องเขียนคำแนะนำเวิร์กโฟลว์จากหน้าว่าง เริ่มจากทำงานจริงให้สำเร็จร่วมกับเอเจนต์ของคุณ เมื่อผลลัพธ์เป็นประโยชน์แล้ว ให้ขอให้เอเจนต์เปลี่ยนวิธีการที่คุณพัฒนาร่วมกันให้เป็นเวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้

เอเจนต์จะสร้างฉบับร่างแรก บทบาทของคุณคือทบทวนสมมติฐานของมันและตัดสินใจว่าเวิร์กโฟลว์ต้องมีข้อจำกัดที่ชัดเจนตรงไหนบ้าง เพื่อให้เพื่อนร่วมทีมคนอื่นได้ผลลัพธ์ที่เชื่อถือได้

ด้วย My Okou คำแนะนำส่วนบุคคลจะเก็บความชอบของสมาชิกแต่ละคนไว้; เวิร์กโฟลว์ของพื้นที่ทำงานจะเก็บขั้นตอนที่ทำซ้ำได้และมาตรฐานของทีม เวิร์กโฟลว์ส่วนตัวเป็นของผู้ใช้ปัจจุบัน และเวิร์กโฟลว์สาธารณะจะแชร์ภายในพื้นที่ทำงาน การทำงานใช้คำแนะนำ หน่วยความจำ บัญชี และสิทธิ์ของสมาชิกที่เป็นผู้รัน ใน Legacy Agents เวิร์กโฟลว์ยังคงผูกกับเอเจนต์หนึ่งตัว ดู Instructions and experience modes.

เริ่มจากการรันที่สำเร็จ

การสร้างเวิร์กโฟลว์จะง่ายขึ้นหลังจากที่เอเจนต์ได้เห็นงาน แหล่งข้อมูลที่ใช้ ความคิดเห็นของคุณ และผลลัพธ์ที่ยอมรับได้

1. ให้งานจริงและอินพุตจริงที่ต้องใช้แก่อเจนต์
2. ทบทวนผลลัพธ์และแก้บริบทที่ขาด เหตุผลที่อ่อน หรือรูปแบบที่ไม่ถูกต้อง
3. เมื่อผลลัพธ์ดีแล้ว ให้ขอให้เอเจนต์สกัดวิธีการที่ทำซ้ำได้
4. ให้เอเจนต์ร่างชื่อเวิร์กโฟลว์ คำอธิบาย คำแนะนำ และไฟล์อ้างอิงใดๆ ที่มันแนะนำ
5. ทบทวนฉบับร่างร่วมกันก่อนทำให้เวิร์กโฟลว์เป็นสาธารณะ

คุณสามารถถามได้ว่า:

เปลี่ยนสิ่งที่เราเพิ่งทำให้เป็นเวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้สำหรับทีม ร่างชื่อ คำอธิบาย และคำแนะนำ แยกวิธีการที่ใช้ซ้ำได้ออกจากรายละเอียดที่ใช้กับกรณีนี้เท่านั้น ก่อนที่เราจะสรุป ให้แสดงสมมติฐานและข้อจำกัดที่ฉันควรทบทวน

สิ่งนี้มอบหน้าที่การร่างให้เอเจนต์ และมอบหน้าที่ตัดสินใจว่าต้องควบคุมส่วนใดบ้างให้กับคุณ

คำแนะนำเป็นจุดที่มักใช้กำหนดข้อจำกัด

คำแนะนำของเวิร์กโฟลว์จะติดไปกับเวิร์กโฟลว์และมีผลทุกครั้งที่มันรัน นั่นทำให้เป็นหนึ่งในตำแหน่งที่ใช้กำหนดข้อจำกัดบ่อยที่สุด เช่น อินพุตที่ต้องมี แหล่งข้อมูลที่อนุมัติแล้ว รูปแบบเอาต์พุต มาตรฐานคุณภาพ และการกระทำที่ต้องขอการยืนยัน

แต่ไม่ใช่ชั้นควบคุมเพียงอย่างเดียว:

อย่าพึ่งพาข้อความในคำแนะนำแทนการควบคุมการเข้าถึง หากการกระทำต้องถูกจำกัดทางเทคนิค ให้ใช้การอนุญาตของคอนเน็กเตอร์จริงและสิทธิ์ที่ระบุชื่อไว้ควบคู่กับคำแนะนำที่ชัดเจน

ทบทวนฉบับร่างแรกของเอเจนต์

คุณไม่จำเป็นต้องเขียนใหม่ทุกประโยค โฟกัสการทบทวนไปที่การตัดสินใจที่สำคัญต่อทีม

ควรใช้เมื่อใด?

• คำขอหรือสถานการณ์แบบใดควรเลือกเวิร์กโฟลว์นี้?
• เมื่อใดที่เอเจนต์ไม่ควรใช้มัน?
• คำอธิบายเฉพาะพอที่จะแยกจากเวิร์กโฟลว์ที่คล้ายกันหรือไม่?

ต้องใช้อินพุตอะไรบ้าง?

• เพื่อนร่วมทีมต้องให้ข้อมูลอะไรบ้างก่อนเริ่มงาน?
• อินพุตที่ขาดหายใดควรทำให้เอเจนต์ถามคำถาม?
• รายละเอียดใดควรอยู่ในแต่ละการรันแทนที่จะอยู่ในคำแนะนำถาวร?

แหล่งข้อมูลและกฎข้อใดชนะ?

• แหล่งข้อมูลหลักที่เป็นบันทึกทางการคืออะไร?
• ไฟล์ที่แนบมาระบุเกณฑ์หรือเทมเพลตที่อนุมัติแล้วอยู่ไฟล์ใด?
• หากสองแหล่งขัดแย้งกัน แหล่งใดมีลำดับความสำคัญ?
• เอเจนต์ควรติดป้ายข้อเท็จจริงที่ตรวจสอบไม่ได้อย่างไร?

เอาต์พุตควรมีลักษณะอย่างไร?

• ต้องมีส่วนหรือฟิลด์ใดบ้าง?
• รายละเอียดระดับใดถึงจะมีประโยชน์?
• เอาต์พุตต้องมีการอ้างอิง ลิงก์ หรือป้ายกำกับความมั่นใจหรือไม่?
• เมื่อมีปลายทางกำหนดไว้ ผลลัพธ์ควรไปที่ใด?

เอเจนต์ต้องหยุดตรงไหน?

• การกระทำใดต้องได้รับการยืนยัน?
• เอเจนต์ควรสร้างฉบับร่างแทนการส่งหรือการเผยแพร่หรือไม่?
• ข้อมูลใดไม่ควรปรากฏในเวิร์กโฟลว์สาธารณะหรือผลลัพธ์ที่แชร์?

นี่คือข้อจำกัดที่คุ้มค่าจะทำให้ชัดเจน ให้เอเจนต์จัดการถ้อยคำ แล้วค่อยยืนยันว่าถ้อยคำนั้นสะท้อนการตัดสินใจของคุณ

โครงสร้างสำหรับทบทวนร่วมกัน

เอเจนต์สามารถใช้โครงสร้างต่อไปนี้สำหรับฉบับร่างแรกได้ ให้ถือว่านี่เป็นกรอบสำหรับการทบทวน ไม่ใช่แบบฟอร์มที่คุณต้องกรอกเอง:

# 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.

เวิร์กโฟลว์ที่เรียบง่ายอาจต้องมีเพียงไม่กี่ส่วน เวิร์กโฟลว์ที่มีความเสี่ยงสูงอาจต้องมีกฎด้านแหล่งข้อมูล การตรวจสอบ และการอนุมัติที่ชัดเจนมากขึ้น ขอให้เอเจนต์เก็บคำแนะนำให้สั้นที่สุดเท่าที่จะทำได้ โดยไม่ปิดบังการตัดสินใจที่ทีมพึ่งพาอยู่

ตัวอย่าง: ร่วมสร้างเวิร์กโฟลว์การคัดกรองลีด

สมมติว่าคุณขอให้อเอเจนต์ค้นคว้าเกี่ยวกับลีดขาเข้าหนึ่งรายและร่างการตอบกลับ ระหว่างการรัน คุณแก้จำนวนพนักงานของบริษัท อธิบายว่า CRM คือแหล่งข้อมูลหลัก ใช้เกณฑ์ ICP ของทีม และขอให้อีเมลสั้นลง

หลังจากผลลัพธ์ได้รับการอนุมัติแล้ว ให้ขอให้เอเจนต์เปลี่ยนบทสนทนาให้เป็นเวิร์กโฟลว์ เอเจนต์จะร่างขั้นตอน จากนั้นคุณเพิ่มข้อจำกัดที่ควรคงอยู่ต่อไปแม้จะพ้นจากลีดรายนี้แล้ว:

• ตรวจ CRM ก่อนทำการค้นคว้าสาธารณะ;
• ใช้เกณฑ์ ICP ที่แนบมาในการให้คะแนน;
• อ้างอิงแหล่งข้อมูลสำหรับขนาดบริษัท ที่ตั้ง และบทบาทปัจจุบัน;
• ติดป้ายข้อเท็จจริงที่จำเป็นแต่ยังไม่ยืนยันว่า Unknown;
• ส่งกลับ Account summary, Evidence, ICP score, Risks, Recommended next step, และ Reply draft;
• สร้างฉบับร่างอีเมลและห้ามส่งโดยไม่ได้รับการยืนยัน.

ตอนนี้เอเจนต์สามารถผสานการตัดสินใจเหล่านั้นเข้าไปในคำแนะนำได้ คุณไม่จำเป็นต้องกำหนดทุกขั้นตอนการค้นคว้า สิ่งที่คุณต้องทำคือทำให้แหล่งข้อมูล สัญญาเอาต์พุต และขอบเขตการอนุมัติของทีมชัดเจนแบบไม่กำกวม

ให้ฟีดแบ็กเรื่องข้อจำกัดด้วยภาษาธรรมดา

คุณสามารถปรับฉบับร่างให้แน่นขึ้นได้โดยบอกเอเจนต์ว่าสิ่งใดต้องเปลี่ยน:

• “ขอระเบียน CRM ก่อนเริ่ม ถ้ามันหายไป”
• “ให้ถือ CRM เป็นแหล่งข้อมูลหลักเมื่อชื่อบริษัทขัดแย้งกัน”
• “ทุกข้ออ้างเชิงข้อเท็จจริงในบรีฟต้องมีลิงก์แหล่งข้อมูล”
• “คงการตอบกลับให้ไม่เกิน 150 คำ แต่ปรับน้ำเสียงให้เหมาะกับข้อความขาเข้า”
• “สร้างอีเมลเป็นฉบับร่าง อย่าส่งโดยอัตโนมัติ”
• “เวิร์กโฟลว์นี้ไม่ควรรันสำหรับโอกาสที่มีอยู่แล้ว”

ขอให้เอเจนต์อัปเดตเวิร์กโฟลว์และสรุปว่าการเปลี่ยนแต่ละอย่างตอบโจทย์ข้อจำกัดข้อใด วิธีนี้ช่วยให้จับกฎที่ถูกเข้าใจผิดหรือถูกวางไว้ผิดส่วนได้ง่ายขึ้น

เก็บสิ่งที่เหมาะสมไว้นอกคำแนะนำ

ข้อมูลบางอย่างไม่ควรกลายเป็นข้อความเวิร์กโฟลว์ถาวร:

• ชื่อลูกค้า กำหนดส่งครั้งเดียว และปลายทางเฉพาะกรณี ควรอยู่ในคำขอรัน;
• รหัสผ่าน โทเค็น และข้อมูลรับรองส่วนตัวไม่ควรอยู่ในคำแนะนำหรือไฟล์ที่แนบ;
• ตารางเวลาและเหตุการณ์ควรอยู่ใน ระบบอัตโนมัติ;
• ขอบเขตการเข้าถึงทางเทคนิคควรอยู่ในการอนุญาตของคอนเน็กเตอร์และสิทธิ์ที่ระบุชื่อไว้;
• ฟีดแบ็กส่วนตัวที่ใช้กับผลลัพธ์เพียงครั้งเดียวสามารถคงอยู่ในแชทนั้นได้

คำแนะนำควรบรรจุวิธีการที่นำกลับมาใช้ซ้ำได้และข้อจำกัดด้านพฤติกรรม ไม่ใช่ทุกรายละเอียดที่ล้อมรอบงาน

ทดสอบและปรับปรุงร่วมกัน

รันเวิร์กโฟลว์ด้วยอินพุตจริงอย่างน้อยสองชุด โดยควรมีเพื่อนร่วมทีมอีกคนด้วย หลังจากแต่ละการรัน ให้ถามว่า:

• เวิร์กโฟลว์ถูกกระตุ้นสำหรับงานที่ถูกต้องหรือไม่?
• มันร้องขออินพุตที่ต้องใช้หรือไม่?
• มันทำตามลำดับความสำคัญของแหล่งข้อมูลที่ตั้งใจไว้หรือไม่?
• เอาต์พุตสอดคล้องกันโดยไม่แข็งทื่อเกินไปหรือไม่?
• มันหยุดที่ขอบเขตการอนุมัติที่กำหนดไว้หรือไม่?
• ปัญหานี้ทำซ้ำได้หรือเกิดกับกรณีนี้เท่านั้น?

ขอให้อเอเจนต์แก้ไขคำแนะนำสำหรับช่องว่างที่เกิดซ้ำ เก็บการแก้ไขเฉพาะครั้งไว้ในการรัน เมื่อวิธีการใช้งานได้กับคนอื่นที่ไม่ใช่ผู้สร้างดั้งเดิมของมันแล้ว แชร์เวิร์กโฟลว์กับทีมของคุณ