Skill טיפול באסקלציה ל-Claude

אם אתם רואים placeholder לא מוכר או צריכים לבדוק אילו כלים מחוברים, ראו CONNECTORS.md.

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

שימוש

/customer-escalation <תיאור הבעיה> [שם לקוח או חשבון]

דוגמאות:

• /customer-escalation API returning 500 errors intermittently for Acme Corp
• /customer-escalation Data export is missing rows — 3 customers reported this week
• /customer-escalation SSO login loop affecting all Enterprise customers
• /customer-escalation Customer threatening to churn over missing audit log feature

תהליך עבודה

1. הבנת הבעיה

נתחו את הקלט וקבעו:

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

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

2. איסוף הקשר

אספו מידע רלוונטי מהמקורות הזמינים:

• ~~support platform: כרטיסיות קשורות, ציר זמן התקשורת, בדיקות תקלות קודמות
• ~~CRM (אם מחובר): פרטי חשבון, אנשי קשר מרכזיים, אסקלציות קודמות
• ~~chat: דיונים פנימיים על הבעיה, דיווחים דומים מלקוחות אחרים
• ~~project tracker (אם מחובר): דוחות באגים קשורים או בקשות תכונה, סטטוס הנדסה
• ~~knowledge base: בעיות ידועות או פתרונות עקיפים, תיעוד רלוונטי

3. הערכת השפעה עסקית

תוך שימוש בממדי ההשפעה שלהלן, כמתו:

• היקף: כמה לקוחות/משתמשים מושפעים? האם זה גדל?
• עומק: חסום לחלוטין מול אי-נוחות?
• משך: כמה זמן זה קורה?
• הכנסה: ARR בסיכון? עסקאות ממתינות מושפעות?
• לחץ זמן: האם יש deadline נוקשה?

4. קביעת יעד האסקלציה

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

5. מבנה שלבי שחזור (עבור באגים)

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

6. יצירת תיק האסקלציה

## ESCALATION: [סיכום בשורה אחת]

**חומרה:** [Critical / High / Medium]
**צוות יעד:** [Engineering / Product / Security / Leadership]
**מדווח על ידי:** [שמכם/צוותכם]
**תאריך:** [תאריך היום]

### השפעה
- **לקוחות מושפעים:** [מי וכמה]
- **השפעה על זרימת עבודה:** [מה הם לא יכולים לעשות]
- **הכנסה בסיכון:** [אם רלוונטי]
- **זמן בתור:** [כמה זמן זה בעיה]

### תיאור הבעיה
[תיאור ברור ותמציתי של הבעיה — 3-5 משפטים]

### מה נוסה
1. [שלב בדיקת תקלות ותוצאה]
2. [שלב בדיקת תקלות ותוצאה]
3. [שלב בדיקת תקלות ותוצאה]

### שלבי שחזור
[אם רלוונטי — עקבו אחר הפורמט שלהלן]
1. [שלב]
2. [שלב]
3. [שלב]
Expected: [X]
Actual: [Y]
Environment: [פרטים]

### תקשורת עם הלקוח
- **עדכון אחרון ללקוח:** [תאריך ומה הועבר]
- **ציפיות הלקוח:** [מה הם מצפים ועד מתי]
- **סיכון אסקלציה:** [האם הם יסלמו הלאה אם לא ייפתר עד X?]

### מה נדרש
- [בקשה ספציפית — "חקירת סיבת שורש", "תעדוף תיקון",
  "קבלת החלטה על X", "אישור חריג ל-Y"]
- **Deadline:** [מתי נדרשת פתרון או עדכון]

### הקשר תומך
- [כרטיסיות קשורות או קישורים]
- [שרשורי דיון פנימיים]
- [תיעוד או לוגים]

7. הצעת צעדים הבאים

לאחר יצירת האסקלציה:

• "רוצים שאפרסם זאת בערוץ ~~chat של הצוות היעד?"
• "האם לעדכן את הלקוח בתגובה ביניים?"
• "רוצים שאקבע תזכורת מעקב לבדוק על כך?"
• "האם לנסח עדכון ללקוח עם הסטטוס הנוכחי?"

מתי לסלם מול לטפל בתמיכה

לטפל בתמיכה כאשר:

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

לסלם כאשר:

• טכני: באג מאושר שצריך תיקון קוד, נדרשת חקירת תשתיות, פגיעה בנתונים או אובדן
• מורכבות: הבעיה מעבר ליכולת האבחון של התמיכה, דורשת גישה שאין לתמיכה, כוללת יישום מותאם אישית
• השפעה: מספר לקוחות מושפעים, מערכת ייצור מושבתת, שלמות הנתונים בסיכון, חשש אבטחה
• עסקי: לקוח בעל ערך גבוה בסיכון, הפרת SLA ממשמשת ובאה, לקוח מבקש מעורבות הנהלה
• זמן: הבעיה פתוחה מעבר ל-SLA, הלקוח ממתין זמן בלתי סביר, ערוצי תמיכה רגילים לא מתקדמים
• דפוס: אותה בעיה מדווחת על ידי 3+ לקוחות, בעיה חוזרת שנאמר שתוקנה, חומרה גוברת לאורך זמן

דרגות אסקלציה

L1 → L2 (אסקלציה בתמיכה)

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

L2 → Engineering

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

L2 → Product

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

Any → Security

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

Any → Leadership

מ: כל דרגה (בדרך כלל L2 או מנהל) אל: הנהלת תמיכה, צוות מנהלים מתי: לקוח בעל הכנסה גבוהה מאיים לנטוש (churn), הפרת SLA בחשבון קריטי, נדרשת החלטה צולבת-פונקציות, נדרש חריג מדיניות, סיכון יחסי ציבור או משפטי מה לכלול: הקשר עסקי מלא, הכנסה בסיכון, מה נוסה, החלטה או פעולה ספציפית נדרשת, deadline

הערכת השפעה עסקית

בעת אסקלציה, כמתו את ההשפעה היכן שניתן:

ממדי השפעה

קיצור חומרה

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

כתיבת שלבי שחזור

שלבי שחזור טובים הם הדבר הבודד החשוב ביותר באסקלציה של באג. עקבו אחר שיטות אלה:

1. התחילו ממצב נקי: תארו את נקודת ההתחלה (סוג חשבון, הגדרה, הרשאות)
2. היו ספציפיים: "לחץ על כפתור ה-Export בפינה הימנית העליונה של עמוד ה-Dashboard" ולא "נסה לייצא"
3. כללו ערכים מדויקים: השתמשו בקלטים ספציפיים, תאריכים, מזהים — לא "הכנס נתונים כלשהם"
4. ציינו את הסביבה: דפדפן, מערכת הפעלה, סוג חשבון, feature flags, רמת תוכנית
5. תעדו את התדירות: ניתן לשחזור תמיד? לסירוגין? רק בתנאים מסוימים?
6. כללו ראיות: צילומי מסך, הודעות שגיאה (טקסט מדויק), לוגי רשת, פלט console
7. ציינו מה שלילתם: "נבדק ב-Chrome וב-Firefox — אותה התנהגות" "לא ספציפי לחשבון — שוחזר בחשבון בדיקה"

תדירות מעקב לאחר אסקלציה

אל תסלמו ותשכחו. שמרו על בעלות על מערכת היחסים עם הלקוח.

פעולות מעקב

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

הורדת אסקלציה

לא כל אסקלציה נשארת מסולמת. הורידו אסקלציה כאשר:

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

בעת הורדת אסקלציה:

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

שיטות עבודה מומלצות לאסקלציה

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