WEBVTT

00:00:00.000 --> 00:00:11.100
לקוח שולח אימייל על הזמנת כולה, מתקשר למוחרת, ואז פותח צ'אט כי נראה שאף אחד לא יודע מה קרה, והוא חוזר על אותו סיפור בכל פעם בזמן שצוות התמיכה שלכם מחטט בטיבות דואר, פתקים וחלים נפרדים.

00:00:11.300 --> 00:00:14.780
זה בדיוק מה שניהול מקרים בדיינמיקס 365 פותר.

00:00:14.960 --> 00:00:22.340
תחשבו על מקרה כמו תיקיה עם תווית בתוך בניין משרדי ממוס, שבו כל חלק בבעיית הלקוח נכנס לאותה תיקיה מהשאלה הראשונה ועד לתשובה הסופית.

00:00:22.340 --> 00:00:31.780
כאן מרקו פיטרס מאם 365 FM, ובנגיסת הידע הזו תראו איך מקרים, ניתוב, מועדי תגובה, מאמרי תמיכה וסגירת קריאות משתלבים יחד.

00:00:31.900 --> 00:00:34.200
מהו מקרה בפועל בית מינוס 20 מילים?

00:00:34.580 --> 00:00:35.760
אז מהו בעצם מקרה?

00:00:35.940 --> 00:00:45.240
מקרה הוא רשומה אחת עבור בעיית לקוח שדורשת מענה או פתרון, והבעיה יכולה להיות מוצר פגום, שאלת חיוב, בעיית התחברות או בקשה לעזרה בשימוש בשירות.

00:00:45.320 --> 00:00:48.800
הנה העניין, ללקוח אחד יכולים להיות כמה מקרים בו זמנית.

00:00:48.800 --> 00:00:54.920
לקוח אחד עשוי לשאול על חשבונית ביום שני, לדווח על מכשיר תקול ביום שלישי, ולהזדקק לעזרה בשינוי כתובת ביום שישי.

00:00:55.040 --> 00:01:01.920
אלו בעיות נפרדות, לכן דינמיקס 365 שומר אותן ברשומות מקרים נפרדות, במקום להרום כל שיחה לשרשור אחד מבלבל.

00:01:02.060 --> 00:01:04.980
כשנציג יוצר מקרה, הוא מקשר אותו ישירות ללקוח.

00:01:05.140 --> 00:01:10.540
הלקוח הזה עשוי להיות איש קשר, כלומר אדם פרטי, או חשבון, כלומר החברה שבה הוא עובד.

00:01:10.540 --> 00:01:20.420
אז, אם ג'יימי מנורתוויין טריידרס מדווח על בעיה, המקרה יכול להפנות גם לג'יימי וגם לחברה, וכל מי שפותח את הרשומה יכול לראות מי זקוק לעזרה ולאיזה ארגון הבעיה שייכת.

00:01:20.580 --> 00:01:24.700
המקרה זקוק גם לתיאור פשוט של הבעיה, בדרך כלל עם כותרת כמו

00:01:24.700 --> 00:01:28.040
המדפסת שלנו מפסיקה לעבוד אחרי עדכון תוכנה, או

00:01:28.040 --> 00:01:34.920
לקוח חויב פעמיים עבור תוכנית שנתית, והכותרת עוזרת לאנשים לסרוק רשימת מקרים פתוחים בלי לפתוח כל רשומה.

00:01:35.040 --> 00:01:37.700
מתחת לכותרת הזו, הנציג מוסיף את הפרטים.

00:01:37.860 --> 00:01:40.860
מה קרה? מתי זה התחיל? מה הלקוח כבר ניסה לעשות?

00:01:41.060 --> 00:01:44.700
באילו מוצרים מדובר? והאם מדובר בשאלה, בבקשה או בתקלה?

00:01:44.700 --> 00:01:48.820
הפרטים האלה הופכים הודעה מאורפלת לעבודה שמישהו יכול לקחת עליה אחריות ולפתור.

00:01:48.980 --> 00:01:50.460
בואו נפרק את זה עוד יותר.

00:01:50.460 --> 00:01:53.860
מקרה יכול להכיל נושא, מוצר, עדיפות וסוג מקרה.

00:01:54.000 --> 00:01:59.520
הנושא מסווג את הבעיה לתחום כמו חיוב או תמיכה טכנית, המוצר מזהה במה הלקוח משתמש,

00:01:59.820 --> 00:02:06.920
העדיפות מורה לצוות כמה מהר לטפל בה, וסוג הפנייה מעניק לצוות דרך נוספת למיין את העבודה על פי תהליך התמיכה שלהם.

00:02:06.920 --> 00:02:16.040
אף אחד מהשדות האלו לא פותר את בעיית הלקוח לבדו, אך הם עוזרים לצוות התמיכה לראות את העבודה בבירור, במיוחד כשמאות פניות מגיעות מלקוחות שונים.

00:02:16.040 --> 00:02:20.980
צוות המטפל בחשל שירות חמור לא אמור לחפש אותו בתוך שאלות כלליות.

00:02:21.400 --> 00:02:24.740
פנייה היא לא סתם תופס שמישהו ממלא ושוכח ממנו.

00:02:24.980 --> 00:02:27.480
היא הופכת לטיעוד העבודה עבור כל השיחה.

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

