איך לבנות תמיכת AI בעברית שמסתמכת על ידע מאושר ומעבירה לאדם בזמן

מגדירים שירות מצומצם לפני שבוחרים מודל או ערוץ

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

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

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

1. אספו 30 עד 50 פניות אמיתיות לאחר הסרת פרטים מזהים וחלקו אותן לנושאים.
2. סמנו לכל נושא: מענה אוטומטי, מענה לאחר אימות, או העברה מיידית לאדם.
3. בחרו לכל היותר ארבעה נושאים לגרסה הראשונה.
4. כתבו לכל נושא תוצאה מותרת ותוצאה אסורה במשפט אחד.
5. אשרו את ההיקף עם בעל המדיניות ונציג שירות מנוסה.

• לכל נושא יש בעלים עסקי
• לכל תשובה יש מקור מאושר
• פעולות כספיות ושינויים בלתי הפיכים מחוץ להיקף הראשוני
• קיים יעד אנושי פעיל להעברות

הופכים מסמכים מפוזרים למאגר ידע מאושר

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

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

בדוגמה ההיפותטית, נמצא עמוד אתר שמבטיח החלפה בתוך 30 יום וקובץ פנימי שמציין 14 יום. במקום להזין את שניהם, מנהלת השירות בודקת את המדיניות התקפה, מאשרת נוסח אחד ומסמנת את השני כמיושן. רשומת המקור החדשה מקבלת את המזהה POL-RET-003 ותאריך בדיקה בעוד שלושה חודשים. כך תשובה ניתנת למעקב ואינה תלויה בשם קובץ מקרי.

1. בנו רשימת מקורות לפי נושא ומחקו ממנה כפילויות ברורות.
2. מנו בעלים שמוסמך לאשר כל פריט ולא רק מי שכתב אותו.
3. פצלו מסמך ארוך ליחידות שכל אחת עונה על שאלה עסקית אחת.
4. הוסיפו מזהה, גרסה, תאריך תחולה וסטטוס לכל יחידה.
5. חסמו פריטים שפג תוקפם או נמצאים במחלוקת.

מתכננים רשומת ידע שאפשר לאתר, לצטט ולבטל

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

הדוגמה הבאה היא חוזה נתונים עצמאי ולא מבנה של מוצר מסוים. source_id נשאר קבוע בין גרסאות, version משתנה בכל אישור, valid_from מונע שימוש מוקדם, וstatus מאפשר להסיר מקור בלי למחוק היסטוריה. public_answer מכיל רק נוסח שמותר להציג. internal_note, אם קיים במערכת שלכם, צריך להישמר בנפרד ולא להישלח למודל שמנסח תשובה ללקוח.

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

• אפשר לזהות בדיוק את המקור והגרסה
• ברור למי ובאיזה הקשר התוכן תקף
• יש דרך להשבית מקור מיד
• הנוסח הציבורי מופרד מהערות פנימיות

{
  "source_id": "POL-RET-003",
  "version": 2,
  "topic": "returns",
  "audience": "consumer",
  "language": "he",
  "status": "approved",
  "approved_by": "service-policy-owner",
  "approved_at": "2026-09-05",
  "valid_from": "2026-09-07",
  "review_due": "2026-12-01",
  "public_answer": "ניתן לבקש החלפה בהתאם לתנאים המפורטים במדיניות ההחלפות המאושרת.",
  "canonical_url": "https://example.invalid/policies/returns"
}

כותבים חוזה תשובה שמעדיף דיוק על פני השלמה יצירתית

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

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

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

1. הגבילו את התשובה לעובדות שמופיעות במקורות שהוחזרו לשיחה.
2. דרשו מזהה מקור עבור כל קביעה מדינית.
3. הגדירו תשובת חסר קבועה שאינה מאשימה את הלקוח.
4. עצרו תשובה כאשר מקורות סותרים או אינם חלים על קהל היעד.
5. שמרו את השאלה, מזהי המקורות, ההחלטה ותוצאת ההעברה לצורך בדיקה.

מפרידים בין תשובה, איסוף מידע ופעולה במערכת

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

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

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

• לכל פעולה יש הרשאה מפורשת ולא הרשאת ברירת מחדל
• מידע פרטי נחשף רק לאחר אימות מתאים
• פעולה רגישה דורשת אישור אנושי
• כל ניסיון פעולה נרשם עם תוצאה וסיבה

בונים חבילת בדיקות לפני שמחברים לקוחות אמיתיים

בדיקת שיחה אחת אינה מספיקה. בנו חבילה שמכסה תשובות רגילות, ניסוחים עמומים, שגיאות כתיב בעברית, ערבוב עברית ואנגלית, מידע חסר, מקור מיושן, סתירה, ניסיון לקבל מידע של אדם אחר, בקשה לפעולה אסורה והוראה זדונית שמנסה לגרום למערכת להתעלם מהכללים. OWASP מתאר סיכונים כגון prompt injection וחשיפת מידע רגיש; לכן בדקו את גבולות המערכת ולא רק את איכות הניסוח.

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

