בקש סיכום וסיווג (טריאג' כרטיסים)

רווחים:

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

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

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

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

למה סיכום מובנה?

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

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

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

שלב אחר שלב: הקמת תכנית טריאז'

1. הצמד את רשימת הקטגוריות. אל תתנו לדגם להתאים; תן רשימה סגורה.
2. הגדירו את קריטריון הדחיפות. קונקרטי מה המשמעות של "קריטי": שירות הופסק לחלוטין, אובדן תשלום, סיכון אבטחה.
3. זיהוי תוויות רגש. השתמש בסט מוגבל וברור.
4. ייבא את פורמט הפלט. עבור עיבוד אצווה, JSON (פורמט נתונים קריאת מכונה המורכב מזוגות שדה-ערך) מתאים, עבור בקשה בודדת, טבלה מתאימה.
5. עשה כלל "סימון אם לא בטוח". אם הדגם לא בטוח בקטגוריה, תנו לו לומר לא בטוח והאדם יראה.
6. לְאַמֵת. באצווה הראשונה, בדוק ידנית את דיוק התוויות והגדר את ההנחיה.

הנחיות הניתנות להעתקה

הנחיה בסיסית הממירה בקשה בודדת לסיכום מובנה:

תפקיד: אתה מומחה לטריאג' תמיכה מנוסה. נתח את בקשת הלקוח למטה. הוסף תגובה; פשוט הסתמכו על מה שכתוב בטקסט. מלאו את השדות הבאים:- סיכום: (מקסימום משפט 1)- קטגוריה: [משלוח | חזור | תשלום | טכני | מידע על המוצר | תלונה | הזדמנות מכירה]- דחיפות: [קריטית | גבוה | בינוני | נמוך]- רגש: [כועס | אכזבה | ניטרלי | מרוצה]- Next_step: (משפט בודד, פעולה קונקרטית)- לא בטוח: ("כן" אם הקטגוריה/דחיפות לא ברורה, אחרת "לא") בקשה:"""{{ request_text }}"""

עבור עיבוד אצווה, ההנחיה ממירה מספר בקשות למערך JSON בבת אחת:

עבד את הבקשות הממוספרות למטה. צור אובייקט JSON עבור כל אחד עם הסכימה הבאה והחזר את כולם כמערך JSON. מעבר לתכנית: { "id": "", "summary": "", "category": "", "urgency": "", "emotion": "", "next_step": "", "I'm not sure": "" }קטגוריות בלבד: משלוח, החזרה, תשלום, טכני, מידע מוצר, תלונה, הזדמנות מכירה. בקשות: {{ numbered_request_list }}

ההנחיה המבהירה את קריטריון הדחיפות ומלמדת את המודל את ההגדרה של "קריטי":

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

הנחיה שתופסת את הזדמנות המכירה ומקימה גשר תמיכה/מכירות:

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

הנחיה חלשה / הנחיה חזקה

הנחיה חלשה

הנחיה עוצמתית

"סכמו וסווגו את הבקשה הזו"

רשימת קטגוריות סגורה + הגדרת דחיפות + סכימת JSON קבועה

יוצר תוויות שונות בכל פעם

תמיד נותן את אותה תווית לאותה בקשה

הוא משתמש במילה "דחוף" לפי רצונו.

מיישם קריטריונים קונקרטיים עבור "קריטי"

הוא ממציא את המעורפל

emin_degilim: אמור כן והשאיר את זה לאדם

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

שלושה מיני מארזים

מקרה 1 - מבקר חסוי. בחברת SaaS (תוכנה שכורה באינטרנט), ההודעה "אני לא מצליח להיכנס, כל הצוות מחכה ל-40 אנשים" נראתה רגילה כי היא הייתה קצרה באורך. הודעת הטריאג' סימנה את זה "קריטי" הודות לכלל הדחיפות ("השירות אינו זמין לחלוטין"). הבקשה טופלה תוך 6 דקות במקום המתנה של שעתיים בתור; נמנעה הפרת SLA (הסכם רמת שירות, כלומר זמן תגובה מובטח).

מקרה 2 - תעדוף כעס. יום אחד, כאשר נבחנו תגי הבינה המלאכותית של 180 בקשות, נראה כי 14 בקשות עם הרגש "כועס" הוכנסו לתור נפרד. בקשות אלו הופנו לנציגים מנוסים, וציון הסקר השלילי (CSAT, כלומר ציון שביעות רצון לקוחות) באותו שבוע השתפר משמעותית בהשוואה לשבוע הקודם.

מקרה 3 - גשר מתמיכה למכירות. "החבילה הנוכחית שלי היא ל-5 משתמשים, אני צריך להגדיל אותה ל-20 אנשים, האם זה אפשרי?" AI תייג את ההודעה כ"הזדמנות מכירה" והוסיף הערת מכירה. הבקשה נפלה אוטומטית לצוות המכירות; הזדמנות למכירה נוספת שהיתה נעלמת מעיניהם אם היא הייתה אובדת בתור התמיכה הסטנדרטי הפכה לרווח.

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

חיבור לאוטומציה

הכוח האמיתי של פלט ה-JSON המובנה הוא בכך שהוא זורם אוטומטית לשלב הבא: הבקשה שכותרתה "קריטית" מודיעה מיד למנהל, "הזדמנות מכירות" נופלת ל-CRM (תוכנת ניהול קשרי לקוחות), "החזרה" נכנסת לזרימת השירות העצמי. אבל הכלל הראשון של אוטומציה: פעולות בעלות השפעה גבוהה (החזר, סגירת חשבון) לעולם אינן מופעלות על סמך תג ה-AI בלבד; לפעמים יש אישור אנושי.

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

טעויות נפוצות

• השארת רשימת הקטגוריות לדגם; מקבל תוויות שונות, לא תואמות בכל פעם.
• השארת מילה יחסית כמו "דחוף" לא מוגדרת; הבקשה של כולם דחופה.
• אי תיקון פורמט הפלט; לפעמים מופיעה פסקה, לפעמים רשימה במקום JSON.
• לא לספק דלת יציאה לאי ודאות (אני לא בטוח).
• קישור עסקאות בעלות השפעה גבוהה (החזר כספי, סגירת חשבון) לתג AI ללא אישור אנושי.
• אוטומציה של כל הזרימה ללא אימות ידני של האצווה הראשונה.

לסיכום

• Triage ממיין במהירות את ערימת הבקשות הנכנסות לפי קטגוריות, דחיפות ורגש.
• המפתח לעקביות: רשימת קטגוריות סגורה, הגדרת דחיפות קונקרטית ופורמט פלט קבוע (JSON).
• תוויות דחיפות ורגשות מאיצות את סדר העדיפויות; זה מעלה דרישות ביקורתיות וכועסות.
• ניתן לקשר פלט מובנה ישירות לאוטומציה (הודעה, ניתוב, CRM).
• פעולות בעלות השפעה ותוויות מעורפלות צריכות תמיד לעבור אימות אנושי.

משימת יישום

עבד באצוות את 5 בקשות הלקוחות השונות שיש לך (או דוגמאות) עם ההנחיה של מערך JSON למעלה. לאחר מכן בדוק ידנית את הפלט: (1) האם כל קטגוריה נכונה? (2) האם אלו המסומנים כ"קריטיים" אכן מפסיקים את השירות? (3) האם בטוח אמרתי "כן" במקומות הנכונים? תקן את כל התגים שאינם מתאימים ועדכן את ההנחיה (במיוחד הגדרות קטגוריות וכלל דחיפות) בהתאם. תרגיל זה בונה את ההרגל לכייל את הסכימה למציאות שלך.

רשימת בדיקה

• [ ] הגדרתי רשימה סגורה ודיסקרטית של קטגוריות.
• [ ] תיארתי את רמות הדחיפות באמצעים קונקרטיים.
• [ ] תיקנתי את פורמט הפלט (JSON/טבלה).
• [ ] הוספתי דלת יציאה לחוסר ודאות (אני_לא בטוח).
• [ ] אימתתי ידנית את האצווה הראשונה וכיילתי את ההנחיה.
• [ ] שמתי שכבה של אישור אנושי על פעולות בעלות השפעה.