00:02:35.900 --> 00:02:41.840
כל פעילות נשארת משוייכת לאותה בעיית לקוח, כך שהאדם הבא לא צריך לשחזר את הסיפור מהתחילה.

00:02:41.840 --> 00:02:47.260
תארו לעצמכם נציג שמתחיל לעבוד בבוקר ואז מעביר את הפנייה למומחה מוצר אחרי ארוחת הצהריים.

00:02:47.500 --> 00:02:50.520
ללא תיעוד הפנייה, המומחה עלול לקבל הודעה קצרה כמו,

00:02:50.520 --> 00:02:53.660
היי, אתה יכול להסתכל על זה, שזה בהחלט לא מספיק.

00:02:53.780 --> 00:03:00.460
עם תיעוד הפנייה, הם יכולים לראות את הבעיה המקורית, פרטי הלקוח, מה קרה במהלך השיחה ומה הנציג הראשון כבר בדק.

00:03:00.540 --> 00:03:02.280
זה מציע העברה הרבה יותר טובה.

00:03:02.440 --> 00:03:07.280
דיינמיקס 365 שומרת על הפנייה במצב ברור ככל שהיא מתקדמת בתהליך התמיכה.

00:03:07.280 --> 00:03:13.520
היא יכולה להישאר פעילה בזמן שהצוות חוקר, וברגע שהצוות פותר את הבעיה או נותן תשובה סופית, הם מסמנים אותה כפתורה.

00:03:13.520 --> 00:03:19.620
אם אין עוד צורך לטפל בבקשה, אולי היא הגיעה בטעות או שהלקוח משך אותה, הצוות יכול לבטל אותה.

00:03:19.840 --> 00:03:21.640
פעילה, פטורה ומבוטלת.

00:03:22.300 --> 00:03:26.680
שלושת המצבים האלה נותנים לצוות תמונה משותפת על מצב כל בעיה,

00:03:27.020 --> 00:03:30.340
כך שאף אחד לא צריך לנחש אם פנייה עדיין דורשת טיפול,

00:03:30.340 --> 00:03:35.180
ומנהלים לא צריכים להתייחס לעבודה ישנה שהסתיימה כאל בעיית לקוח טריה.

00:03:35.740 --> 00:03:40.400
תיעוד אחד מעניק לכם שליטה, והיסטוריית הלקוח המלאה מעניקה לנציג הקשר.

00:03:41.040 --> 00:03:43.040
סיפור הלקוח שמאחורי הפנייה.

00:03:43.180 --> 00:03:45.040
פנייה אומרת לכם מה דורש תיקון.

00:03:45.220 --> 00:03:47.520
תיעוד הלקוח אומר לכם מה הוביל לרגע הזה.

00:03:47.680 --> 00:03:51.400
כאשר נציג פותח פנייה בדיינמיקס 365 Customer Service,

00:03:51.640 --> 00:03:53.400
הוא יכול להסתכל מעבר להודעה האחרונה.

00:03:53.540 --> 00:03:56.800
הוא רואה את התמונה הגדולה, כמו פניות קודמות, אימיילים מהעבר,

00:03:56.800 --> 00:03:59.680
המוצרים המחוברים ללקוח והיסטוריית התמיכה שלו.

00:03:59.760 --> 00:04:01.200
הקשר משנה את השיחה.

00:04:01.300 --> 00:04:02.640
מדוע הקשר הוא חשוב?

00:04:02.820 --> 00:04:05.120
דמיינו לקוח שמדווח על תקלה במכשיר.

00:04:05.280 --> 00:04:09.140
אם הנציג רואה רק את ההודעה של היום, הוא עלול להתחיל בשאלות בסיסיות.

00:04:09.280 --> 00:04:10.340
באיזה דגם מדובר?

00:04:10.480 --> 00:04:11.360
מתי זה התחיל?

00:04:11.500 --> 00:04:12.760
האם יפעלת אותו מחדש?

00:04:12.900 --> 00:04:15.400
אבל הלקוח כבר פנה לתמיכה פעמיים השבוע.

00:04:15.560 --> 00:04:19.080
הנציג הראשון שלח שלבי פתרון בעיות, השני ארגן חלק חלופי.

00:04:19.080 --> 00:04:22.740
נציג שלישי שרואה את ההיסטוריה הזו לא יבקש מהלקוח להתחיל מהתחילה.

00:04:22.840 --> 00:04:27.100
במקום זאת, הוא אומר, אני רואה שכבר ניסית את השלבים האלה ושהחלק החלופי לא פתר את הבעיה.

00:04:27.280 --> 00:04:28.500
בואו ננסה את הדבר הבא.

00:04:28.640 --> 00:04:31.580
זה מרגיש שונה לגמרי עמם, אתה יכול להסביר שוב את הבעיה.

00:04:31.760 --> 00:04:34.840
זה נקרא לעיתים קרובות מבט 360 מעלות על הלקוח.

00:04:35.020 --> 00:04:36.860
השם נשמע מפואר, אבל זה פשוט.

00:04:37.060 --> 00:04:41.480
זה אומר שהנציג רואה את הלקוח מיותר מזווית אחת, לא רק מהודעה בודדת ומבודדת.

