גבייה מלקוחות שלא משלמים: אוטומציה עם תרחישי טיפול ולא רק תזכורת

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

תמונת החוב לפני ההודעה הראשונה

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

היתרה האמיתית לגבייה היא 5,800 ש"ח על 0944 בלבד: 14,200 פחות 6,000 תקבול פחות 2,400 זיכוי. מערכת שמסכמת "חשבוניות פתוחות" תשלח תזכורת על 21,700 ש"ח - סכום שלא קיים - ותכלול בה חוב שנוי במחלוקת. הלקוח יענה בכעס, איש הכספים יבלה שעה בהתנצלות, וה-5,800 האמיתיים יידחו בשבועיים.

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

שישה מצבים שכל חוב נמצא באחד מהם

• current - טרם הגיע מועד התשלום. אין פעולה.
• overdue - עבר המועד, אין מחלוקת ואין הסדר. מסלול תזכורות.
• disputed - הלקוח הודיע על מחלוקת בשורה או בסכום. האוטומציה נעצרת, נפתחת משימה לבירור.
• promised - הלקוח נתן הבטחת תשלום עם תאריך. המתנה עד התאריך, ואז בדיקה.
• arrangement - סוכם פריסה או דחייה מתועדים. מעקב לפי לוח התשלומים, לא לפי גיל החוב.
• handover - התיק יצא מהאוטומציה לטיפול אדם או גורם מוסמך. אין הודעות אוטומטיות.

המעברים מוגדרים: overdue יכול לעבור ל-disputed, ל-promised, ל-arrangement או ל-handover. promised חוזר ל-overdue אם התאריך חלף בלי תקבול, וזו הפעם היחידה שבה חוב "מחמיר" אוטומטית. disputed אינו חוזר ל-overdue בלי החלטה אנושית מתועדת.

למה חוב במחלוקת חייב לצאת מהתור?

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

• על מה המחלוקת - מספר מסמך ומספר שורה, לא "הלקוח לא מרוצה".
• סכום שנוי במחלוקת - 3,000 מתוך 7,500, ולא כל המסמך. יתרת המסמך ממשיכה במסלול הרגיל.
• מי בודק - שם, לא מחלקה.
• תאריך יעד לתשובה - וזו התחייבות פנימית שנמדדת.

הפרדת הסכום היא הנקודה המעשית. בתיק שלמעלה, אם הלקוח חולק על 3,000 ש"ח מתוך 7,500, אין סיבה שה-4,500 הנותרים ייעצרו. מערכות רבות עוצרות מסמך שלם כי שדה המחלוקת יושב על המסמך ולא על השורה - וזו אותה בעיית רזולוציה שמתוארת בקישור הצעה, הזמנה וחשבונית במזהה אחד.

הבטחת תשלום כרשומה, לא כהערה

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

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

מי מטפל בכל דלי, ומתי אדם לוקח את התיק

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

מה מודדים כדי לדעת שהתהליך עובד?

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

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

מקורות

• מס"ב - חיובים על פי הרשאה
• מס"ב - העברת הרשאות לחיוב חשבון