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

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

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

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

התור הוא רק החלק הגלוי של מודל השירות

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

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

מה ארגוני שירות בוגרים באמת מנסים לנהל

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

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

המשמעות הטכנולוגית

עבור CIO, ניהול רצף שירות הוא לא עוד מסך. זו שכבה מבוססת אירועים שמחזיקה מצב שירות בלי להחליף CRM, מערכות ליבה, זהות, יומנים או contact center. השכבה צריכה APIs, webhooks, הרשאות, audit, כללי מדיניות וגמישות פריסה. בלי זה מקבלים מערכת תורים יפה יותר עם אותו מודל מקוטע מתחת.

עבור מנהלי שירות ועסקים, השאלה משתנה מ-'כמה זמן מחכים?' ל-'איזו החלטה תשפר את השעתיים הקרובות בלי לשבור הוגנות, SLA או אמון?'