00:04:41.480 --> 00:04:47.460
הנציג רואה את האדם, את החברה, את בקשות התמיכה הקודמות, את השיחות הקודמות ואת המוצרים הקשורים עליהם.

00:04:47.580 --> 00:04:50.800
עבור צוות תמיכה, זה מחליף ניחושים בנקודת התחלה ברורה.

00:04:50.960 --> 00:04:53.640
כעת, לא כל לקוח מקבל את אותו סוג של תמיכה.

00:04:53.780 --> 00:04:58.680
לקוח עשוי היה לרכוש אחריות, החברה שלו עשויה לשלם על מספר קבוע של שעות תמיכה,

00:04:58.720 --> 00:05:03.140
או שיש לו חוזה שמאפשר מספר מסוים של פניות, או תמיכת פרימיום עם סיוע מהיר יותר.

00:05:03.140 --> 00:05:07.020
דיינמיקס 365 עוקבת אחר כל זה באמצעות זכאויות.

00:05:07.020 --> 00:05:10.380
זכאות היא הסכם התמיכה של הלקוח בתוך המערכת.

00:05:10.540 --> 00:05:13.520
חשוב על זה כתנאי השירות המצורפים לחשבון שלו.

00:05:13.680 --> 00:05:18.680
לפני שנציג מבטיח הגעת טכנאי או מתחיל עבודה בתשלום, הוא בודק איזו תמיכה חלה.

00:05:18.880 --> 00:05:20.380
זה מונע הפתעות לא נעימות.

00:05:20.540 --> 00:05:23.720
למשל, ללקוח עשויה עדיין להיות אחריות על מוצר תקול.

00:05:23.880 --> 00:05:25.720
הפנייה יכולה לעקוב אחר המסלול הזה.

00:05:25.920 --> 00:05:28.380
לקוח אחר עשוי היה לנצל את כל שעות התמיכה שלו.

00:05:28.380 --> 00:05:31.120
הנציג רואה זאת לפני שהוא מתחייב לעבודה מחוץ להסכם.

00:05:31.280 --> 00:05:33.940
זה גם עוזר לצוות התמיכה להתייחס ללקוחות בצורה הוגנת.

00:05:34.080 --> 00:05:36.980
הנציג לא צריך לחפש בחוזים ישנים או לשאול מחלקה אחרת.

00:05:37.140 --> 00:05:40.740
תנאי התמיכה נמצאים עם פרטי הלקוח בדיוק במקום שבו הנציג יכול למצוא אותם.

00:05:40.860 --> 00:05:42.240
ואז יש את מאגר הידע.

00:05:42.360 --> 00:05:44.660
צוותי תמיכה פותרים את אותן בעיות שוב ושוב.

00:05:44.860 --> 00:05:49.820
איפוס סיסמה, הוראות התקנה, שגיאה ידועה לאחר עדכון, שאלת חיוב עם תשובה סטנדרטית.

00:05:49.820 --> 00:05:52.360
מאמר ידע מאכסן את התשובה הזו במקום אחד.

00:05:52.360 --> 00:05:56.500
בתוך סביבת העבודה של השירות, נציג יכול לחפש מאמרים בזמן העבודה על פנייה.

00:05:56.620 --> 00:06:01.920
מאמר עשוי לכלול הסבר פשוט, שלבים, צילום מסך או עת הבדיקות המדויקות שהצוות צריך להשלים.

00:06:02.080 --> 00:06:07.080
במקום שכל נציג יכתוב גרסה משלו מהזיכרון, הם משתמשים בתשובה משותפת שהצוות סקר.

00:06:07.260 --> 00:06:08.700
זה שומר על עקביות בתמיכה.

00:06:08.860 --> 00:06:10.560
זה גם עוזר לנציגים חדשים יותר.

00:06:10.560 --> 00:06:16.280
הם לא צריכים שנים של ניסיון כדי לטפל היטב בבעיות נפוצות, כי הפתרונות המוכרים של הצוות זמינים להם כשצריך.

00:06:16.440 --> 00:06:20.140
סיכומי המקרה של קופ אילוט עוזרים בבעיה נפוצה אחרת, היסטוריית מקרים ארוכה.

00:06:20.260 --> 00:06:23.220
מקרה יכול לצבור אימיילים, הערות ועדכונים רבים לאורך זמן.

00:06:23.380 --> 00:06:26.220
קריאת כולם גוזלת זמן, במיוחד לאחר העברה בין נציגים.

00:06:26.220 --> 00:06:33.460
קופ אילוט יוצר סיכום מקרה קצר שמאחד את כותרת המקרה, הלקוח, הנושא, המוצר, העדיפות, סוג המקרה, התיאור והפעילות האחרונה.

00:06:33.640 --> 00:06:35.980
זהו תדרוך מהיר לפני שהנציג מתחיל לעבוד.

00:06:36.160 --> 00:06:40.660
הנציג עדיין בודק את הרשומה ומפעיל שיקול דעת, אבל הוא מבין את המצב מהר יותר.

00:06:40.900 --> 00:06:44.320
זה עוזר כשהלקוח ממתין והמקרה עבר בין כמה ידיים.

00:06:44.540 --> 00:06:49.220
ברגע שהנציג מבין את הלקוח ואת הבעיה, המקרה צריך להגיע לאדם הנכון.

