SOPs לסוכנים: לכתוב את ספר ההפעלה של החברה

מושג ליבההבעיהלמה SOPs אנושיים נכשלים לסוכנים

נתחיל מהכאב האופרטיבי. יש לך כבר היום נוהל כלשהו — אולי בראש, אולי בקובץ Google Docs ישן, אולי במסמך onboarding לעובדים: "כשמגיעה פנייה בתמיכה, תבדוק אם זה לקוח קיים, תענה לו בנחת, ואם זה משהו מסובך או כספי — תעביר אליי." בן אדם שיקרא את זה יבצע את זה מצוין. סוכן-AI שיקבל אותו בדיוק כלשונו ייכשל, ולא כי הוא טיפש, אלא כי הוא לוקח אותך במילה. מודל שפה לא משלים חסכים מתוך אינטואיציה אנושית.

זה ההבדל היחיד שחשוב להבין כאן: בני אדם קוראים בין השורות; סוכנים לא. כש"תענה לו בנחת" מגיע לעובד אנושי, הוא יודע אוטומטית מה זה אומר בעסק שלך — איזה טון, איזה פתיח, מתי לא לענות בכלל ולחכות לך. הסוכן לא יודע כלום מזה. הוא ינחש. ולפעמים הוא ינחש בביטחון מלא, בכיוון הלא נכון לגמרי. דוגמה מספרית: בעסק עם 200 פניות חודש, "משהו מסובך או כספי" = כ-30 פניות. בלי כלל ברור, הסוכן יטפל בעצמו בכולן, והתוצאה: 30 החלטות לא-מבוקרות בחודש, שאחת מהן מספיקה כדי להרוס לקוח או לבצע החזר שגוי. זה בדיוק מה שחברות כמו Nestr ומקורות 2026 מכנים "human SOPs don't transfer to agents unchanged" — נהלים אנושיים לא עוברים לסוכן כמו שהם, הם דורשים תרגום לשפה אגנטית.

המקור הזה (research של הקורס) מנסח את זה חד: נהלים אנושיים מניחים קריאה-בין-השורות; נהלים לסוכנים צריכים דיוק מפורש וחד-משמעי — אחרת הסוכן מאלתר בכיוון הלא נכון. וזה מוביל אותנו למונח החדש של 2026.

שים לב למתח שמלווה את כל הפרק הזה: אנחנו רוצים הרבה דיוק (כדי שהסוכן לא ינחש וימציא), אבל לא נוקשות (כדי שלא נחזיר אותו להיות סקריפט מכאני). ה-SOP האגנטי הוא בדיוק הליכה על הקו הזה. RFC 2119 הוא הכלי שמאפשר לנו ללכת עליו: אנחנו אומרים MUST איפה שאסור לסטות בשום תנאי, SHOULD איפה שיש דרך נכונה אבל שיקול דעת מותר, ו-MAY איפה שאנחנו נותנים למודל לחשוב בעצמו.

כדאי לעצור רגע על מילה אחת מהמילון שלנו: determin-ish-tic. היא נשמעת כמו בדיחה או שגיאת כתיב, אבל היא מתארת את ההחלטה החשובה ביותר בכתיבת SOP. דמיין שני קצוות קיצוניים. בקצה אחד יש סקריפט קשיח ודטרמיניסטי: "אם המייל מכיל את המילה 'החזר' — שלח את תבנית מספר 3". זה צפוי לחלוטין, אבל גם טיפש לחלוטין — לקוח שכתב "אני מבקש שתחזירו לי את הכסף" בלי המילה "החזר" יפול בין הכיסאות, ולקוח שכתב "אני לא רוצה החזר, רק שאלה" יקבל בטעות את תבנית ההחזרים. בקצה השני יש הנחיה פתוחה לחלוטין: "טפל בלקוח כמיטב הבנתך". זה גמיש, אבל בלתי-צפוי — בכל ריצה תקבל התנהגות אחרת, ולא תוכל לסמוך על התהליך או לשפר אותו. שני הקצוות האלה חסרי-תועלת ל-operator שרוצה לייצר עקביות עסקית.

