מדריך Revenue Cloud: ARM, RCA, RCB ומעבר מ-Salesforce CPQ

המונחים סביב Revenue Cloud השתנו לא מעט בשנים האחרונות: Revenue Lifecycle Management, ‏Revenue Cloud Advanced, ‏Revenue Cloud Billing, ‏Agentforce Revenue Management. המדריך הזה עושה סדר. הוא מבוסס על פרויקטי Revenue Cloud שאנחנו מובילים ב-Meir IT עבור חברות SaaS, חברות שירותים ויצרנים, ונכתב עבור צוותי מכירות, כספים ו-IT בחברות ישראליות שבוחנות את המערכת.

מה זה Revenue Cloud (ARM)?

Revenue Cloud הוא הפתרון של Salesforce לניהול כל מחזור ההכנסות: להגדיר מה מוכרים ובאיזה מחיר, להרכיב את ההצעה, לתמחר אותה בהצעת מחיר, להפוך אותה להזמנה, לחוזה ולנכסים, לחדש אותה – ולבסוף לחייב. Salesforce משווקת אותו כיום בשם Agentforce Revenue Management (ARM), כדי להדגיש את מקומם של סוכני ה-AI בתהליכים האלה. בפועל, הצוותים והתיעוד עדיין מדברים הרבה על "Revenue Cloud", "RCA" ו-"RCB".

ההבדל המהותי מהדורות הקודמים: Revenue Cloud בנוי בתוך הליבה של פלטפורמת Salesforce, על האובייקטים הסטנדרטיים (Quote, ‏Order, ‏Asset, ‏Contract ועוד), ולא כ-managed package שמותקן מעל המערכת. זה משנה את האופן שבו מגדירים אותו, מרחיבים אותו ומפתחים אותו לאורך זמן.

ARM, ‏RCA ו-RCB: מה ההבדל?

• ARM (Agentforce Revenue Management) – השם המסחרי הנוכחי של כל הצעת Revenue Cloud.
• RCA (Revenue Cloud Advanced) – החלק של "לפני המכירה וניהול מחזור החיים": קטלוג, מחירים, קונפיגורציה, הצעות מחיר, הזמנות, תזמור, חוזים, נכסים, חידושים ושימוש.
• RCB (Revenue Cloud Billing) – רכיב החיוב: תוכניות חיוב, חשבוניות, זיכויים, מסים, רישום לחשבונות הנהלת החשבונות, תשלומים ותזכורות. RCB נשען על ההזמנות והנכסים שמנוהלים ב-RCA.

אפשר להטמיע RCA בלי RCB – ואז החיוב נשאר במערכת ה-ERP, שמקבלת את ההזמנות מ-Salesforce. לעומת זאת, RCB הגיוני רק יחד עם ההזמנות ש-RCA מייצר. השמות המדויקים של הרישיונות והיקפם משתנים מעת לעת, ולכן כדאי תמיד לוודא מול נציג Salesforce מה בדיוק כלול בחוזה שלכם.

ממה בנוי Revenue Cloud?

Product Catalog Management (PCM)

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

Salesforce Pricing

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

Product Configurator

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

Transaction Management: הצעות מחיר והזמנות

כאן מנוהלים הצעת המחיר (Quote), האישורים שלה, הפקת ה-PDF וההמרה להזמנה (Order). אותו מודל משמש למכירה חדשה, לשינויי חוזה (amendments) – למשל הוספת רישיונות באמצע תקופה – לחידושים ולביטולים.

Dynamic Revenue Orchestrator (DRO)

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

חוזים, נכסים וחידושים

אחרי שההזמנה מופעלת, Revenue Cloud יוצר או מעדכן את הנכסים (Assets) של הלקוח, עם היסטוריית כמויות ומחירים לאורך זמן. הנכסים האלה הם הבסיס לשינויי חוזה, לחידושים ולביטולים. החוזה מרכז את ההתחייבויות והתנאים.

Usage Management

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

Billing (RCB)

RCB הופך הזמנות ושימוש ללוחות חיוב, ואז לחשבוניות ולזיכויים, תוך החלת כללי מס, ישות משפטית ורישום חשבונאי.

למי Revenue Cloud מתאים?

Revenue Cloud מצדיק את עצמו כשתהליך המכירה הוא יותר מהצעת מחיר פשוטה מתוך מחירון:

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

אם אתם מוכרים מעט מוצרים במחיר קבוע עם הצעות מחיר פשוטות, Sales Cloud עם הצעות המחיר הסטנדרטיות שלו מספיק בדרך כלל – לחבילת Quickstart Sales Cloud יש תוספת של הצעות מחיר פשוטות (פרטים בעמוד החבילות). Revenue Cloud מתחיל להשתלם כשהמורכבות של ההצעה, של מחזור החיים של הלקוח או של החיוב עולה לכם בהקלדות כפולות, בטעויות ובעיכובים.