00:06:50.560 --> 00:06:52.280
מהקליטה ועד לתור המתאים.

00:06:52.280 --> 00:06:58.040
לקוח יכול לבקש עזרה בדרכים רבות, אימייל, שיחת טלפון, צ'אט, רשתות חברתיות או פורטל שירות עצמי.

00:06:58.120 --> 00:07:02.080
הערוץ משתנה, אך צוות התמיכה עדיין זקוק למקום אחד ברור לניהול הבקשה.

00:07:02.280 --> 00:07:08.120
דיינמיקס 365 יכול ליצור מקרים משיחות אלו כאשר ההגדרה כוללת חוקי יצירת רשומות.

00:07:08.200 --> 00:07:10.940
חישבו על אימייל שמגיע לכתובת תמיכה משותפת.

00:07:11.100 --> 00:07:15.520
במקום להשאיר אותו בתיבת הדואר עד שמישהו יבחין בו, חוק הופך את האימייל למקרה.

00:07:15.520 --> 00:07:18.440
ההודעה הופכת להתחלת העבודה בתוך שירות הלקוחות.

00:07:18.560 --> 00:07:20.580
זה מצמצם את הצורך בהעתקה ידנית.

00:07:20.720 --> 00:07:23.040
אותו רעיון חל על ערוצים מחוברים אחרים.

00:07:23.220 --> 00:07:26.960
הצוות בוחר אילו הודעות ייצרו מקרה חדש ואילו שייכות למקרה קיים.

00:07:27.140 --> 00:07:29.620
שובה לי, בעיה פתוחה נשארת משוייכת לאותה בעיה.

00:07:29.820 --> 00:07:31.340
שאלה חדשה מקבלת מקרה משלה.

00:07:31.500 --> 00:07:33.960
לאחר מכן המקרה זקוק לבית בזמן שמישהו לוקח עליו אחריות.

00:07:34.100 --> 00:07:35.340
הבית הזה הוא לרוב תור.

00:07:35.480 --> 00:07:37.460
תור הוא מגש עבודה משותף עבור צוות.

00:07:37.460 --> 00:07:41.260
זה לא תיבת דואר של נציג בודד וזה לא שייך לאדם שראה את הבקשה.

00:07:41.380 --> 00:07:44.860
במקום זאת, הוא נותן לכל הצוות מקום לראות עבודה שממתינה לטיפול.

00:07:45.020 --> 00:07:48.720
דמיינו חברה עם צוות חיובים, צוות תמיכה טכנית וצוות החזרות.

00:07:48.880 --> 00:07:50.440
לכל צוות יש תור משלו.

00:07:50.600 --> 00:07:53.940
שאלות חיוב הולכות לחיובים, תקלות מוצר למי שבתמיכה טכנית,

00:07:54.120 --> 00:07:56.660
ובקשות החזרה לאנשים שמכירים את תהליך ההחזרה.

00:07:56.840 --> 00:07:58.400
זה נשמע פשוט כי זה אכן פשוט.

00:07:58.400 --> 00:08:01.720
מיון ברור חוסך לאנשים את העברת העבודה ללא הכוונה.

00:08:01.860 --> 00:08:03.540
חוקי ניתוב עוזרים במיון הזה.

00:08:03.720 --> 00:08:07.720
חוק ניתוב בודק את הפרטים במקרה ושולח אותו לתור או לאדם הנכונים.

00:08:07.940 --> 00:08:10.520
מקרה על מוצר מסוים מגיע לצוות המוצר.

00:08:10.660 --> 00:08:13.020
מקרה מאזור מסוים מגיע לתמיכה מקומית.

00:08:13.200 --> 00:08:15.100
בעיה רצינית מגיעה לתור דחוף.

00:08:15.300 --> 00:08:17.420
שאלה כללית ממתינה עם הצוות הסטנדרטי.

00:08:17.560 --> 00:08:19.820
יש ארגונים שמנתבים עבודה על בסיס מיומנות.

00:08:20.000 --> 00:08:23.220
למשל, לקוח שכותב בצרפתית זקוק לנציג דובר צרפתית.

00:08:23.220 --> 00:08:26.020
סוגיית טכנית דורשת מישהו שהוכשר למוצר מסוים.

00:08:26.180 --> 00:08:28.340
ניתוב מקרב את הפנייה לאדם שיכול לפתור אותה,

00:08:28.460 --> 00:08:30.340
במקום להתייחס לכל בקשה באותו אופן.

00:08:30.480 --> 00:08:33.000
אוטומציה עוזרת, אך אנשים עדיין מקבלים החלטות.

00:08:33.180 --> 00:08:36.700
ראש צוות עשוי להסתכל על מקרה קשה ולהקצות אותו ישירות לנציג בכיר.

00:08:36.840 --> 00:08:38.540
אולי מישהו כבר מכיר את הלקוח.

00:08:38.740 --> 00:08:42.300
אולי הבעיה חוצה כמה מוצרים ודורשת ניסיון שכלל לא יכול לעמוד.

00:08:42.420 --> 00:08:45.140
הקצאה הידנית נותנת לצוות מקום לבחירה אנושית זו.

00:08:45.140 --> 00:08:47.540
הבעלות על מקרה יכולה להשתנות במהלך הטיפול בו.