ה-SOP האגנטי יושב באמצע בכוונה תחילה. הוא מבני מספיק כדי שהסוכן יעשה את אותו תהליך בכל פעם (תמיד מסווג קודם, תמיד בודק היסטוריה, תמיד מסלים פעולות כסף), אבל פתוח מספיק כדי שהסוכן יפעיל שיקול דעת בתוך כל צעד (לנסח תשובה מתאימה ללקוח הספציפי הזה, לזהות שהלקוח עצבני, להבין שהשאלה היא בעצם על נושא אחר). הסטרוקטורה היא על התהליך; הגמישות היא על התוכן. זה בדיוק מה ש-RFC 2119 קונה לך: MUST נועל את התהליך, MAY משחרר את התוכן.

מבנהFoundationאנטומיה של צעד ב-SOP אגנטי

SOP אנושי הוא בדרך כלל רשימת bullet-ים מהירה: "1. בדוק. 2. ענה. 3. הסלם." זה לא מספיק לסוכן AI, כי כל bullet מסתיר בתוכו שלוש שאלות שהבן אדם עונה עליהן לבד מאליהן: מתי הצעד הזה בכלל רץ, מה בדיוק צריך לעשות בו, ואיך בדיוק יודעים שהוא הסתיים. ה-SOP האגנטי מנסח את כל השלוש במפורש. צעד תקין מורכב מארבעה רכיבים הכרחיים:

למה זה כל-כך חשוב? כי הצעד הראשון שמרומז הוא הצעד שבו הסוכן סוטה מהתוכנית. אם השארת "ענה יפה" בלי action מפורש, הסוכן ימציא טון לבד. אם השארת צעד בלי exit criteria, הוא ימשיך לדבר ולייצר תוכן עד שיפלוט גרוטסקה. אם השארת אותו בלי נתיב escalation, הוא ינסה לפתור לבד מקרה רגיש שהיה צריך להגיע אליך ישירות. ארבעת הרכיבים סוגרים את ארבעת החורים הקלאסיים האלה.

בוא נראה את ההבדל על שורה אחת פשוטה. הנה צעד אנושי טיפוסי: "ענה ללקוח." שתי מילים, ובן אדם יודע בדיוק מה לעשות. עכשיו הנה אותו צעד בדיוק, מנוסח אגנטית עם כל ארבעת הרכיבים מלאים:

• Precondition: "אם הפנייה סווגה כ'מידע' או 'שימוש' וגם בסיס הידע (Knowledge Base) מכסה אותה."
• Action: "MUST לבסס את התשובה אך ורק על בסיס הידע (אל תמציא מידע). SHOULD לפתוח בשם הלקוח ולענות בשפת הפנייה. MAY לצרף קישור למאמר עזרה רלוונטי."
• Exit criteria: "התשובה נשלחה בהצלחה והפנייה סומנה בתגית 'נפתרה'."
• On failure: "אם בסיס הידע לא מכסה את השאלה → MUST להסלים ל-operator, MUST NOT לנחש או להמציא תשובה."

שים לב כמה ידע "מובן מאליו" היה חבוי בתוך המילים "ענה ללקוח": שצריך קודם לוודא שיש כיסוי בבסיס הידע, שאסור בתכלית להמציא מידע, שעונים בשפת הלקוח, ושיש מצב שבו לא עונים אלא מסלימים. כל אלה היו בראש שלך. עכשיו הם בקובץ טקסט מסודר — וזה בדיוק ההבדל בין סוכן שאפשר לסמוך עליו בעיניים עצומות לסוכן שמפתיע אותך לרעה באמצע הלילה.

הפורמט2026הפורמט של 2026: Markdown + RFC 2119

