אין צורך לכתוב הוראת זרימת עבודה מדף ריק. התחילו בביצוע משימה אמיתית עם הסוכן שלכם. ברגע שהתוצאה שימושית, בקשו מהסוכן להפוך את השיטה שפיתחתם יחד לזרימת עבודה לשימוש חוזר.
הסוכן יוצר את הטיוטה הראשונה. התפקיד שלכם הוא לבדוק את ההנחות שלו ולהחליט היכן זרימת העבודה זקוקה למגבלות ברורות יותר, כדי שחבר צוות אחר יוכל לקבל תוצאה אמינה.
ב־My Okou, ההוראות האישיות (Instructions) מחזיקות את ההעדפות של כל חבר; תהליך עבודה בסביבת העבודה מחזיק את ההליך החוזר ואת תקני הצוות. תהליכי עבודה פרטיים שייכים למשתמש הנוכחי, ותהליכי עבודה ציבוריים משותפים בתוך סביבת העבודה. ההרצה משתמשת ב־Instructions, בזיכרון, בחשבונות ובהרשאות של חבר הצוות שמבצע את ההרצה. ב־Legacy Agents, תהליכי העבודה נשארים מצורפים לסוכן אחד. ראו Instructions ומצבי חוויה.
התחילו מהרצה מוצלחת
קל יותר ליצור זרימת עבודה אחרי שהסוכן ראה את המשימה, את חומרי המקור, את המשוב שלכם ואת התוצאה המקובלת.
- תנו לסוכן משימה אמיתית ואת הקלט בפועל שהוא צריך.
- בדקו את התוצאה ותקנו הקשר חסר, חשיבה חלשה או פורמט שגוי.
- כשהתוצאה טובה, בקשו מהסוכן לחלץ את השיטה שניתן לחזור עליה.
- בקשו מהסוכן לנסח טיוטה לשם זרימת העבודה, לתיאור, להוראה ולכל קובצי עזר שהוא ממליץ עליהם.
- בדקו יחד את הטיוטה לפני שהופכים את זרימת העבודה לציבורית.
אפשר לשאול:
הפכו את מה שעשינו עכשיו לזרימת עבודה לשימוש חוזר עבור הצוות. נסחו טיוטה לשם, לתיאור ולהוראה. הפרידו את השיטה הניתנת לשימוש חוזר מהפרטים שרלוונטיים רק למקרה הזה. לפני שנאשר סופית, רשמו את ההנחות והמגבלות שאני צריך לבדוק.
זה נותן לסוכן את המשימה לנסח טיוטה. זה נותן לכם את המשימה להחליט אילו חלקים חייבים להיות בשליטה.
ההוראה היא מקום נפוץ למגבלות
הוראת זרימת העבודה נעה עם הזרימה וחלה בכל פעם שהיא רצה. לכן זהו אחד המקומות הנפוצים ביותר להגדיר בו מגבלות כמו קלטים נדרשים, מקורות מאושרים, פורמט פלט, תקני איכות ופעולות שדורשות אישור.
זה לא שכבת הבקרה היחידה:
| שכבה | על מה היא מגבילה | דוגמה |
|---|---|---|
| Description | מתי צריך לבחור בזרימת העבודה | השתמשו בפניות חדשות נכנסות שזקוקות למחקר ולהסמכה; אל תשתמשו בהזדמנויות קיימות. |
| Instruction | איך צריך לבצע את המשימה | בדקו קודם את ה־CRM, צטטו טענות ציבוריות, פעלו לפי רובריקת ה־ICP, וצרו טיוטה במקום לשלוח. |
| Files | ההפניות הקבועות שהשיטה צריכה לעקוב אחריהן | רובריקת ICP, דוגמאות מאושרות, תבנית דוח, מילון מונחים של המוצר |
| Connector permissions | אילו פעולות חיצוניות הסוכן באמת מורשה לבצע | לקרוא רשומות CRM, ליצור טיוטת אימייל, אך לא לשלוח אימייל |
| Run request | הקלט וההיקף עבור המקרה הזה בלבד | להסמיך את הליד הזה, להשתמש ברשומת CRM זו, ולהחזיר את התוצאה בצ'אט הזה. |
| Automation | מתי הזרימה רצה ומי הבעלים של ההרצה | להריץ בכל יום חול ב־09:00 ולפרסם את התוצאה בערוץ בעל שם. |
אל תסתמכו על טקסט ההוראה כתחליף לבקרות גישה. אם פעולה חייבת להיות מוגבלת טכנית, השתמשו גם בהרשאת המחבר בפועל ובהרשאות בעלות שם וגם בהוראה ברורה.
בדקו את הטיוטה הראשונה של הסוכן
אין צורך לשכתב כל משפט. התמקדו בבדיקה שלכם בהחלטות החשובות לצוות.
מתי צריך להשתמש בה?
- איזו בקשה או מצב אמורים לבחור בזרימת העבודה הזו?
- מתי הסוכן לא צריך להשתמש בה?
- האם התיאור מספיק ספציפי כדי להבדיל אותה מזרימות עבודה דומות?
איזה קלט נדרש?
- מה חבר צוות חייב לספק לפני שהעבודה מתחילה?
- אילו קלטים חסרים צריכים לגרום לסוכן לשאול שאלה?
- אילו פרטים שייכים לכל הרצה במקום להוראה הקבועה?
אילו מקורות וכללים גוברים?
- מהו מקור האמת?
- איזה קובץ מצורף מכיל את הרובריקה או התבנית המאושרות?
- אם שני מקורות מתנגשים, מי מהם מקבל עדיפות?
- איך הסוכן צריך לתייג עובדות שהוא לא יכול לאמת?
איך הפלט צריך להיראות?
- אילו סעיפים או שדות נדרשים?
- איזו רמת פירוט שימושית?
- האם הפלט צריך ציטוטים, קישורים או תווית ביטחון?
- לאן צריך להגיע התוצאה כשמוגדרת כתובת יעד?
איפה הסוכן חייב לעצור?
- אילו פעולות דורשות אישור?
- האם הסוכן צריך ליצור טיוטה במקום לשלוח או לפרסם?
- אילו נתונים לא אמורים להופיע בזרימת עבודה ציבורית או בתוצאה משותפת?
אלה המגבלות שכדאי להבהיר במפורש. תנו לסוכן לטפל בניסוח, ואז אשרו שהניסוח משקף את ההחלטה שלכם.
מבנה לסקירה משותפת
הסוכן יכול להשתמש במבנה הבא לטיוטה הראשונה שלו. התייחסו אליו כמסגרת סקירה, לא כטופס שאתם חייבים למלא בעצמכם:
# 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 מילים, אבל התאימו את הטון שלה להודעה הנכנסת.”
- “צרו את האימייל כטיוטה. לעולם אל תשלחו אותו אוטומטית.”
- “זרימת העבודה הזו לא צריכה לרוץ עבור הזדמנויות קיימות.”
בקשו מהסוכן לעדכן את זרימת העבודה ולסכם איזו מגבלה כל שינוי מתייחס אליה. כך קל יותר לזהות כלל שהובן לא נכון או הוצב בסעיף הלא נכון.
השאירו את הדברים הנכונים מחוץ להוראה
מידע מסוים לא צריך להפוך לטקסט קבוע של זרימת העבודה:
- שמות לקוחות, דדליינים חד-פעמיים ויעדים ספציפיים למקרה שייכים לבקשת ההרצה;
- סיסמאות, אסימונים ופרטי גישה פרטיים אינם שייכים להוראה או לקובץ מצורף;
- לוחות זמנים ואירועים שייכים ל־automation;
- גבולות גישה טכניים שייכים להרשאות המחבר ולרשאות בעלות שם;
- משוב אישי שרלוונטי רק לתוצאה אחת יכול להישאר בצ'אט הזה.
ההוראה צריכה לשאת את השיטה הניתנת לשימוש חוזר ואת המגבלות ההתנהגותיות, לא כל פרט שמקיף את העבודה.
בדקו ושפרו יחד
הריצו את זרימת העבודה עם לפחות שני קלטים מציאותיים, ועדיף עם חבר צוות נוסף. אחרי כל הרצה, שאלו:
- האם זרימת העבודה הופעלה עבור המשימה הנכונה?
- האם היא ביקשה את הקלטים שהייתה צריכה?
- האם היא פעלה לפי סדר העדיפויות המיועד של המקורות?
- האם הפלט היה עקבי בלי להפוך נוקשה?
- האם היא עצרה בגבול האישור הנדרש?
- האם הבעיה ניתנת לשחזור, או שהיא חלה רק על המקרה הזה?
בקשו מהסוכן לתקן את ההוראה עבור פערים שחוזרים על עצמם. השאירו תיקונים חד-פעמיים בהרצה. כשהשיטה עובדת גם עבור מישהו שאינו היוצר המקורי שלה, שתפו את זרימת העבודה עם הצוות שלכם.