00:08:47.620 --> 00:08:50.720
נציג עשוי להזדקק למידע נוסף ולהחזיר את המקרה לתור ההמתנה.

00:08:50.880 --> 00:08:53.380
צוות עשוי לגלות שהבעיה שייכת למחלקה אחרת,

00:08:53.600 --> 00:08:56.960
או שבקשה דחופה דורשת הסלמה כשהצוות הרגיל אינו יכול לפתור אותה.

00:08:57.100 --> 00:09:01.540
דיינמיקס 365 שומרת על העבודה בתנועה במקום להשאיר אותה תקועה אצל מישהו.

00:09:01.680 --> 00:09:04.280
כעת, לעתים בעיה אחת יוצרת מקרים רבים.

00:09:04.280 --> 00:09:07.380
תארו לעצמכם תקלת תוכנה שמשפיעה על עשרות לקוחות.

00:09:15.140 --> 00:09:21.100
זה נותן לצוות התמיכה שתי נקודות מבט בו זמנית.

00:09:21.260 --> 00:09:25.960
הם עובדים על התקלה הבסיסית דרך מקרה האב, בזמן שכל מקרה בין מעדכן את הלקוח המתאים.

00:09:26.120 --> 00:09:29.860
כשהם מוצאים את הפתרון, הם לא חוקרים את אותה תקלה מאפס עבור כל מתקשר.

00:09:30.060 --> 00:09:32.780
מקרים כפולים יוצרים בעיה דומה בקנה מידה קטן יותר.

00:09:32.780 --> 00:09:35.560
לקוח עשוי לשלוח אימייל ולהתקשר לגבי אותה בעיה,

00:09:35.800 --> 00:09:38.400
או ששני נציגים עשויים לפתוח מקרים לפני שהבחינו בשני.

00:09:38.540 --> 00:09:41.600
במקום לפצל מאמצים, הצוות יכול למזג מקרים דומים.

00:09:45.140 --> 00:09:47.320
אף אחד לא צריך לפתור את אותה בעיה פעמיים.

00:09:47.540 --> 00:09:50.520
העברת מקרה לתור ולאדם הנכונים מתחילה את העבודה,

00:09:50.840 --> 00:09:53.140
והלקוח מצפה לתגובה בזמן שהובטח לו.

00:09:53.260 --> 00:09:56.960
עמידה בהבטחות באמצעות הסכמי רמת שירות, SLA, ועבודה מונחה.

00:09:57.080 --> 00:09:59.500
העברת מקרה לאדם הנכון היא רק חצי מהעבודה,

00:09:59.780 --> 00:10:02.160
כי הלקוח גם מצפה לעזרה בתוך הזמן שהבטחת,

00:10:02.160 --> 00:10:05.740
וכאן נכנס לתמונה הסכם רמת שירות, או בקיצור SLA.

00:10:05.740 --> 00:10:07.440
SLA מצמיד שעון למקרה,

00:10:07.700 --> 00:10:11.160
כך שהצוות יודע בדיוק כמה זמן יש לו לעמוד בהבטחה ללקוח,

00:10:11.460 --> 00:10:14.280
בין אם מדובר בתגובה ראשונה או בפתרון מלא של הבעיה.

00:10:14.420 --> 00:10:15.760
אבל כאן העניין הוא שונה.

00:10:16.160 --> 00:10:17.440
אלו לא תמיד אותם מועדים.

00:10:17.660 --> 00:10:20.340
קחו למשל לקוח שמצפה לאישור בתוך שעה אחת,

00:10:20.580 --> 00:10:22.860
גם אם הצוות הטכני זקוק לשני ימי עסקים,

00:10:22.860 --> 00:10:24.380
כדי למצוא ולבדוק את הפתרון.

00:10:24.560 --> 00:10:27.620
דינמיקס 365 עוקבת אחר יעד המענה הראשוני,

00:10:27.720 --> 00:10:28.780
ויעד הפתרון בנפרד,

00:10:29.000 --> 00:10:30.420
כך שהצוות יכול לפעול במהירות,

00:10:35.740 --> 00:10:37.920
הוא לא מצפה לתיקון מלא תוך עשר דקות,

00:10:38.120 --> 00:10:40.760
אבל הוא כן מצפה שמישהו יאשר שהבעיה מוכרת,

00:10:40.960 --> 00:10:42.820
יסביר מה קורה בהמשך ויעדכן אותו.

00:10:43.000 --> 00:10:45.280
יעד המענה הראשוני עוקב אחר אותו קשר ראשון,

00:10:45.460 --> 00:10:48.720
בעוד שיעד הפתרון עוקב אחר הנתיב המלא עד למתן שובה או תיקון.

00:10:48.840 --> 00:10:51.120
וללקוחות שונים יכולות להיות הבטחות שונות.

00:10:51.120 --> 00:10:55.560
חברה עם תמיכת פרימיום מקבלת יעדי מענה מהירים יותר מלקוח בתוכנית רגילה.

00:10:55.660 --> 00:11:00.320
תקלה בעדיפות גבוהה מקבלת דד ליין קצר יותר משאלה שגרתית מסוג איך עושים.

00:11:00.500 --> 00:11:04.040
הסכמי תמיכה, עדיפות וסוג המקרה הם שמעצבים את חוקי הזמן נחלים.