החדשות הטובות: אתה לא צריך להמציא את הפורמט או לתכנת אותו מאפס. ב-2026 נוצר תקן דה-פקטו, ו-AWS Open Source פרסמו אותו כ-Strands Agent SOPs (הריפו הציבורי strands-agents/agent-sop): natural-language Markdown workflows שמשתמשים ב-RFC 2119. למה דווקא Markdown? כי הוא קריא היטב לאדם וגם למודל, נשמר נקי ב-git (אפשר לעשות עליו diff קלאסי), ולא דורש שום כלי תכנות מיוחד. למה דווקא RFC 2119? כי המילים MUST/SHOULD/MAY מוכרות למודלים מאלפי מסמכים טכניים שהם נחשפו אליהם באימון — הן אות חד-משמעי ובינלאומי של רמת-חובה.

הנה השלד של SOP אגנטי בפורמט הזה. שמור אותו כתבנית מאסטר — כל סוכן בצי שלך ייכתב לפיה:

## SOP: <שם התפקיד>
**Role:** <מי הסוכן, הועתק מ-role spec בפרק 2>
**Goal:** <מה הוא מנסה למקסם>
**Scope of authority:** <מה מותר לו לבד / מה דורש אישור>
**Tools:** <במה הוא נוגע - מערכות, תוכנות>
**Escalation:** <למי ובאיזה תנאי הוא פונה>

### Step 1 — <שם הצעד>
- **Precondition:** <מתי הצעד רץ>
- **Action:**
  - MUST <פעולת חובה שאסור לסטות ממנה>
  - SHOULD <פעולה מומלצת>
  - MAY <פעולת רשות>
- **Exit criteria:** <איך יודעים שהסתיים בהצלחה>
- **On failure:** <MUST escalate to ... / fallback / human approval>

### Step 2 — ...

אבחוןSkillשלושת כשלי ה-"SOP אנושי" — וכיצד לתקן

לפני שנכתוב SOP מלא לתפקיד שלך, בוא נחדד את העין שלך לשלושת הכשלים הקלאסיים שהופכים נוהל אנושי טוב לנוהל אגנטי גרוע ובלתי-צפוי. כל אחד מהם הוא "קריאה בין השורות" שאתה עושה אוטומטית והסוכן לא יכול לעשות.

כשל 1 — קריאה בין השורות (Implicit Context)

הנוהל האנושי מניח ידע עסקי שלא נכתב. "החזר לפי המדיניות שלנו" — איזו מדיניות בדיוק? היכן היא מתועדת? הבן אדם יודע או יודע לשאול; הסוכן צריך שתצמיד לו את המידע פיזית. תיקון: כל פנייה ל"מדיניות / טון / ICP / כללי הבית" חייבת להיות מקושרת או מוצמדת כטקסט מלא בתוך ה-SOP עצמו (או בקובץ נפרד ב-.context/ שה-SOP מפנה אליו במפורש בשמו).

כשל 2 — צעדים מרומזים (Skipped Steps)

הבן אדם מדלג על צעד "מובן מאליו" שבשבילו שקוף. "ענה ללקוח" — אבל לפני שעונים, בן אדם תמיד בודק קודם את חלון התפעול, וודא שלא ענו לפנייה הזו במייל אחר, ובודק אם הלקוח עצבני. הצעדים האלה לא נכתבו כי הם "ברורים מאליהם". לסוכן הם לא ברורים, והוא ייתן תשובה כפולה או יתעלם מטון הלקוח. תיקון: כתוב את הצעד ה"מובן מאליו" במפורש כ-Step נפרד לחלוטין עם precondition משלו. אם בודקים היסטוריה — זה Step 0.

כשל 3 — החלטות שלא נוסחו (Un-stated Decision Rules)

הנוהל אומר "ענה אם זה פשוט, הסלם אליי אם זה מסובך" — בלי להגדיר בכלל מה פשוט ומה מסובך. הבן אדם מרגיש את הגבול בבטן; הסוכן צריך כלל ברור ובדיד. תיקון: הפוך כל "אם זה X" לכלל ניתן-לבדיקה (testable condition): "מסובך = הפנייה כוללת בקשת החזר כספי מעל 100 ש"ח, או אזכור עורך-דין, או שלוש הודעות ויותר בלי פתרון."

תרגיל 1פלט: דוח אבחוןתרגיל 1 — אבחן את הנוהל הקיים שלך

