תקלה במערכת עסקית: איך מאפיינים עדכוני מצב ללקוחות?

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

מה אפשר ללמוד מהאירוע של Toll?

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

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

אפיינו השפעה על פעולות, ולא רק צבע ירוק או אדום

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

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

הפרידו בין זמן תיקון לבין מועד העדכון הבא

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

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

קבעו מי מעדכן ואיך מגיעים למידע כשהמוצר אינו זמין

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

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

בדקו גם את ההודעה שהאירוע הסתיים

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

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

מה לבקש בהצעת הפיתוח?

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

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