Verikal.
← חזרה לספרייה

מדריך

איך בונים סוכן שרודף אחרי חשבוניות

walk-through מכוער ואמיתי של סוכן שמזכיר לקוחות שאיחרו, בלי להישמע כמו רובוט.

פורסם 8 במאי 2026 · 9 דקות קריאה

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

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

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

מה הוא בעצם עושה

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

  • 3 ימים בפיגור: דחיפה רכה. “רק להזכיר, אם זה נפל לכם בין הכיסאות.”
  • 14 ימים בפיגור: בקשה ברורה. עם מספר חשבונית, סכום, תאריך.
  • 30 ימים בפיגור: הודעה תקיפה שמזכירה השלכות בלי לאיים. שולחת לכם פינג ב-Slack.
  • 45+ ימים בפיגור: עוצר. כותב הערת hand-off, מכניס לתור שלכם. אדם ממשיך מכאן.

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

ארבעת החלקים

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

1. קריאה של העולם

משימה מתוזמנת מושכת חשבוניות פתוחות, פרטי לקוחות, חותמות זמן של פנייה אחרונה, ותשלומים אחרונים. אנחנו לא משתמשים פה ב-webhooks. cron מספיק. הסוכן לא צריך להיות real-time; אף אחד לא מחכה לתזכורת ב-9:03 במקום ב-9:00.

// כל יום עסקים, 9:00 שעון ישראל
schedule('0 9 * * 1-5', async () => {
  const invoices = await accounting.listOverdueInvoices();
  for (const invoice of invoices) {
    await maybeChase(invoice);
  }
});

2. שכבת כללים (לא ה-LLM)

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

function shouldChase(invoice, lastContact, today) {
  if (invoice.doNotContact) return null;
  if (invoice.paidAt) return null;
  const daysOverdue = daysBetween(invoice.dueDate, today);
  const daysSinceContact = lastContact
    ? daysBetween(lastContact, today)
    : Infinity;

  if (daysOverdue >= 45) return 'handoff';
  if (daysOverdue >= 30 && daysSinceContact >= 7) return 'firm';
  if (daysOverdue >= 14 && daysSinceContact >= 7) return 'clear';
  if (daysOverdue >= 3 && daysSinceContact >= 14) return 'soft';
  return null;
}

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

3. המודל — בשביל המילים, ורק בשבילן

עכשיו ה-LLM עושה את מה שהוא טוב בו: כותב הודעה קצרה, בטון הנכון, לא רובוטית, שמזכירה את מספר החשבונית, את הסכום, את תאריך היעד, ואת שם הלקוח. אנחנו נותנים לו את הטון (“רך” / “ברור” / “תקיף”) ואת חוקי הקול של החברה. אנחנו לא נותנים לו את כוח ההחלטה.

const draft = await claude.messages.create({
  model: 'claude-haiku-4-5',
  system: COMPANY_VOICE,
  messages: [{
    role: 'user',
    content: `כתוב מייל follow-up בטון "${tone}" לחשבונית
    ${invoice.number}, סכום ${invoice.amount}, יעד ${invoice.dueDate}.
    לקוח: ${customer.name}. תגובה אחרונה שלו: "${customer.lastReply ?? 'אין'}".
    אילוצים: עד 80 מילים, להזכיר את מספר החשבונית פעם אחת,
    בלי איומים, בלי סימני קריאה, בלי "באדיבותך".`,
  }],
});

אנחנו מתעדים את הטיוטה. תמיד. אם משהו מתחיל להיראות מוזר, אנחנו רוצים לדעת מה המודל עמד לשלוח.

4. בדיקת בטיחות לפני שליחה

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

הבעיות שתפגשו ביום השלישי

כל סוכן ששלחנו פגש את אותן בעיות בשבוע הראשון. תכננו אותן מראש.

תשלומים חלקיים

לקוח שילם חצי. מערכת הנהלת החשבונות שלכם אולי עוקבת אחרי זה ואולי לא. תתייחסו לכל חשבונית עם תשלום לא אפסי ב-14 הימים האחרונים כ-out-of-bounds עד שאדם יסתכל. העלות של טעות פה היא “לקוח שילם לכם משהו ואתם צעקתם עליו.” אל.

השהיית סנכרון

מערכת הנהלת החשבונות שלכם מסנכרנת מהבנק. הבנק לוקח יום. הלקוח שילם בהעברה ביום שלישי בבוקר; המערכת חושבת שהוא בפיגור ביום שלישי בערב. הוסיפו חלון חסד של 48 שעות מעבר לתאריך היעד הטכני, לכל חשבונית עם שיטת תשלום שאינה real-time.

ריטיינרים והכנסות חוזרות

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

דגל אל-תפנו-אליי

חלק מהלקוחות באמצע משא-ומתן מחודש. חלק פוטרו. חלק ב-hold עד שמשהו משפטי יסתיים. אתם צריכים override ידני שאומר “תעזבו את הלקוח הזה עד שאני אגיד.” זאת עמודה בטבלת לקוחות. הסוכן קורא אותה. זה כל הפיצ׳ר.

איפה זה נופל בלי כללים מסביב

ראינו אנשים שניסו לבנות את זה עם קריאת LLM אחת ופרומפט שאומר “בבקשה תעקוב אחרי חשבוניות שאיחרו ותפעל בהתאם.” זה לא עובד. לא כי המודל לא מספיק חכם — כי המערכת סביבו אין לה זיכרון של מה נשלח אתמול, אין לה idempotency, אין לה תיעוד של למה היא קיבלה החלטה מסוימת, ואין דרך לבטל כשהיא עושה משהו טיפשי.

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

שלושה ימים, לא שלושה חודשים

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

ואז זה רץ. בשקט. לנצח. ויום אחד אתם שמים לב שה-DSO ירד ב-12 ימים והמנהל החשבונות חזר לעשות חשבונות בפועל.

אם אתם רוצים שאנחנו נבנה

זה בדיוק מה ששירות הסוכנים שלנו עושה — 350 ש״ח לחודש לסוכן. אנחנו דואגים לאינסטלציית הנתונים, לשכבת הכללים, לאינטגרציה עם המודל, לבדיקות הבטיחות, לתיעוד. אתם מצביעים לנו על מערכת הנהלת החשבונות, נותנים לנו דוגמה של שלוש חשבוניות ושלושה מיילי follow-up אמיתיים שלכם (כדי שהסוכן יתאים לקול שלכם), ושבוע אחר כך זה רץ.

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


מצאתם פה דליפה? בואו נמצא יחד את הגדולה יותר.

קבעו שיחה — חינם
איך בונים סוכן שרודף אחרי חשבוניות — Verikal — Verikal