דוגמה מודרכתSupportדוגמה מודרכת #1: SOP לסוכן תמיכה

נכתוב עכשיו SOP מלא לסוכן תמיכה, צעד-אחר-צעד, כדי שתראה את כל הרכיבים והעקרונות עובדים יחד בהרמוניה. זהו worked example מייצג — התאם את הכללים לעסק שלך. סכומי הכסף וההגדרות הם דוגמה בלבד, לא ייעוץ משפטי.

## SOP: Support Agent (תמיכה)
**Role:** נציג/ת תמיכה ראשונה לפניות לקוחות בערוצי המייל וה-WhatsApp.
**Goal:** לפתור עצמאית פניות פשוטות במהירות ובטון המותג, ולהסלים נכון את המסוכנות.
**Scope of authority:** MAY לענות עצמאית על פניות מידע/שימוש.
  MUST לקבל אישור operator לכל פעולה שנוגעת בכסף (החזר, זיכוי, ביטול חיוב).
**Tools:** מערכת הטיקטים (קריאה/כתיבה), בסיס הידע (קריאה בלבד).
**Escalation:** operator (אתה), לפי הכללים למטה.
**Context files:** brand-voice.md, refund-policy.md, icp.md  ב-.context/

### Step 1 — Classify & Check (סיווג ובדיקה)
- Precondition: התקבלה פנייה חדשה שטרם טופלה.
- Action:
  - MUST לסווג את הפנייה לאחת מ: [מידע, שימוש, תקלה, כסף, אחר].
  - MUST לבדוק אם קיימת היסטוריה לאותו לקוח/פנייה לפני כל מענה.
  - SHOULD לזהות את שפת הפנייה ולענות באותה שפה.
- Exit criteria: לפנייה הוצמד תג-סיווג חד-משמעי ונבדקה היסטוריה.
- On failure: אם הסיווג לא חד-משמעי → MUST לתייג "אחר" ולהסלים.