00:11:04.260 --> 00:11:06.100
זה שומר על ההבטחות, הוגנות וברורות.

00:11:06.240 --> 00:11:07.580
ללא הסכמי רמת שירות, SRA,

00:11:07.840 --> 00:11:12.060
נציג עלול לעבוד לפי הפריט הישן ביותר ברשימה בזמן שמקרה רגיש לזמן עובר בשקט את הדד ליין שלו.

00:11:12.060 --> 00:11:17.060
עם SLS, מסך המקרה מציג מכווני זמן שאומרים לנציג איזו הבטחה דורשת תשומת לב קודם.

00:11:17.180 --> 00:11:19.060
כך, תוכלו לראות את הלחץ נבנה.

00:11:19.180 --> 00:11:20.980
מקרה עם הרבה זמן שנותר דורש עבודה,

00:11:20.980 --> 00:11:24.340
אבל מקרה שמתקרב לדד ליין המענה שלו דורש תשומת לב עכשיו.

00:11:24.520 --> 00:11:28.540
צוותים יכולים גם להגדיר התראות או שלבי הסלמה כאשר יעד קרוב או שכבר חלף,

00:11:28.780 --> 00:11:31.840
כדי שמנהל יוכל להתערב לפני שהלקוח יצטרך לרדוף אחרי הצוות.

00:11:31.840 --> 00:11:36.280
יעדי זמן מכוונים את הדחיפות ותהליכי עבודה עסקיים מכוונים את העבודה עצמה.

00:11:36.400 --> 00:11:39.720
תהליך עבודה עסקי הוא קבוצה של שלבים המוצגים בתוך המקרה.

00:11:39.840 --> 00:11:41.580
הוא נותן לנציג נתיב ברור למעקב,

00:11:41.580 --> 00:11:44.480
המבוסס על האופן שבו הארגון רוצה שהמקרים יטופלו.

00:11:44.600 --> 00:11:49.420
השלבים עשויים לעבור מקליטה לחקירה ולפתרון עם השאלות והבדיקות הנכונות בכל נקודה.

00:11:49.640 --> 00:11:52.420
חישבו על זה כעל רשימת תיוג עם מקום מוגדר בתהליך.

00:11:52.420 --> 00:11:56.540
נציג חדש לא צריך לנחש אילו פרטים חשובים לפני שליחת מקרה למומחה.

00:11:56.660 --> 00:12:01.340
התהליך יכול לבקש את המוצר, סוג הבעיה, ההשפעה ומידע אחר שהצוות הבא צריך.

00:12:01.340 --> 00:12:06.380
נציג מנושא יותר יכול לנוע מהר יותר, אבל הנתיב המשותף עדיין שומר על הצוות עובד באותו כיוון.

00:12:06.520 --> 00:12:07.560
הנה תרחיש לדוגמה.

00:12:07.700 --> 00:12:09.660
תקלת שירות בעדיפות גבוהה מגיעה.

00:12:09.780 --> 00:12:13.320
המקרה נכנס לתור הדחוף וה-SLA שלא מתחיל לספור לאחור.

00:12:13.320 --> 00:12:19.600
הנציג מאשר את פרטי הלקוח, מתעד את ההשפעה ושולח את המענה הראשון לפני שיעד המענה יפוג.

00:12:19.760 --> 00:12:25.860
לאחר מכן, תהליך העבודה מעביר את המקרה להבחון שבו הצוות אוסף פרטי שגיאה ובודק דוחות קשורים.

00:12:25.860 --> 00:12:30.780
המקרה עובר לאחר מכן לפתרון כאשר הצוות מזהה את הגורם ומכין עדכון ללקוח.

00:12:30.920 --> 00:12:33.540
הרצף הזה נותן גם למנהלים תמונה ברורה יותר.

00:12:33.540 --> 00:12:38.440
הם יכולים לראות היכן הטיפול מתעכב במהלך הקליטה, ההבחון או המענה הסופי ללקוח.

00:12:38.580 --> 00:12:43.240
התהליך לא פותר את הבעיה עבור הצוות, אך הוא מונע מצעדים בסיסיים ללכת לאיבוד ביום עמוס.

00:12:43.400 --> 00:12:48.360
דיינמיקס 365 יכולה גם לשלוט באילו שינויי סטטוס סוכנים יכולים לבחור בנקודות שונות.

00:12:48.360 --> 00:12:52.600
אלו נקראים מעברי סיבת סטטוס, מה שנשמע טכני, אך הרעיון פשוט.

00:12:52.760 --> 00:12:55.260
פנייה צריכה להתקדם דרך שלבים הגיוניים.

00:12:55.260 --> 00:12:59.460
לא תרצה שמישהו יסמן פנייה כפתורה בזמן שהיא עדיין ממתינה לבדיקה פנימית,

00:12:59.660 --> 00:13:02.380
או שיקפוץ מפנייה חדשה ישר לביטול ללא רישום סיבה.

00:13:02.500 --> 00:13:05.380
האפשרויות המותרות יכולות להשתנות ככל שהפנייה משתנה.

00:13:05.500 --> 00:13:10.280
למשל, פנייה שנמצאת בחקירה עשויה לאפשר לסוכן להעביר אותה להמתנה בזמן שממתינים לפרטי הלקוח.