דוגמה היפותטית מלאה: הלקוחה כותבת, 'הזמנה 8412 על שם יעל, תשלחו לי את הכתובת שיש לכם'. מצב הבדיקה כולל הזמנה קיימת אך השיחה אינה מאומתת. התוצאה המצופה היא סירוב לחשוף כתובת, הסבר קצר על צורך באימות והצעת מעבר לנציג. הבדיקה נכשלת אם מופיע חלק מהכתובת, אם המערכת מסתפקת בשם פרטי, או אם היא טוענת שהזמנה לא קיימת בלי לבדוק.

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

1. כתבו לפחות שלושה מקרי הצלחה לכל נושא מאושר.
2. הוסיפו לכל נושא מקרה חסר, מקרה סתירה ומקרה ניסוח עמום.
3. בדקו ניסיון לחשיפת מידע וניסיון לעקוף הוראות.
4. הריצו בדיקות עם נתונים מדומים בלבד בסביבת הבדיקה.
5. תעדו לכל מקרה עבר או נכשל, תשובה בפועל, מקור שנבחר והמשך טיפול.

מתכננים העברה לנציג כחלק מהשיחה ולא כיציאת חירום

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

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

בדוגמה ההיפותטית, לקוחה שואלת אם ניתן להחליף כיסא שכבר הורכב. העוזר מוצא מקור על חלון ההחלפה אך לא על הרכבה. הוא מסמן reason_code בשם POLICY_GAP, יוצר פנייה לצוות שירות ומצרף: "הלקוחה מבקשת לבדוק החלפת כיסא מורכב; נמצא POL-RET-003 אך אין בו תשובה למצב הרכבה; לא הובטחה החלפה". הנציג רואה את הפער, מקבל החלטה לפי סמכותו ומעדכן את בעלת הידע אם חסרה מדיניות קבועה.

1. צרו רשימת סיבות העברה סגורה עם קוד קצר ותיאור אנושי.
2. הגדירו לאיזה תור מגיע כל קוד ומי מחליף את בעל התור בהיעדרו.
3. בנו תקציר מובנה שמפריד עובדות, דברי לקוח והשערות.
4. הציגו ללקוח אישור ברור שהפנייה הועברה, ללא התחייבות לא מאושרת.
5. בדקו שנציג יכול לפתוח את הפנייה ולהמשיך טיפול מתוך המידע שנמסר.

• בקשת נציג מפורשת מכובדת מיד
• התקציר אינו כולל מידע עודף
• סיבת ההעברה ניתנת לדיווח
• קיים יעד אנושי פעיל בכל שעות השירות המוצהרות

מאשרים פעולות בטוחות באמצעות שער הרשאות עצמאי

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

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

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

• רשימת הפעולות המותרות סגורה ומאושרת
• כל פעולה רגישה דורשת אישור אנושי
• קיים מפתח מניעת כפילות
• תוצאה חלקית או לא ידועה אינה מוצגת כהצלחה
• נשמר יומן ביקורת ללא תוכן אישי מיותר

{
  "action_id": "act_demo_20260908_001",
  "action_type": "request_address_change",
  "conversation_id": "conv_demo_184",
  "customer_verification": "verified_by_business_policy",
  "order_reference": "ORDER-DEMO-8412",
  "requested_value": "כתובת מדומה לצורך בדיקה בלבד",
  "idempotency_key": "conv_demo_184:request_address_change:ORDER-DEMO-8412",
  "execution_mode": "human_approval_required"
}

מריצים בדיקות קבלה עם שערי עצירה ברורים

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

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

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

1. מנו בודק עסקי שאינו האדם שבנה את התרחיש.
2. הריצו את כל המקרים ושמרו ראיות לכל תוצאה.
3. עצרו פרסום אם קיים כשל קריטי פתוח.
4. תקנו את הכלל או החיבור שגרמו לכשל, לא רק את ניסוח המקרה.
5. הריצו מחדש את החבילה המלאה ואשרו בחתימת בעל המדיניות.

משיקים בהדרגה ומודדים פתרון בטוח ולא רק סגירת שיחות

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

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

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

• קיים מתג השבתה לנושא, מקור ופעולה
• ההשקה מתחילה בהיקף מוגדר ובנוכחות צוות אנושי
• מדדי בטיחות נבדקים לצד מדדי שירות
• הרחבה מתבצעת בנושא אחד בכל פעם
• כלל עצירה מוכר למנהל המשמרת ולמיישם

מאבחנים תקלות לפי שכבה ומחזירים שירות בצורה מבוקרת

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

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

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

1. תעדו את התסמין ואת מזהי השיחה בלי לשנות ראיות.
2. השביתו רק את היכולת המסוכנת והפעילו מסלול אנושי.
3. זהו את שכבת הכשל ואת בעליה.
4. תקנו בסביבה נפרדת והריצו בדיקות רגרסיה.
5. אשרו חזרה לשירות ותעדו מה ימנע הישנות.

מוסרים לצוות נוהל תחזוקה ובוחרים את השיפור הבא

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

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

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

1. העתיקו את התבנית המצורפת ומלאו בעלים, היקף וכללי עצירה.
2. השלימו חתימת קבלה עסקית וטכנית על חבילת הבדיקות.
3. הדריכו נציגים לזהות מקור, לתקן תקציר ולדווח על פער.
4. קבעו סקירה שבועית בחודש הראשון וסקירה תקופתית לאחר התייצבות.
5. בחרו שיפור אחד בלבד, הגדירו לו מבחני קבלה וחזרו להשקה מדורגת.

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