### Step 2 — Resolve or Escalate (פתור או הסלם)
- Precondition: הפנייה סווגה ב-Step 1.
- Action:
  - אם הסיווג ב-[מידע, שימוש] ויש כיסוי בבסיס הידע → MAY לענות עצמאית.
  - אם הסיווג = כסף → MUST להסלים ל-operator; MUST NOT לבצע החזר/זיכוי לבד.
  - אם זוהה אות-סיכון (אזכור עו"ד / איום בביקורת ציבורית / 3+ הודעות בלי פתרון) → MUST להסלים.
  - SHOULD לפתוח את התשובה בשם הלקוח; הטון מוגדר ב-brand-voice.md.
- Exit criteria: נשלחה תשובה ללקוח, או הפנייה סומנה "מוסלם ל-operator".
- On failure: אם בסיס הידע לא מכסה את השאלה → MUST להסלים, MUST NOT לנחש תשובה.

### Step 3 — Log a lesson (תיעוד לקח)
- Precondition: הפנייה נסגרה או הוסלמה (סיום 2).
- Action:
  - MUST לכתוב שורת-לקח קצרה לקובץ .context/lessons/support.md.
  - פורמט: תאריך | סיווג | מה הלקוח ביקש | מה עשינו | מה כדאי לעשות בפעם הבאה.
- Exit criteria: נוספה שורת-לקח אחת לפחות.
- On failure: ללא — צעד זה תמיד רץ ולא נכשל.

שים לב לשלושה דברים קריטיים שעשינו כאן. ראשית, Step 1 הוא הצעד ה"מובן מאליו" (סיווג + בדיקת היסטוריה) שכתבנו במפורש ולא הנחנו שיקרה — כשל 2 נסגר. שנית, כל החלטת "פשוט/מסוכן/מסובך" הומרה לכלל בדיד ומתמטי ("אות-סיכון = אזכור עו"ד או 3+ הודעות") — כשל 3 נסגר. שלישית, Step 3 הוא זרע ה-reflexion של פרק 4: כל פנייה כותבת שורת-לקח ל-.context/lessons/, ושם נבנה בפרק הבא ה-loop שמשפר את הסוכן אוטומטית בלילה לפי הלקחים שהוא עצמו אסף.

דוגמה מודרכתSDRדוגמה מודרכת #2: SOP לסוכן SDR (מכירות נכנסות)

הדוגמה השנייה מציגה תבנית ארכיטקטונית שונה וקריטית: כאן ה-SOP מסתיים ב-approval gate (שער אישור) — הסוכן עושה את כל העבודה הכבדה והאינטליגנטית (זיהוי ליד, סינון מול פרופיל מוצר, העשרת נתונים, ניסוח הודעה), אבל לא שולח כלום בעצמו לפני אישור שלך. זהו הדפוס הנכון לכל פעולה שיוצרת קשר חיצוני חדש בשם העסק.

## SOP: SDR Agent (מכירות נכנסות)
**Role:** סוכן שמטפל בלידים נכנסים מטופס האתר ומה-inbox המשותף.
**Goal:** לסנן לידים מול ICP, להעשיר, ולהכין טיוטת פנייה מותאמת — בלי לשלוח לבד.
**Scope of authority:** MAY לסווג ולהעשיר לידים עצמאית.
  MUST NOT לשלוח הודעת outreach ללא אישור operator.
**Tools:** טופס/inbox (קריאה), CRM (כתיבה), כלי העשרה חיצוניים (קריאה).
**Escalation / approval:** כל outreach יוצא → תור אישור של operator (אתה).
**Context files:** icp.md, outreach-templates.md  ב-.context/

### Step 1 — Watch & Capture (איסוף)
- Precondition: התקבל ליד חדש בטופס או ב-inbox.
- Action:
  - MUST לחלץ: שם מלא, חברה, ערוץ תקשורת, וטקסט הפנייה המקורי.
  - MUST לכתוב את הליד ל-CRM עם תגית "new".
- Exit criteria: הליד קיים ב-CRM עם השדות המינימליים האלו.
- On failure: אם חסר שדה חובה (כמו שם/חברה) → MAY לסמן "incomplete" ולהמשיך.

### Step 2 — Qualify vs ICP (סינון)
- Precondition: הליד נקלט ב-Step 1.
- Action:
  - MUST להשוות את הליד מול קובץ icp.md.
  - MUST לתת ציון fit בינארי או מספרי: [strong / weak / out].
  - אם out → MUST לסמן ב-CRM "disqualified" ולעצור את התהליך.
- Exit criteria: לליד הוצמד ציון fit מנומק.
- On failure: אם המידע חלקי ולא ניתן להכריע → MUST לתת "weak" (לא "strong") ולהמשיך.

### Step 3 — Enrich (העשרה)
- Precondition: ציון fit הוא [strong, weak].
- Action:
  - SHOULD להוסיף הקשר עסקי ציבורי (אתר חברה, תחום עיסוק).
  - MUST NOT להמציא נתונים שלא נמצאו בפועל — MAY לסמן "unverified".
- Exit criteria: לליד יש לפחות שדה הקשר אחד או סימון "no-enrichment".

### Step 4 — Draft outreach → Approval gate
- Precondition: fit = strong בלבד.
- Action:
  - MUST לנסח טיוטת פנייה מתוך outreach-templates.md, מותאמת אישית לליד.
  - MUST להגיש את הטיוטה לתור-אישור של operator במערכת.
  - MUST NOT לשלוח או לפרסם לפני אישור מפורש מה-operator.
- Exit criteria: הטיוטה נמצאת בסטטוס "ממתינה לאישור".
- On failure: אם אין תבנית מתאימה בקובץ → MUST להסלים ל-operator.

שתי נקודות עיצוב חשובות מאוד כאן. ראשית, ה-approval gate הוא צעד מפורש ופעיל ב-SOP, הוא לא הערה בצד. Step 4 מסתיים ב"ממתין לאישור" — זהו סטטוס, לא פעולת סיום. שנית, שים לב ל-MUST NOT החוזרים: "אל תשלח לבד", "אל תמציא נתונים". איסורים מפורשים חשובים בדיוק כמו פקודות חיוביות — הם מגדירים את גבול ה-scope מבפנים ומונעים מהסוכן "להתלהב" ולשלוח מייל גרוע בשמך. בפרק 5 נראה איך ה-gate הזה הופך לפעולה אמיתית בתור-אישור עם named approver וסף סיכון.

אחסוןgitאחסון כ-Version Control: תבנית ה-.context/

SOP שיושב ב-Google Docs, ב-Notion או בצ'אט הוא לא "מוח חברה" — הוא פתק דביק. ההרגל שמבדיל operator חובבן מ-operator שמנהל צי אמיתי הוא לשמור את כל הנהלים, התפקידים וההגדרות כ-Markdown ב-git, לפי תבנית .context/ שהריפו gru-ai (MIT) הפך לסטנדרט מוביל. למה המעבר הזה קריטי לעסק שלך:

• Forkable (ניתן לשכפול זריז) — אפשר לשכפל את כל ה"חברה" (SOPs + roles + lessons learned) לעסק חדש, לקוח חדש או קו מוצר חדש בפקודת git clone אחת. אתה בונה מערכת הפעלה, לא סתם מסמך.
• Diff-able (ניתן להשוואה) — כל שינוי בנוהל מתועד ועוקב. אתה רואה בדיוק מה שינית, מתי, ולמה — בדיוק כמו קוד תוכנה. אם סוכן מתחיל להזות, אתה יודע בדיוק איזה commit שבר אותו.
• Recoverable (ניתן לשחזור) — עריכת SOP גרועה שהתגלתה כטעות היא git revert אחד משחזור. זו רשת הביטחון התפעולית של צי של אחד שלא יכול להרשות לעצמו זמן שבתה.

מבנה תיקיות מומלץ לעסק שלך (דוגמה מייצגת, בהשראת תבנית gru-ai שמאפשרת ניהול סטנדרטי):

.context/
├── org-chart.md          # מפרק 2: כל התפקידים והקשרים ביניהם
├── roles/
│   ├── support.md        # role spec מלא לתמיכה
│   └── sdr.md            # role spec מלא ל-SDR
├── sops/
│   ├── support.sop.md    # ה-SOP מהפרק הזה
│   └── sdr.sop.md
├── policies/
│   ├── brand-voice.md    # ההקשר שהצמדנו (תיקון לכשל 1)
│   ├── refund-policy.md  # מדיניות החזרים כספיים
│   └── icp.md            # פרופיל לקוח אידיאלי
└── lessons/
    └── support.md        # שורות-לקח (זרע ל-reflexion אוטומטי, פרק 4)

תרגיל 2פלט: SOP מלא ב-gitתרגיל 2 — כתוב את ה-SOP המלא ושמור ב-git

אוטומציהSkillsמ-SOP ל-Claude Code Skill: הסוכן טוען לבד

עד כאן יש לך נוהל מצוין ומדויק שמור ב-git. אבל מי קורא אותו בזמן אמת? אם אתה צריך להדביק את ה-SOP לתוך הצ'אט מחדש בכל פעם שיש פנייה — חזרת להיות צוואר הבקבוק של העסק. הצעד הבא במודל האופרטיבי הוא להפוך את ה-SOP ל-Claude Code Skill: קובץ-תהליך ש-Claude Code מזהה לבד ומרים בעת הצורך, בלי שתצטרך לבקש זאת ממנו אי פעם. דוגמה קונקרטית: אתה כותב לסוכן "התקבלה פנייה חדשה: לקוח מבקש החזר על חיוב חודשי של 240 ש"ח" — המערכת מזהה התאמה סמנטית ל-description של support-agent-sop, טוענת את ה-SOP לבד, מריצה Step 1 (Classify), רואה אות-סיכון כספי, ועוצרת לקרוא לך במקום לבצע החזר בעצמה.

כפי שמקור הקורס מנסח זאת: Skill הוא בדיוק "מסמך תהליך לשימוש חוזר — בעצם SOP לסוכן שלך". כותבים את התהליך פעם אחת כקובץ עם תגית מתאימה, והסוכן טוען אותו אוטומטית להקשר שלו כשהמשימה רלוונטית. ההמרה של ה-SOP שלך ל-Skill היא פשוטה להפליא: ה-SOP הוא כמעט ה-Skill; כל מה שצריך לעשות הוא להוסיף לו כותרת-מטא (front-matter) קצרה שמסבירה מתי להפעיל אותו, כדי שהמודל יידע לזהות שהקובץ הזה רלוונטי למשימה שהגיעה.

---
name: support-agent-sop
description: |
  טען את הקובץ הזה כשמגיעה פנייה חדשה מלקוח (מייל/WhatsApp) 
  שדורשת סיווג, מענה ראשון, או החלטת הסלמה. 
  זהו נוהל התמיכה המלא והרשמי של החברה.
---

# <כאן בא בדיוק תוכן ה-SOP מ-support.sop.md שכתבת בתרגיל 2>
## Step 1 — Classify ...
## Step 2 — Resolve or Escalate ...
## Step 3 — Log a lesson ...

ה-description היא לב המערכת האוטומטית שלך. היא לא תיעוד בשבילך (בשבילך יש את ה-git log) — היא הטריגר. ככל שהיא מנוסחת מדויק יותר ("טען כשמגיעה פנייה שצריכה סיווג או הסלמה"), כך הסוכן מרים את ה-Skill הנכון בזמן הנכון, בלי שתתערב. description עמומה או קצרה מדי = הסוכן לא יודע מתי זה רלוונטי = חזרת להדביק ידנית טקסטים ולבזבז זמן.

תרגיל 3פלט: Skill פעילתרגיל 3 — הפוך את ה-SOP ל-Skill ובדוק שהוא נטען אוטומטית

אימותSkillDry-run לפני Live: בדוק את ה-SOP על מקרים אמיתיים

זו הנקודה שמפרידה בין operator זהיר ל-operator שלומד את החורים במערכת שלו מלקוחות זועמים באמצע הלילה. לעולם ובשום תנאי אל תשגר SOP ל-live (פרודקשן) בלי dry-run. dry-run פירושו הלכה למעשה: לקחת 3–5 מקרים אמיתיים מהחודש שעבר (פניות תמיכה שכבר טיפלת בהן בעצמך, לידים שכבר קיבלת ודחית או אישרת — מקרים שאתה כבר יודע בוודאות מה הייתה התשובה הנכונה), ולהריץ עליהם את ה-SOP בלי לבצע שום פעולה אמיתית כלפי חוץ. הסוכן פשוט מתאר מה הוא היה עושה צעד אחרי צעד. אתה משווה: מה הסוכן עשה מול מה שהיה צריך לקרות במציאות.

למה דווקא מקרים אמיתיים מהעבר? כי הם קרקע אמת חינמית ומושלמת — אתה כבר יודע את התשובה הנכונה, אז כל פער בין מה שהסוכן עשה לבין מה שקרה באמת הוא חור שנתגלה לפני שלקוח חי נופל בו. ובונוס ענק ומרכזי לקורס שלנו: 3–5 המקרים האלה, עם התשובות הנכונות שלהם, הם בדיוק הזרע ל-golden dataset של פרק 4. אתה לא בונה חומרי בדיקה פעמיים — מה שאתה אוסף כאן ל-dry-run הופך לסט-הזהב שה-eval gate ינקד מולו בעתיד.

תרגיל 4פלט: דוח dry-runתרגיל 4 — Dry-run על 3–5 מקרים אמיתיים

הקשר מקומיעבריתההקשר הישראלי: SOP שעובד בעברית

סוכן תמיכה או מכירות שמשרת לקוחות SMB בישראל עובד בשפה העברית — וזה לא טריוויאלי למודל שפה. שלושה ניואנסים מקומיים שכדאי לקבע ישירות ב-SOP שלך כדי שהוא יישמע אנושי ולא כמו תרגום גרוע:

• טון ופנייה ישירה. עברית עסקית-ישראלית מאזנת בין רשמיות לחמימות ולעיתים ישירות בוטה. קבע ב-brand-voice.md אם הסוכן פונה בלשון יחיד/רבים, משתמש ב"אתה" או "אתם", ובאיזו רמת פורמליות. הוסף ל-SOP הוראה נוקשה: SHOULD לענות בעברית תקנית, בטון שמוגדר ב-brand-voice.md.
• זיהוי והתאמת שפה (Code-switching). לקוח ישראלי עשוי לכתוב חצי משפט בעברית וחצי באנגלית, או להשתמש במונחים טכניים באנגלית בתוך טקסט עברי (למשל "איפה אני עושה את ה-login?"). הוסף כלל: MUST לזהות את שפת הפנייה ולענות באותה שפה באופן רציף — אחרת הסוכן עלול לענות באנגלית תקנית למי ששאל בעברית משובשת, מה שייצור ניכור מיידי.
• סוכן עברי כיתרון תחרותי. הערת research של הקורס: סוכני תמיכה/מכירות בעברית הם בידול אמיתי בשוק ה-SMB הישראלי. ה-SOP העברי המוקפד שאתה כותב כאן הוא לא רק נוהל פנימי — הוא נכס תחרותי שקשה לחקות. סוכנות שירות אנושית של 5 אנשים מתמחרת פעולות כאלה בעשרות אלפי שקלים לחודש, בעוד operator סולו עם SOP עברי מוצלח מספק שירות זהה בחלק קטן מהמחיר, 24/7.

בדיקה עצמיתבדוק את עצמך

סיכוםגשר לפרק 4סיכום הפרק וגשר קדימה

צ'קליסטסיוםצ'קליסט סיום פרק

• אבחנתי את הנוהל האנושי הקיים שלי דרך מבחן שלושת ה-W (assumed / skipped / undefined) ומיפיתי את הכשלים בטבלה.
• זיהיתי לפחות שלושה מקומות של "מובן מאליו" בתהליך הנוכחי שלי והמרתי כל אחד לכלל מפורש וברור ב-SOP.
• כתבתי SOP אגנטי מלא עם 3+ צעדים, כשלכל צעד יש באופן מלא את ארבעת הרכיבים (precondition / action / exit / escalation).
• השתמשתי בכל מקום רלוונטי בתקני RFC 2119 (MUST / SHOULD / MAY) ולא בניסוח אחיד וגנרי של "תעשה" שאינו מבדיל בין רמות חומרה.
• הוספתי ל-SOP לפחות שני MUST NOT ברורים שמגדירים מה הסוכן לעולם לא עושה לבד (למשל, פעולות כספיות).
• הגדרתי escalation path (נתיב הסלמה) לכל פעולה שנוגעת בכסף/הרשאות/בלתי-הפיכה (מחובר ל-scope of authority מפרק 2).
• הקמתי תיקיית .context/ ב-git והצמדתי אליה קבצי policies (כמו brand-voice / refund / icp) למניעת כשלי הקשר.
• ביצעתי git commit מסודר ל-SOP הראשוני ולכל תיקון שנעשה בהמשך — "מוח החברה" מקובע, מתועד ושחזיר.
• הפכתי SOP אחד ל-Claude Code Skill עם description בסגנון טריגר ברור, ואימתתי בשיחה נקייה שהסוכן טוען אותו לבד בעת הצורך.
• הרצתי dry-run מלא על 3–5 מקרים אמיתיים מהחודש שעבר ותיקנתי ב-SOP (עם commit) כל פער משמעותי שנמצא בהם.
• שמרתי את 3–5 המקרים עם התשובות הנכונות כקובץ golden.md בתיקייה ייעודית — מוכן ל-eval gate של פרק 4.
• התאמתי את ה-SOP לשוק הישראלי (טון נכון, זיהוי והתאמת שפה) אם הסוכן משרת לקוחות ישראלים בעברית.
• ודאתי לבסוף שאף פעולה שנוגעת בכסף, מכירה או חשבונית לא רצה לבד באופן אוטונומי לחלוטין — היא תמיד תחת MUST + approval gate אנושי.