Revenue Cloud מול Salesforce CPQ

Salesforce CPQ (לשעבר Steelbrick) ו-Salesforce Billing הם managed packages שמותקנים בתוך ה-org. Salesforce מפנה כיום לקוחות חדשים ל-Revenue Cloud Advanced במקום לחבילת ה-CPQ הוותיקה, ומרכזת את ההשקעה בפלטפורמה המובנית. אלה ההבדלים שחשובים בפועל:

איך עוברים מ-Salesforce CPQ ל-Revenue Cloud?

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

1. מיפוי מה שקיים: מוצרים ו-bundles, price rules, ‏product rules, קוד ב-Quote Calculator Plugin, תבניות הצעות מחיר, תהליכי אישור ואינטגרציות. זו גם ההזדמנות לזרוק כללים שאף אחד כבר לא משתמש בהם.
2. תכנון מחדש ולא העתקה: הרבה ממה שנכתב ב-CPQ כקוד או ככללים נפרדים מתבטא ב-RCA דרך מאפיינים, decision tables ואילוצים.
3. הסבת נתונים: החלק הרגיש הוא החוזים והמנויים הפעילים, כי עליהם יתבססו החידושים ושינויי החוזה הבאים. צריך להחליט מה מוסבים כנכסים ומה נשאר כהיסטוריה.
4. מעבר מדורג: מתחילים בקו מוצרים או בסוג עסקה אחד, מאמתים את המודל, ורק אז מרחיבים.
5. החלטה על החיוב: Salesforce Billing, ‏RCB או ERP – כדאי לסגור את זה מוקדם, כי זה משפיע על כל המודל.

דוגמאות מפרויקטים

• Memoritz (RCA + RCB): הצעות מחיר עם מוצרים מורכבים וחידושים, ניהול תהליכי אחרי המכירה והחלק של ה-ERP דרך ה-DRO של RCA, וחיוב שנגזר מההזמנות בפועל.
• Coptis (RCA + RCB): הצעות מחיר ל-SaaS שמשלבות מנויים ודמי הקמה, שינויי חוזה וכללים חוזיים, וחיוב בתדירות שכל לקוח בוחר.
• Nowbrains (RCA): מוצרים מורכבים שמשלבים רכיב חוזר וימי עבודה, מחזור חידוש–הזמנה–חוזה, וקישור ל-Field Service.
• Transvalor (RCA): הצעות מחיר שמותאמות למאפייני ההצעה שלהם, תוך שמירה על האינטגרציה הקיימת עם Sage להנהלת החשבונות.

עוד פרויקטים בעמוד סיפורי הלקוחות.

איך נראה פרויקט Revenue Cloud?

1. אפיון: מיפוי הקטלוג, המחירונים, כללי ההנחות והאישורים, מחזור החיים החוזי והממשקים ל-ERP. כאן מחליטים מה שייך ל-RCA, מה ל-RCB ומה נשאר ב-ERP.
2. מידול הקטלוג: סוגי מוצרים, מאפיינים, bundles. אנחנו מתחילים בכוונה בהיקף מצומצם – כעשרה מוצרים מייצגים – כדי לאמת את המודל.
3. תמחור וקונפיגורציה: pricing procedures, ‏decision tables וכללי קונפיגורציה.
4. הצעות מחיר ומסמכים: עיצוב ה-PDF, תהליך האישור והמרה להזמנה.
5. מחזור חיים: הזמנות, חוזים, נכסים, שינויי חוזה, חידושים, ובמידת הצורך תזמור ב-DRO.
6. חיוב (RCB) או ממשק ל-ERP.
7. הסבת נתונים, בדיקות, הדרכה ועלייה לאוויר, ואחר כך הרחבה לשאר הקטלוג.

Revenue Cloud ו-Agentforce

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

טעויות נפוצות שכדאי להימנע מהן

• להעתיק את הקטלוג מה-ERP כמו שהוא: קטלוג מכירות הוא לא עץ מוצר של ייצור. צריך לחשוב אותו מחדש מנקודת המבט של המכירה.
• לכתוב קוד לכל מקרה קצה: רוב הצרכים נפתרים במאפיינים, ב-decision tables ובאילוצים. קוד צריך להיות החריג.
• לשכוח את מחזור החיים: הצעת מחיר מוצלחת שמייצרת נכסים לא עקביים תהפוך את החידושים ואת החיוב לכאב ראש.
• לדחות את שאלת ה-ERP: החליטו מוקדם מה Salesforce מחייב ומה ה-ERP רושם.