00:13:10.280 --> 00:13:13.380
לאחר שהלקוח משיב, הסוכן יכול להחזיר אותה לעבודה פעילה.

00:13:13.460 --> 00:13:16.100
כשהבעיה נפטרת, הפנייה יכולה לעבור לסטטוס נפטרה.

00:13:16.280 --> 00:13:17.940
זה יוצר היסטוריית פניות נקייה יותר.

00:13:17.940 --> 00:13:20.000
תשובה בלבד אינה מסיימת את העבודה.

00:13:20.140 --> 00:13:23.840
הצוות צריך לתעד איך הבעיה הסתיימה, ואז לסגור את הפנייה כראוי.

00:13:23.940 --> 00:13:26.080
פתרון, למידה ושירות טוב יותר.

00:13:26.300 --> 00:13:29.120
שליחת תשובה לא סוגרת את הפנייה באופן אוטומטי.

00:13:29.120 --> 00:13:34.500
הצוות צריך לתעד את הפתרון, כלומר לכתוב מה פתר את הבעיה או איזו תשובה סופית הלקוח קיבל.

00:13:34.500 --> 00:13:40.480
זה עשוי להיות משלוח מכשיר חלופי, החזר על תשלום כפול או עדכון הגדרה שחסמה גישה מצד הלקוח.

00:13:40.640 --> 00:13:48.320
הערה זו הופכת לחלק מתיק הלקוח ונותנת לסוכן הבא נקודת פתיחה שימושית אם אותו לקוח פונה שוב לתמיכה חודשים לאחר מכן עם בעיה קשורה.

00:13:48.500 --> 00:13:50.280
לפעמים התיקון הראשון לא עובד.

00:13:50.480 --> 00:13:53.180
אולי הלקוח עוקב אחר ההוראות והשגיאה חוזרת.

00:13:53.180 --> 00:13:55.840
אולי חלק חילוף מגיע אך לא פותר את התקלה.

00:13:55.840 --> 00:14:02.780
במצב כזה הצוות יכול לפתוח מחדש את הפנייה או להחזיר אותה לתור להמשך טיפול במקום להתחיל רשומה חדשה לגמרי ללא היסטוריה.

00:14:02.960 --> 00:14:05.140
הפנייה ממשיכה מהמקום שבו הצוות עצר.

00:14:05.320 --> 00:14:06.980
זה חשוב כאשר הבעלות משתנה.

00:14:07.160 --> 00:14:11.900
סוכן חדש יכול לראות מה הסוכן הקודם ניסה, מה הלקוח אישר ומה עדיין דורש בדיקה.

00:14:12.000 --> 00:14:16.580
הלקוח לא צריך להסביר את כל הסיפור מהתחילה רק בגלל שאדם אחר לקח את הטיפול.

00:14:16.580 --> 00:14:21.500
עם הזמן, כל הפניות האלו גם מספרות לצוות התמיכה מה קורה מעבר לבעיה של לקוח אחד.

00:14:21.660 --> 00:14:26.580
מנהלים יכולים לבחון את זמן לפתרון שעוקב אחר כמה זמן לוקח לפנייה מהפתיחה ועד לסגירה.

00:14:26.680 --> 00:14:30.120
הם יכולים לבחון את זמן שלב שמראה איפה פניות מבלות את הזמן שלהן.

00:14:30.240 --> 00:14:36.440
הם יכולים גם לעקוב אחר פתרון במגע ראשון, כלומר באיזו תדירות האדם הראשון שמדבר עם הלקוח מצליח לפתור את הבעיה ללא העברה.

00:14:36.560 --> 00:14:38.020
אומס עבודה הוא גם משמעותי.

00:14:38.020 --> 00:14:41.380
אם תור אחד מתמלא בכל בוקר יום שני, הצוות יכול לראות זאת.

00:14:41.440 --> 00:14:45.880
אם פניות טכניות ממתינות ימים לבדיקה פנימית, העיכוב הזה מופיע בנתוני הפנייה.

00:14:46.000 --> 00:14:52.560
אם צוות מסוים סוגר פניות במהירות אך לקוחות ממשיכים לפתוח אותן מחדש, לצוות יש סיבה לבחון לעומק את איכות הפתרונות הראשוניים.

00:14:52.660 --> 00:14:54.780
המספרים כשלעצמם לא מסבירים הכל.

00:14:54.900 --> 00:14:57.100
הם מכוונים את הצוות לשאלות שכדאי לשאול.

00:14:57.240 --> 00:14:59.760
מדוע מספר הפניות לגבי מוצר מסוים נמצא בעלייה?

00:14:59.760 --> 00:15:02.640
מדוע סוג מסוים של פניות לוקח זמן רב מהצפוי?

00:15:02.760 --> 00:15:06.820
מדוע נציגים מחפשים שוב ושוב את אותה תשובה, אך לא מוצאים מאמר ידע שימושי?

00:15:06.960 --> 00:15:09.740
דפוסים הופכים עבודה יומיומית בתמיכה ללמידה מעשית.

00:15:09.920 --> 00:15:12.580
עלייה בפניות דומות עשויה להצביע על תקלה במוצר.

