מה הופך הודעה לקריאה, איך מדרגים חומרה לפי השפעה כפול היקף, מה באמת עובר בהסלמה, ומי קובע שקריאה נפתרה. כולל ציר זמן מלא של טיפול בתלונה אחת.
עיקרי הדברים
- הנציג אינו מתרשל. ערוץ שיחה אינו מחזיק מצב, ולכן פנייה שנשארת בו אינה ניתנת לניטור, להסלמה או להעברה.
- חומרה נקבעת מהשפעה כפול היקף, ולא מטון הדיבור. לקוח רגוע שהמערכת שלו מושבתת דחוף יותר מלקוח כועס שהכפתור בצבע לא נכון.
- הסלמה מעבירה בעלות ומשנה קצב עדכון. הוספת מנהל לרשימת תפוצה אינה הסלמה, מפני שאיש לא עבר להיות האחראי.
- "נפתר" ו"נסגר" הם שני מצבים. נפתר הוא קביעה של מי שתיקן, נסגר הוא אישור של הלקוח או חלוף חלון האישור.
- ממשק וואטסאפ מגביל בזמן: Meta מתעדת חלון שירות של 24 שעות שמתאפס בכל הודעה נכנסת, ומחוצה לו נדרשת תבנית מאושרת. שיחה אינה מקום לאחסון קריאה פתוחה.
פנייה נשארת בשיחה של נציג אחד מפני שהשיחה עצמה היא הרישום. אין לה מזהה, אין לה דירוג חומרה, אין לה מועד יעד ואין לה קורא שני. הפיכת הודעה לקריאה היא רגע מוגדר: הרגע שבו נוצרת רשומה שמישהו אחר יכול למצוא בלי לבקש את הטלפון של הנציג.
למה פנייה דחופה נשארת בוואטסאפ של נציג אחד?
מפני שהערוץ אינו מחזיק אף אחד מהשדות שהופכים פנייה לניתנת לניהול. בשיחה אין מזהה שאפשר לחפש, אין שדה חומרה, אין מועד יעד ואין בעלים מוצהר. הנציג הוא היחיד שיודע שהפנייה קיימת, וברגע שהוא ביום חופש, היא לא קיימת עבור הארגון. למדריך מעשי ראו איך בונים בוט וואטסאפ.
יש גם אילוץ טכני קשיח. התיעוד של Meta לממשק Cloud API קובע שכאשר לקוח שולח הודעה נפתח טיימר של 24 שעות שנקרא חלון שירות, שהוא מתאפס בכל הודעה חדשה מהלקוח, וכדי לפנות ללקוח מחוץ לחלון יש להשתמש בהודעת תבנית מאושרת. קריאה שמחכה שלושה ימים לחלק חילוף אינה יכולה לחיות בתוך חלון של 24 שעות. מנגנוני התור והמשלוח שמאחורי זה מפורטים בתור הודעות וואטסאפ בנפח גבוה.
גבול ההמרה: מה הופך הודעה לקריאה
ההודעה הופכת לקריאה כשנוצרת רשומה עם השדות שמאפשרים לאדם אחר להמשיך אותה. פחות מזה זו עדיין שיחה.
| שדה | ערך לדוגמה | למה בלעדיו אין קריאה |
|---|---|---|
ticket_id | TCK-2026-04412 | מספר שאפשר למסור ללקוח ולחפש |
customer_id | CUS-8841 | קישור להיסטוריה, לא רק למספר טלפון |
severity | S2 | קובע קצב עדכון ומסלול הסלמה |
opened_at | 2026-10-14T08:41+03:00 | ממנו נמדד כל יעד |
owner_user_id | u_1174 | אדם אחד, לא צוות |
channel | whatsapp | איפה הלקוח מצפה לתשובה |
source_ref | מזהה ההודעה המקורית | מאפשר לחזור לשרשור המדויק |
state | in_progress | מצב אחד מתוך רשימה סגורה |
השדה source_ref הוא זה שמונע את התלונה הבאה. בלעדיו, נציג שמקבל את הקריאה ביום למחרת מבקש מהלקוח לספר שוב מה קרה, וזו החוויה שהופכת תקלה קטנה לתלונה על השירות. השורה שמעליו, channel, קובעת לאן חוזרים: לקוח שכתב בוואטסאפ ומקבל מייל תופס את זה כאי מענה. המרה דומה של הודעות נכנסות לרשומות מובנות מתוארת בהפיכת הזמנות בוואטסאפ לתור עבודה.
חומרה היא השפעה כפול היקף, לא טון דיבור
| רמה | השפעה | היקף | קצב עדכון ללקוח |
|---|---|---|---|
S1 | תהליך עסקי מושבת, אין דרך עוקפת | כל הלקוחות או לקוח קריטי | כל שעה |
S2 | תהליך פגוע עם דרך עוקפת מוכרת | קבוצת משתמשים או אתר אחד | פעמיים ביום |
S3 | תקלה מקומית, העבודה נמשכת | משתמש בודד | פעם ביום עבודה |
S4 | הערה, בקשת שיפור, שאלה | לא חוסם | בעדכון גרסה |
הטבלה הזאת היא דוגמה למטריצה שכל ארגון קובע לעצמו, ולא תקן. מה שחשוב הוא שהיא כתובה, שהיא מבוססת על שני צירים ולא על תחושה, ושהיא נקבעת בזמן הפתיחה על ידי מי שמקבל את הפנייה. שלוש הבהרות מעשיות:
- החומרה יכולה לעלות ולרדת, וכל שינוי נרשם עם סיבה. מי שהוריד חומרה אחראי להסבר.
- לקוח שדורש
S1אינו קובעS1. הוא מספק מידע על ההשפעה, וההיקף נקבע אצלכם. - כשלוש קריאות
S3מאותו לקוח באותו שבוע מצדיקות בדיקה כאילו היוS2אחת, מפני שהדפוס הוא הבעיה ולא כל אירוע בנפרד.
מה באמת עובר בהסלמה
הסלמה היא העברת בעלות עם סמכות רחבה יותר, ולא הוספת נמענים. Google מתארת בפרק על ניהול אירועים בספר ה-SRE מבנה שבו יש מפקד אירוע מוגדר ותפקידים נפרדים לטיפול ולתקשורת, וזה בדיוק מה שנשבר כשהסלמה מסתכמת בהוספת מנהל לשרשור. שלושה דברים משתנים בכל מדרגה:
- הבעלים משתנה לאדם אחד חדש, והקודם מסיים את תפקידו כאחראי. שני אחראים שווים לאפס.
- הסמכות משתנה: מדרגה שיכולה לאשר החלפת ציוד, לזמן ספק או לעצור גרסה.
- קצב העדכון ללקוח מתקצר בהתאם לחומרה, וזה מה שהלקוח מרגיש.
לכל מדרגה יש פסק זמן. אם אין תשובה בתוך הזמן שנקבע, הקריאה עוברת הלאה בעצמה ולא ממתינה. המנגנון זהה בעקרונו לזה שמתואר בבעלות ו-SLA בטיפול בלידים, אבל הכיוון הפוך: שם החשש הוא שהזדמנות תתקרר, וכאן שנזק שכבר קורה יימשך. לעלויות בנייה ותפעול ראו כמה עולה צ'אטבוט.
ציר זמן של קריאה אחת, TCK-2026-04412 בחומרה S2:
- 08:41 - הודעה נכנסת בוואטסאפ, נפתחת קריאה אוטומטית עם
source_ref. - 08:53 - נציג מדרגה ראשונה מאשר קבלה ומעדכן חומרה ל-S2.
- 09:41 - פסק הזמן של המדרגה הראשונה חלף בלי דרך עוקפת. הבעלות עוברת למומחה.
- 10:20 - נמצאה דרך עוקפת, הלקוח מקבל עדכון והחומרה יורדת ל-S3 עם סיבה רשומה.
- 11:05 - התיקון אומת אצל הלקוח. המצב עובר ל
resolved. - 13:05 - הלקוח אישר, המצב עובר ל
closed.
מי קובע שקריאה נפתרה?
מי שתיקן קובע resolved, והלקוח או חלוף הזמן קובעים closed. שני מצבים ולא אחד, מפני שהם עונים על שתי שאלות שונות: האם התקלה תוקנה, והאם הלקוח מסכים.
ההפרדה הזאת גם משנה את מה שאפשר למדוד. משך עד resolved מודד את הצוות הטכני, ומשך עד closed מודד את איכות התקשורת עם הלקוח. מערכת שמחזיקה מצב אחד בלבד מערבבת בין השניים, וכשהמספר עולה אי אפשר לדעת אם התיקון איטי או שהלקוחות פשוט אינם עונים.
resolvedנקבע על ידי המטפל, עם תיאור של מה נעשה בפועל ולא "טופל".closedנקבע באישור הלקוח, או אוטומטית אחרי חלון אישור שהוגדר מראש.- פתיחה מחדש בתוך חלון שנקבע מחזירה את הקריאה המקורית עם החומרה שלה, ולא פותחת קריאה חדשה. אחרת דוח הקריאות מראה שתי תקלות קטנות במקום תקלה אחת שלא נפתרה.
- קריאה שנסגרה אוטומטית מסומנת ככזאת, כי סגירה בשתיקה אינה שביעות רצון.
- כשהקריאה נסגרת בלי תיקון, נדרש ערך מפורש כמו
not_reproducibleאוby_design. סגירה בלי סיבה היא הדרך שבה אותה תלונה חוזרת בעוד חודש.
מקורות
שאלות נפוצות
האם צריך מערכת קריאות ייעודית מהיום הראשון?
לא, אבל צריך רשומה עם מזהה, חומרה, בעלים ומועד יעד מהיום הראשון. טבלה אחת עם שמונה עמודות עדיפה על שיחה, וגם עדיפה על מערכת גדולה שאיש אינו ממלא. המעבר למערכת ייעודית מוצדק כשההסלמה האוטומטית והדוחות מתחילים לעלות יותר זמן מהטיפול עצמו.
איך מגדירים חומרה כשהלקוח והנציג לא מסכימים?
הנציג קובע לפי המטריצה, והלקוח מספק את המידע על ההשפעה. אי הסכמה נרשמת בקריאה ומועברת עם ההסלמה, כך שהמדרגה הבאה רואה גם את הדירוג וגם את ההסתייגות. מטריצה כתובה הופכת את הוויכוח מוויכוח על רגשות לוויכוח על שני שדות.
מה עושים עם תלונה שהגיעה בערוץ אישי של עובד?
מעבירים אותה לרשומה מיד ומשיבים ללקוח בערוץ הרשמי עם מספר הקריאה. אין טעם להילחם בערוץ שהלקוח בחר, אבל יש הכרח שההודעה תיהפך לרשומה. עובד שעובר לתפקיד אחר לא יכול לקחת איתו את התלונות הפתוחות.
כמה זמן להשאיר קריאה פתוחה ללא תגובת לקוח?
מגדירים חלון אחד לכל החומרות, למשל חמישה ימי עסקים, שולחים תזכורת אחת לפני הסגירה, וסוגרים עם ערך שמציין שהסגירה הייתה מחוסר תגובה. חשוב שפתיחה מחדש תחזיר את אותה קריאה, כדי שהמדידה תראה את משך הטיפול האמיתי ולא שתי קריאות קצרות.
להמשך קריאה
שירות רלוונטי
WhatsApp Cloud API
תבניות, אינבוקס דו-כיווני ותזכורות על ה-API הרשמי של Meta.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.