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

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

מה קרה בהודעות של Grail?

ביוני 2023 דיווח MedTech Dive על הודעות שגויות שנשלחו לכ־400 אנשים. לפי הודעת Grail שצוטטה בכתבה, מכתבים עם מידע לא נכון הופעלו עקב בעיית הגדרה בתוכנה אצל ספק הטלרפואה PWNHealth, ולא בעקבות תוצאת מעבדה שגויה. זהו תיאור החברה של האירוע ההיסטורי; הוא אינו מוכיח שלבדיקה אין טעויות בכלל ואינו קביעה שלנו לגבי איכותה הרפואית.

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

מתחילים מהמצב העסקי, לא מתבנית המייל

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

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

מפרידים בין שמירה, שליחה ומסירה

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

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

בודקים גם נמען, שפה וקישור

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

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

מונעים כפילות ומכינים דרך לעצור

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

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

מה משתנה כאשר AI מנסח את ההודעה?

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

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