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

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

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

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

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

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

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

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

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

אוטומציה של קריאה לכרטיס (call-to-ticket) מכוילת היטב היא כזו שיוצרת כרטיס רק כאשר יש פעולה שיש לבצע לאחר מכן. לא לפני כן, לא במקביל.

הדרישות הטכניות המוקדמות לחיבור הטלפוניה שלך למוקד התמיכה שלך

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

עמוד תווך ראשון: טלפוניית VoIP אמינה . משמעות הדבר היא השהייה של פחות מ-150 מילישניות ו-QoS (איכות השירות) שתצורתה ברשת שלך תעדוף תעבורת קול. אם השיחות שלך נופלות או מתקלקלות, גם ה-webhooks שמעבירים אירועי שיחה למוקד התמיכה שלך יאבדו נתונים לאורך הדרך. Kavkom, כפתרון טלפוניית VoIP מבוסס ענן , מנהל שכבה זו באופן טבעי עם איכות שמע HD וניתוב שיחות חכם, ומבטיח שכל אירוע (שיחה שנענה, שיחה שלא נענתה, שיחה שהועברה) נלכד כראוי בצד השרת.

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

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

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

כיצד להגדיר את תהליך העבודה שלך מקריאה לכרטיס ב-4 שלבים

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

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

שלב 1: הגדרת הגורמים המפעילים הרלוונטיים

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

הנה אירועי VoIP שבדרך כלל מצדיקים כרטיס:

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

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

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

שלב 2: מיפוי שדות הנתונים הנדרשים

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

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

סוג השדה	נתונים שנאספו	תועלת עבור הסוכן
הִזדַהוּת	זיהוי מתקשר, חותמת זמן מדויקת	לדעת מי התקשר ומתי
סיווג	בחירת IVR, תור מקור	הבנת אופי הדרישה
קביעת סדרי עדיפויות	מצב ראשוני (דחוף, תקין), ALS קשור	לטפל בסדר הנכון
הקשר טכני	קישור להקלטת שיחה, נציג שהוקצה	האזינו שוב לשיחה מבלי להפריע ללקוח

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

שלב 3: הגדרת כללי ניתוב והקצאה

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

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

• ניתוב IVR. הלקוח לחץ על "2" לתמיכה טכנית? הפנייה עוברת ישירות לתור של הצוות הטכני, לא לתור של צוות המכירות.
• הקצאה על ידי בעל CRM. אם מספר הטלפון של המתקשר כבר מקושר לאיש קשר במערכת ה-CRM שלכם, הפנייה מוקצית לאיש המכירות או למנהל החשבון המטפל באותו לקוח. Kavkom מסנכרנת נתונים אלה דרך אינטגרציות ה-CRM המקוריות שלה, מה שהופך את הכלל הזה לקל ליישום.
• קביעת סדרי עדיפויות לפי הסכם רמת שירות. שיחה מלקוח VIP (המזוהה על ידי מספרו) יוצרת כרטיס בעל עדיפות גבוהה וזמן עיבוד מופחת. אחרים פועלים לפי תהליך העבודה הסטנדרטי.

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

שלב 4: בדיקת הזרימה והגדרת ביטול כפילויות

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

בצעו 10 עד 15 שיחות ניסיון המכסות כל תרחיש (שיחה שלא נענתה, נטישת תור, בחירת IVR טכנית, העברה כושלת). עבור כל שיחה, ודאו שהכרטיס מכיל את כל השדות הנדרשים, שהוא ממוקם בתור הנכון, ושה-SLA מיושם כהלכה.

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

הפתרון: הגדרת מפתח ייחודי לביטול כפילויות המשלב את מספר המתקשר וחלון זמן (לדוגמה, 30 דקות). אם שיחה מאותו מספר מגיעה בתוך חלון זמן זה, המערכת מעדכנת את הכרטיס הקיים במקום ליצור כרטיס חדש. כמו כן, יש לשקול סטנדרטיזציה של פורמטי מספרים (רווחים, קידומת אזור, מקפים) כך ש-+33 6 12 34 56 78 ו-06 12 34 56 78 יזוהו כאותו מתקשר.

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

טעויות נפוצות שהורסות את האוטומציה שלכם

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

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

1. כפילויות מסיביות עקב היעדר מפתח מניעת כפילויות. דנו בכך בשלב 4, אך זה כל כך נפוץ שראוי לחזור על כך. לקוח שמתקשר בחזרה שלוש פעמים מייצר שלושה כרטיסים אם לא הגדרתם חלון זמן לכל מספר. גרוע מכך: אם פורמטי המספרים אינם סטנדרטיים (06 לעומת +336 לעומת 0033 6), מוקד התמיכה שלכם מתייחס לאותו מתקשר כאל שלושה אנשים נפרדים. סטטיסטיקות עומס העבודה של הסוכנים שלכם הופכות לבלתי שמישות, והזמן המבוזבז על סגירת מקרים כפולים מצטבר במהירות.

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

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

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

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

אילו אינדיקטורים יש לנטר לאחר יישום תהליך העבודה?

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

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

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

רזולוציית קשר ראשונה (FCR). מדדי התעשייה מציבים FCR טוב בין 70% ל-85%, בהתאם למגזר ( BlueTweak, 2026 ). עם מערכת כרטוס נכנסת מוגדרת היטב, לסוכן יש גישה להקלטת השיחות, תרשים זרימה של IVR ולהיסטוריית CRM ברגע שהקרטוס נפתח. הם לא צריכים להתקשר בחזרה כדי להבין את ההקשר. רווח מידע זה מתורגם ישירות ל-FCR גבוה יותר.

זמן טיפול ממוצע (AHT). משך השיחה הממוצע הסטנדרטי הוא כ-6 דקות ו-10 שניות בכל המגזרים, ובין 4 ל-7 דקות עבור שירות קולי שגרתי. מה שמעניין אותך הוא החלק של זמן זה המושקע בהזנת נתונים ידנית. אם תהליך ה-call-to-ticket האוטומטי שלך עובד היטב, זמן ה-after-call (הזמן המושקע בתיעוד האינטראקציה לאחר סיום השיחה) אמור לקצר משמעותית, מכיוון שה-ticket כבר מולא מראש.

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

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

נקודות מפתח לתהליך עבודה חלק

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

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

מוכנים לפעול? אתם יכולים להזמין הדגמה בחינם ולבחון את הפתרונות שלנו ללא התחייבות כדי לייעל את תהליכי העבודה של התמיכה שלכם.