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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

צוות עשוי לדון בנושא מורכב בטימס. מסמכים ומידע משותף יכולים להישמר בשארפוינט. פאוור ביי יכול להפוך נתוני פניות לדוחות ולוחות בקרה, בעוד שכלי Power Platform יכולים לתמוך בתפסים נוספים, התראות או שלבים אוטומטיים סביב התהליך של הצוות. לכל כלי יש את התפקיד שלו. הפנייה נשאר את המקום שבו נושא התמיכה וההיסטוריה שלו נשארים מחוברים, גם כשאנשים משתמשים בחילים אחרים כדי לתקשר, לשתף קבצים או לזכור את העבודה. ניהול פניות אינו עוסק רק במילוי תופס על המסך. מדובר במתן מסלול ברור לכל בעיה של לקוח, תיעוד התשובה וצוות שיכול ללמוד ממה שקרה. סיכום. שימרו על סיפור הלקוח השלם במקום אחד. אז, הנה השורה התחתונה. ניהול המקרים בדיינמיקס 365 שומר את הבעיה, העבודה, ההבטחות והתוצאה ברשומה אחת. אין יותר הקשר שעבד או תיקונים חוזרים ונשנים. בכאן את תהליך התמיכה שלך. הוי, לאן נעלם המידע על הלקוח? כאן בדיוק ריכוז הכל למקום אחד משנה את התמונה. הרשמו בפלטפורמת הפודקסטים המועדפת עליכם לעוד פניני ידע על מייקרוסופט ממני, מרקו פיטרס ב-M365.fm, שם אנחנו מסבירים על כלי מייקרוסופט שמאחורי העבודה היומיומית בשפה פשוטה.