מלכ"רים · גיוס תרומות מוסד חינוך אמריקאי ללא מטרות רווח
גביית תרומות חוזרת שיודעת מתי לא לרוץ
Salesforce / SOLA / Hebcal מאות חיובים ביום כחצי שנה בפרודקשן
מלכ"רים · גיוס תרומות מוסד חינוך אמריקאי ללא מטרות רווח
Salesforce / SOLA / Hebcal מאות חיובים ביום כחצי שנה בפרודקשן
כשלים טכניים ב-18,578 ניסיונות חיוב, יולי עד ספטמבר 2026
ימים רצופים שבהם התהליך רץ, בלי יום חסר ובלי כשל
אנחנו מספרים כל מקרה באותה צורה: לא רק מה היה האתגר ומה הייתה התוצאה, אלא איך תכננו את הזרימה ופתרנו אותה שלב-שלב. באוטומציה, ה"איך" הוא מה שמחזיק בפרודקשן. זה החלק ששווה לקרוא.
לפני התהליך, גביית התרומות החוזרות הייתה ידנית מקצה לקצה.
מאות תורמים בכל יום, כרטיס אחר כרטיס, סכום אחר סכום, מול מסך הסליקה. זו לא הייתה משימה של שעה: היא נמשכה שעות, ולעיתים ימים, וכל יום שנוסף דחף את הגבייה הלאה ממועד הפירעון שנקבע.
העלות האמיתית לא הייתה הזמן אלא החשיפה. כל אחת משלוש הנקודות האלה היא מקום שבו תורם עלול להיות מחויב פעמיים, בסכום שגוי, או לא להיות מחויב כלל. במוסד שחי מתרומות חוזרות, טעות בגבייה אינה תקלה תפעולית אלא פגיעה באמון של התורם.
המוסד אינו מבצע פעולות מסחריות בשבת ובחגים. תהליך ידני שומר על זה מעצמו, כי מי שמפעיל אותו אינו במשרד. תהליך אוטומטי לא שומר על זה מעצמו, ולכן זו הייתה דרישה מפורשת מהיום הראשון, לפני כל דרישה תפעולית אחרת.
איך חשבנו על זה
תרחיש יומי אחד שמושך מ-Salesforce את כל החיובים שהגיע מועדם, מעביר אותם לסליקה ב-SOLA ומחזיר את התוצאה המלאה לרשומה. הפעולה הראשונה בכל ריצה אינה נגיעה בנתונים: היא שאלה אחת מול לוח השנה העברי.
הרעיון שהוביל את הבנייה היה שאוטומציה במוסד תורני צריכה לשמור מצוות בדיוק כמו האנשים שהיא משרתת. זו לא הייתה דרישה שנוספה בסוף, וגם לא סעיף בבדיקת קבלה. היא הצעד הראשון בתרחיש, לפני כל שאילתה ולפני כל נגיעה בנתונים.
כל חיוב מסומן כממתין ברשומה לפני שהוא נשלח. נפילה באמצע הריצה אינה יכולה לייצר חיוב כפול.
סירוב אחד אינו סוף הדרך. החיוב חוזר למחזור ניסיונות עם תקרה שיושבת בקונפיגורציה ולא בקוד, וניתנת לשינוי בלי לגעת בתרחיש.
רשומה שאין לה חשבון סולק מתאים נסגרת עם קוד שגיאה מפורש, במקום להידלג עליה בשקט.
המשפט שמסכם את הגישה: תהליך שגובה כסף במקום אנשים צריך להיות שמרן יותר מהם, לא מהיר יותר.
איך בנינו את הלוגיקה
המוסד גובה תרומות חוזרות בכרטיס אשראי, לפי מועדי פירעון שנקבעים מראש ב-Salesforce. התרחיש רץ פעם ביום בשעה קבועה, ומטפל בכל מה שהגיע מועדו. זה אינו webhook: זה תהליך פיננסי מלא, עם שער תנאי בכניסה ועם החלטה נפרדת לכל חיוב.
החיובים אינם רצים בטור אלא במקביל, וכל ניסיון חיוב מקבל את מזהה העסקה כשם הריצה שלו. חודשיים אחורה אפשר לפתוח כל תרומה בודדת ולראות מה בדיוק קרה לה, מתי, וכמה פעמים.
שער תנאי שנשען על שירות חיצוני לפני שהזרימה בכלל מתחילה, ניתוב לפי יום בשבוע, שאילתה שמאחדת שתי קבוצות רשומות שונות, החלטה נפרדת לכל רשומה, ומדרג ניסיונות ששומר מצב לאורך ימים. אוטומציה מנקודה לנקודה מטפלת בצעד אחד. כאן יש תהליך.
תקרת הניסיונות, רשימת חשבונות הסולק והמיפוי בין קמפיין לחשבון הם דברים שמשתנים בעולם האמיתי. כאן הם יושבים כרשומות ב-Salesforce, והלוגיקה עצמה נערכת ב-Builder ויזואלי. אף אחד מהם אינו דורש מפתח.
הדרישה שהתהליך לא ירוץ בשבת ובחג אינה תוספת, היא המודול הראשון. Make Enterprise מאפשר לשבץ קטע קוד כמודול בתוך התרחיש, ולכן הבדיקה מול לוח השנה העברי היא בועית אחת שכל מי שפותח את התרחיש רואה, לא לוגיקה שקבורה בשירות צדדי.
כל ניסיון חיוב הוא ריצה נפרדת בשם מזהה העסקה, עם לוג מלא של מה נשלח ומה חזר. כשמדובר בגבייה מתורמים, היכולת לפתוח מקרה בודד ולהראות בדיוק מה קרה בו היא חלק מהמוצר, לא כלי דיבאג.
התהליך בפרודקשן כחצי שנה. המספרים כאן הם חלון המדידה של החודשיים האחרונים, לא כל הסיפור.
תהליך שגוזל זמן לאנשים אבל אין לו בעלים מובהק לפיתוח. זה בדיוק מה ש-Make Enterprise פותר.