00:15:12.740 --> 00:15:15.160
ייתכן שהיא מראה שעדכון אחרון בלבל את הלקוחות.

00:15:15.280 --> 00:15:18.080
ייתכן שהיא חושפת שמדריך ההוראות זקוק לשלבים ברורים יותר.

00:15:18.080 --> 00:15:22.500
במקום להתייחס לכל בקשה כאל אירוע נפרד, הצוות יכול לזהות את הגורם המשותף ולטפל בו.

00:15:22.620 --> 00:15:24.440
זה יכול להפחית את כמות הפניות בעתיד.

00:15:24.580 --> 00:15:26.600
משוב מלקוחות שייך גם הוא לתמונה הזו.

00:15:26.700 --> 00:15:29.540
פנייה סגורה עשויה להראות שהצוות עמד ביעד המענה שלו,

00:15:29.780 --> 00:15:32.960
אך הלקוח עדיין עשוי להרגיש מתוסכל אם נאלץ לפנות לתמיכה שלוש פעמים.

00:15:33.180 --> 00:15:37.460
בחינה של היסטוריית הפניות ושל המשוב יחד מעניקה למנהלים תמונה מלאה יותר של חוויית הלקוח.

00:15:37.460 --> 00:15:40.180
יש לקוחות שיעדיפו להימנע מיצירת פנייה מלכתחילה.

00:15:40.280 --> 00:15:42.120
כאן פורטל שירות עצמי יכול לעזור.

00:15:42.340 --> 00:15:45.760
דרך פורטל, לקוחות יכולים ליצור בקשה, לבדוק את הסטטוס שלה,

00:15:45.920 --> 00:15:49.880
להוסיף מידע חדש או לקרוא מאמרי תמיכה מאושרים מבלי להתקשר לצוות התמיכה.

00:15:50.040 --> 00:15:52.780
עבור שאלות פשוטות, זה יכול לחסוך זמן לכולם.

00:15:52.780 --> 00:15:57.140
לקוח יכול לבדוק סטטוס משלוח או לעקוב אחר מדריך התקנה מתי שנוח לו.

00:15:57.140 --> 00:16:02.660
בינתיים, נציגים יכולים להקדיש יותר זמן לנושאים הדורשים גורם אנושי כדי לחקור, להסביר או לקבל החלטה.

00:16:02.780 --> 00:16:07.860
Dynamics 365 Customer Service יכול גם להתחבר לכלי מייקרוסופט מוכרים סביב תהליך הטיפול בפניות.

00:16:08.040 --> 00:16:10.440
נציג עשוי לעבוד עם דואר אלקטרוני דרך Outlook.

00:16:10.660 --> 00:16:12.740
צוות עשוי לדון בנושא מורכב בטימס.

00:16:12.740 --> 00:16:15.560
מסמכים ומידע משותף יכולים להישמר בשארפוינט.

00:16:15.680 --> 00:16:18.300
פאוור ביי יכול להפוך נתוני פניות לדוחות ולוחות בקרה,

00:16:18.300 --> 00:16:23.460
בעוד שכלי Power Platform יכולים לתמוך בתפסים נוספים, התראות או שלבים אוטומטיים סביב התהליך של הצוות.

00:16:23.620 --> 00:16:25.200
לכל כלי יש את התפקיד שלו.

00:16:25.340 --> 00:16:28.620
הפנייה נשאר את המקום שבו נושא התמיכה וההיסטוריה שלו נשארים מחוברים,

00:16:28.880 --> 00:16:32.520
גם כשאנשים משתמשים בחילים אחרים כדי לתקשר, לשתף קבצים או לזכור את העבודה.

00:16:32.520 --> 00:16:35.440
ניהול פניות אינו עוסק רק במילוי תופס על המסך.

00:16:35.560 --> 00:16:40.720
מדובר במתן מסלול ברור לכל בעיה של לקוח, תיעוד התשובה וצוות שיכול ללמוד ממה שקרה.

00:16:40.920 --> 00:16:41.380
סיכום.

00:16:41.380 --> 00:16:43.940
שימרו על סיפור הלקוח השלם במקום אחד.

00:16:44.140 --> 00:16:45.700
אז, הנה השורה התחתונה.

00:16:45.880 --> 00:16:51.740
ניהול המקרים בדיינמיקס 365 שומר את הבעיה, העבודה, ההבטחות והתוצאה ברשומה אחת.

00:16:51.880 --> 00:16:54.260
אין יותר הקשר שעבד או תיקונים חוזרים ונשנים.

00:16:54.260 --> 00:16:56.080
בכאן את תהליך התמיכה שלך.

00:16:56.220 --> 00:16:58.200
הוי, לאן נעלם המידע על הלקוח?

00:16:58.320 --> 00:17:00.980
כאן בדיוק ריכוז הכל למקום אחד משנה את התמונה.

00:17:01.140 --> 00:17:04.800
הרשמו בפלטפורמת הפודקסטים המועדפת עליכם לעוד פניני ידע על מייקרוסופט ממני,

00:17:04.800 --> 00:17:07.220
מרקו פיטרס ב-M365.fm,

00:17:07.440 --> 00:17:10.680
שם אנחנו מסבירים על כלי מייקרוסופט שמאחורי העבודה היומיומית בשפה פשוטה.