אוטומציית גבייה: מה נכון להפוך לאוטומטי ומה חייב אדם?

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

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

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

מה נכון להפוך לאוטומטי באוטומציית גבייה?

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

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

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

מה בגבייה ובתשלומים חייב להישאר אצל אדם?

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

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

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

למה אוטומציית גבייה נשברת כשהנתונים לא מסודרים?

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

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

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

איך מחברים את אוטומציית הגבייה למערכת הכספים?

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

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

מתי אוטומציית גבייה היא לא הפתרון הנכון?

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

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

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