עלות Agentforce: צריכה, רישיונות ו-TCO של סוכן ארגוני

התשובה הקצרה

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

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

חמשת רכיבי ה-TCO

עלות למשימה: הנוסחה שכדאי לבנות

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

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

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

מה באמת מייקר בפועל

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

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

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

הקשר בין איכות מקורות המידע לעלות מפורט בGrounding ו-RAG ב-Agentforce.

בקרות תקציב שכדאי להקים מראש

תקרה חודשית מוגדרת לכל Use Case, עם התראה לפני שמגיעים אליה. בלי תקרה, גילוי החריגה מגיע בחשבונית.

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

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

איך מקימים את הניטור שמזין את הבקרות מפורט בObservability לסוכני AI.

תרחיש: פיילוט שנראה יקר והתברר כזול

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

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

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

מתי הסוכן פשוט לא משתלם

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

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

סיכונים ופעולות מניעה

מדדים כלכליים

כאשר נדרש מודל כלכלי שיעמוד בביקורת פנימית לפני החלטת השקעה, שירות Agentforce ו-AI הוא המסלול המעשי להמשך.

Checklist לבניית מודל עלות

• ☐ חמשת רכיבי ה-TCO תומחרו בנפרד
• ☐ הוגדר מה נחשב "משימה שהושלמה" בידי בעל התהליך
• ☐ נמדד Baseline של עלות הטיפול הקיים
• ☐ נקבעה תקרת צריכה חודשית לכל Use Case
• ☐ קיים פירוק עלות ברמת Use Case ולא רק ארגון
• ☐ תוקצבו ניטור ותחזוקת תוכן לשנה הראשונה
• ☐ הוגדר מספר ניסיונות מרבי לפני הסלמה
• ☐ נקבע סף כלכלי שבו הסוכן מושעה או נסגר