התשובה הקצרה
Sales Cloud מנהל עסקה שמתקדמת - יחידת עבודה שחיה שבועות או חודשים, נמדדת בהסתברות סגירה, ומצליחה כשהיא נסגרת. Service Cloud מנהל פנייה שנפתרת - יחידת עבודה שחיה שעות או ימים, נמדדת בזמן תגובה ופתרון, ומצליחה כשהיא נסגרת מהר וללא חזרה.
ההבדל הזה, ולא רשימת הפיצ'רים, קובע את הבחירה. אם מנהלים Pipeline - Sales Cloud. אם מנהלים תור עם SLA - Service Cloud. אם מנהלים לקוח שקונה וגם מתלונן - שניהם, על אותו Account.
ההבדל במונחים תפעוליים
| ממד | Sales Cloud | Service Cloud |
|---|---|---|
| אובייקט מרכזי | Opportunity | Case |
| מחזור חיים | שבועות עד חודשים | שעות עד ימים |
| מדד מוביל | Win rate, Forecast accuracy | First response, FCR, CSAT |
| מנגנון הקצאה | בעלות אישית לאורך זמן | Routing דינמי לפי זמינות |
| מקור עומס | מספר עסקאות פעילות | פיקים בלתי צפויים בערוצים |
| רכיב ידע | Playbooks ותמחור | Knowledge Base מובנה |
השורה החשובה ביותר היא מנגנון ההקצאה. במכירה, בעלות אישית היא ערך - הלקוח רוצה איש קשר קבוע. בשירות, בעלות אישית היא תקלה - היא יוצרת תורים אישיים שנתקעים כשנציג בחופשה.
מתי הבחירה ברורה
Sales Cloud בלבד מתאים לארגון שמוכר בתהליך מתמשך ובו התמיכה שלאחר המכירה מינימלית או מטופלת אצל שותף - למשל ספק ציוד שמוכר דרך משווקים ואינו מפעיל מוקד.
Service Cloud בלבד מתאים לארגון שכל האינטראקציה שלו עם הלקוח היא טיפול בבקשות - חברת שירותים תפעולית, גוף ציבורי, או ספק תשתית עם חוזים קיימים.
שניהם נדרשים כשקיים חידוש, Upsell או שימור: ברגע שנציג שירות צריך לדעת שהלקוח בתהליך חידוש, ונציג מכירות צריך לדעת שהלקוח פתח שלוש תקלות חמורות החודש - ההפרדה הופכת למכשול.
איך מחברים בלי לשכפל נתונים
זו הנקודה שבה הטמעות משולבות נכשלות. הכלל: Account ו-Contact הם שכבה משותפת אחת. אין "לקוח מכירות" ו"לקוח שירות" נפרדים.
מכאן נגזרות שלוש הכרעות:
- בעלות על רשומת הלקוח - מי מעדכן פרטי קשר, כתובת ומבנה ארגוני. בדרך כלל השירות, כי הוא מדבר עם הלקוח בתדירות גבוהה יותר.
- נראות הדדית - נציג שירות רואה עסקאות פתוחות ברמת קריאה בלבד; נציג מכירות רואה תקלות פתוחות ומדד שביעות רצון. שני הכיוונים נקבעים במודל ה-Sharing, לא בהעתקת שדות.
- טריגרים חוצי תחומים - תקלה קריטית אצל לקוח בחידוש מייצרת התראה למנהל התיק. זה מנגנון שווה יותר מכל דשבורד משולב.
עומק בנושא הרשאות ונראות מופיע במודל Sharing ונראות ב-Salesforce.
רישוי: מה שחשוב לדעת לפני שמשווים מחירים
רישיון Service Cloud הוא על-קבוצתי - הוא כולל את יכולות Sales Cloud הבסיסיות, ולכן משתמש שצריך את שניהם אינו זקוק לשני רישיונות. הכיוון ההפוך אינו קיים: רישיון Sales אינו כולל Case management, Entitlements או Knowledge.
המשמעות המעשית: חישוב עלות נכון מתחיל במיפוי משתמשים לפי מה שהם באמת עושים, לא לפי המחלקה שהם שייכים אליה. נציג שנתיים בשנה נוגע בעסקה אינו משתמש מכירות.
סדר ההטמעה כשצריך את שניהם
הטמעה מקבילה נראית יעילה ובפועל מכפילה סיכון: שני תהליכים שמשתנים בו-זמנית, שתי קבוצות משתמשים בהדרכה, ואי-אפשרות לייחס שיפור או כשל למקור.
הסדר המומלץ הוא להתחיל בצד עם הכאב המדיד יותר - בדרך כלל שירות, כי זמן תגובה ונטישה נמדדים כבר היום - ולהוסיף את הצד השני אחרי שני חודשי הפעלה יציבה. השכבה המשותפת (Account, Contact, הרשאות) נבנית בגל הראשון גם אם רק צד אחד עולה לאוויר, אחרת הגל השני יחייב פירוק.
סיכום
השאלה איננה איזה מוצר טוב יותר אלא איזו יחידת עבודה הארגון מנהל: עסקה שמתקדמת או פנייה שנפתרת. רוב הארגונים הבוגרים מנהלים את שתיהן, ואז ההכרעה האמיתית היא לא מה לקנות אלא איך לשמור על שכבת לקוח אחת מתחת לשניהם.