מחזור חיים של כרטיסים ותקשורת עם לקוחות ב-Helpdesk
מבוא
במאמר זה, נעבור על תהליך הכרטוס בהתאם לאופן יצירת הכרטיס ב-Help Desk ובהתאם לגישה של הלקוח למערכת שלך. תמצא עצות לגבי מה להיזהר בתצורות שונות של תהליך הכרטיסים.
מאמר זה מכיל טיפים והצעות לתצורות שונות, אך לא באופן ישיר לאופן ביצוע התצורות. להלן המאמרים הרלוונטיים:
- תיעוד דלפק העזרה
- מדריך למשתמש (זרימת עבודה, הגדרות התראות)
שלושה דרכי תקשורת עיקריות
החל מתכנית של מחזור חיים של כרטיס במצבים ישרים קדימה - כאשר הכרטיס עוקב רק אחרי סוג אחד של זרימה מההתחלה ועד הסוף.
- כתובת אימייל
- משתמש מלא באפליקציה
- משתמש דלפק עזרה באפליקציה
יצירה ותקשורת נוספת בתוך כרטיס
יצירת כרטיסים ותקשורת נוספת יכולים לשלב את הגישות הנ"ל.
אפשר ליצור כרטיס באמצעות דואר אלקטרוני ולאחר מכן לבצע מעקב באפליקציה (בין אם על ידי משתמש מלא, או משתמש ב-Help Desk). אפשר גם ליצור כרטיס דרך המערכת ולאחר מכן לעקוב רק אחר מיילים.
דוגמה 1
- הכרטיסים נוצרים באמצעות דואר אלקטרוני - הלקוח שולח מייל חדש לכתובת העזרה.
- הלקוח נכנס למערכת ויכול לראות שם את הכרטיס, שכן הוא מחבר הכרטיס.
- לקוחות עשויים לשנות סטטוסים ושדות אחרים וכן להשאיר הערות, בהתאם להרשאותיהם.
דוגמה 2
- הלקוח נכנס למערכת ויוצר כרטיס חדש.
- הלקוח מקבל עדכונים במייל ורק צופה בעדכונים אלו ואינו מרגיש צורך להיכנס למערכת יותר.
דוגמה 3
- הלקוח יוצר כרטיס דרך פורטל העזרה
- הלקוח מחליט שהוא רוצה לעקוב רק אחר מיילים ואינו נכנס יותר לפורטל
- לאחר מכן הלקוח מחליט שהוא רוצה לעקוב דרך הפורטל, רושם את I ומזין כמה תשובות דרך הפורטל.
למען הנוחות של הלקוחות שלך, אתה יכול להחליט באילו שיטות אתה רוצה לאפשר להם ליצור ו/או לעדכן כרטיסים. אבל הכי חשוב, צריך לכסות כל מצב אפשרי, כדי שהכרטיסים לא ילכו לאיבוד למבוי סתום. זרימת עבודה ותצורות אחרות מספקות את כל האפשרויות הדרושות.
סוגיות נפוצות
הלקוח משיב להודעת משימה רגילה, אך התשובה אינה מעובדת כראוי.
הסיפור הזה נוגע לדוגמא 2. לקוחות חושבים שהם משיבים לכרטיס באמצעות דואר אלקטרוני, אך המייל אינו משויך לכרטיס הקיים ובמקום זאת נוצר אחד חדש, או שהמייל אינו מגיע למערכת כלל. הלקוח משיב להתראה, או בטעות יוצר אימייל חדש.
הסיבה: הגדרות ההתראות באימייל אינן מצפות לתשובות לכתובת ההתראה.
פתרון: יש לשלוח את תגובת הלקוח לכתובת שצוינה במוקד וצריכה להכיל את מספר הכרטיס. כתובת דואר אלקטרוני של התראות (ניהול >> הגדרות >> הודעות דוא"ל >> כתובת דוא"ל להודעות (FROM)) אולי זהה לכתובת דואר של דלפק העזרה כדי לתפוס תשובות מלקוחות ולהתאים אותן לכרטיס שממנו נשלחה ההודעה בתחילה.
אפשרות נוספת היא פשוט לבטל התראות דוא"ל רגילות למשתמשי הלקוח. המיילים היחידים מכרטיסים שהם יקבלו יישלחו באופן פעיל על ידי המפעילים באמצעות תבניות דוא"ל של דלפק העזרה.
דרך מפתח: הלקוחות שלך יתפתו באופן טבעי להשיב לכל הודעת דוא"ל שהם מקבלים. ודא שהם מקבלים רק הודעות שניתן לעבד עליהן תשובות כראוי.
הלקוח שינה את הכרטיס למצב "שגוי".
זה קורה בעיקר במצבים שבהם ללקוח יש משתמש מלא באפליקציה (במקום משתמש ב-Help Desk). ללקוח עשויה להיות אפשרות לערוך שדות רבים, כולל סטטוס ועלול לפרש לא נכון את המשמעות של סטטוסים שונים. או מצד שני אולי לא ישנה את הסטטוס, כאשר אתה מצפה שהוא ישתנה.
הסיבה: הלקוח אחראי לקביעת המצב הנכון.
פתרון: זהו אנטי דפוס ברור, הלקוח לא צריך לזכור כללים כלשהם עבור סטטוסי משימות.
פתרון אחד הוא להחליף חשבון לקוחות למשתמשי Helpdesk, במקום משתמשים מלאים. משתמשי דלפק העזרה יכולים ליצור כרטיסים ולהכניס הערות לכרטיסים קיימים, שינויים בסטטוס מבוססים על תצורות דלפק העזרה, כך שאין סיכוי שהלקוח "ישבור" תהליך נכון כלשהו. עדכוני הכרטיסים של משתמשי דלפק העזרה מתוכננים באופן מעשי כדי לעקוב אחר ההיגיון וההגדרות של תקשורת הדוא"ל של דלפק העזרה. ההבדל היחיד הוא שהמשתמש יכול לראות ולעבוד עם צורה פיזית של הכרטיס.
אם אתה צריך לשמור על המשתמשים המלאים עבור הלקוחות שלך, ההצעה שלנו היא להשבית לחלוטין כל שינוי סטטוס (או שינויים אחרים בשדות), מה שעלול לשבור חלק מהתהליכים הפנימיים שלך. השתמש בדרכים אחרות כדי לעקוב אחר כרטיסים שיש לעדכן - למשל לפי שדה המשימה עודכנה לאחרונה (תאריך העדכון האחרון), עודכן לאחרונה על ידי (מי ביצע את העדכון האחרון), אתה יכול להציג את ההערה האחרונה על כרטיס ברשימה, כך שיהיה ברור שהלקוח ביצע את העדכון.
תרחיש קצת יותר מסובך הוא מדוגמה 1, כאשר אתה מאפשר תקשורת כרטיסים באמצעות דואר אלקטרוני, אך גם מאפשר ללקוחות להיכנס על ידי משתמש מלא. הנה מה שצריך לשים לב אליו:
- שינוי סטטוס לאחר תשובות לקוח בדוא"ל מוגדר בהגדרות דלפק העזרה העולמיות
- אין אכיפת שינוי סטטוס למשתמשים מחוברים - תמיד קיימת האפשרות לשמור על סטטוס כפי שהוא
במקרה זה, עליך לוודא שהתורים שלך לתגובה מכילים את שני סוגי המצבים, מעודכנים בדוא"ל (למשל סינון לסטטוס ספציפי), וכרטיסים שעודכנו על ידי לקוחות מתוך האפליקציה (למשל רשימת כרטיסים עם עמודה תגובה אחרונה).
נקודת המפתח: הלקוח לעולם לא צריך לדאוג לגבי התהליכים הפנימיים שלך, הם רק צריכים מקום להגיש את הצרות שלהם ולתקשר איתך, התהליכים עליך ולאפליקציה יש אפשרויות שונות להדק אותה.
ערבוב משתמשים מלאים ומשתמשי Help Desk
זו רק אזהרה חזקה לא לשלב פתרונות שמעולם לא נועדו לשלב. אתה יכול להחליט אם להשתמש
- משתמשי דלפק העזרה - ללא תשלום, עם גישה מוגבלת בקוד קשיח, או
- משתמשים מלאים - משתמשים מורשים רגילים, שבהם אתה מחליט למה יש להם גישה
, אבל אסור להשתמש בשניהם בו-זמנית, במיוחד עבור אותם לקוחות. מבחינה טכנית, משתמשים מלאים ומשתמשי דלפק העזרה אינם מחוברים בשום צורה. יש להם אפילו דף כניסה אחר. הם מייצגים תחום שונה במשימות (מחבר לעומת מחבר דלפק העזרה). אז אין סיבה לבלבל את הלקוח שלך בכך שהוא מספק לשני אפשרויות הגישה.
באשר לתהליכים הפנימיים שלך, זה אפשרי מבחינה טכנית לספק לחלק מהלקוחות משתמשים מלאים, ולאחרים רק למשתמשי עזרה דסק. עם זאת, זה דורש תיאורי תהליכים מדויקים והדרכות עבור הסוכנים שלך כדי להבטיח שהם לא יערבבו עיבוד כרטיסים מהערוצים השונים מאוד האלה. בשל הקושי הארגוני, אנו ממליצים בחום לבחור רק אפשרות אחת לגישה ללקוח.
<br> סיכום
הבה נחזיר את המידע הקודם לצורה הניתנת לעיכול. להלן טבלה של מצבים שעלולים להתרחש בהתבסס על סוג הגישה של הלקוחות שלך למערכת שלך.
| גישת לקוח לאפליקציה | אפשרויות להגשת כרטיס (לקוח) |
הודעות מכרטיס (סוכן) |
אפשרויות לעדכון כרטיס (לקוח) |
ההמלצות שלנו |
| ללא גישה | שלח דוא"ל לכתובת דוא"ל של דלפק העזרה. | הסוכן שולח דוא"ל באמצעות תבנית מהכרטיס. |
|
|
| משתמש מלא |
|
|
|
|
| משתמש ב-Help Desk |
|
הסוכן שולח דוא"ל באמצעות תבנית מהכרטיס. |
|
|
