התשובה הקצרה

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

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

את ההשלכות המעשיות של הנקודה הזו על Sales Cloud לעומת Service Cloud פירטנו בנפרד בהטמעת Sales Cloud.

מה ההחלטה שהמאמר עוזר לקבל?

המטרה איננה לייצר עוד רשימת Best Practices, אלא לאפשר לארגון לקבל החלטה אחראית לגבי Sales Cloud לעומת Service Cloud. החלטה טובה מגדירה ארבעה דברים: תוצאה עסקית, Owner, גבולות פתרון וראיה שתוכיח שהפתרון עובד. ב-Salesforce יש כמעט תמיד כמה דרכי מימוש אפשריות; הערך של ארכיטקטורה הוא לבחור ביניהן לפי ההקשר ולתעד את ה-Trade-offs.

ארבעת מוקדי ההחלטה

נושא החלטהשאלה עסקיתשאלה ארכיטקטוניתראיה נדרשת
מטרות ותהליכי ליבהאיזה Outcome עסקי נדרש ומי אחראי עליו?מהו מקור האמת ואילו הרשאות חלות?תהליך מאושר ו-Baseline
אובייקטים וממשקי עבודהמה נכנס ל-Scope ומה נשאר במפורש בחוץ?אילו מערכות, נתונים והחלטות תלויות בכך?Scope, ADR ותלויות מתועדות
אוטומציות ומדדיםמי מבצע את העבודה ומה משתנה ביום-יום?כיצד מטפלים בחריג, בעומס ובכשל חלקי?תרחיש End-to-End ותוצאת בדיקה
מתי צריך את שניהםאיזה KPI יוכיח שההחלטה יצרה ערך?כיצד בודקים, מנטרים ומשנים בבטחה?Dashboard, Sign-off ותוכנית תפעול

מטרות ותהליכי ליבה

השלב של מטרות ותהליכי ליבה קובע את איכות ההחלטות שבאות אחריו. במקרה של Sales Cloud לעומת Service Cloud, המשמעות היא הגדרת תהליך מכירה או שירות מקצה לקצה לפני התאמת מסכים ואובייקטים. צריך לכתוב מי מקבל את ההחלטה, מהו הגבול ואיזו ראיה נדרשת לפני שמתקדמים. אחרת, פער קטן בהגדרה מתגלגל ל-Data Model, לאוטומציות, לבדיקות ולחוזה.

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

תוצר עבודה מתאים הוא מפת אחריות המפרידה בין העסק, צוות Salesforce, ספקים ומערכות חיצוניות. הוא צריך להיות קצר מספיק לשימוש ושיטתי מספיק לביקורת: מטרה, Owner, הנחות, חלופות, החלטה, קריטריון קבלה ותאריך לבחינה מחדש. אם אין קריטריון קבלה או Decision Record עבור מטרות ותהליכי ליבה, הנושא עדיין אינו בשל לפיתוח או להתחייבות מסחרית.

כדי לתרגם את העיקרון הזה לתוכנית עבודה סביב Sales Cloud לעומת Service Cloud, כדאי לקרוא גם הטמעת Service Cloud.

אובייקטים וממשקי עבודה

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

מבחינה ארכיטקטונית ותפעולית, יש לבחון את אובייקטים וממשקי עבודה דרך נפח, Latency, יכולת בדיקה ויכולת חזרה לאחור. בדיקה מקצועית כוללת לא רק את ה-Happy Path אלא גם נתון חסר, משתמש ללא הרשאה, עומס, שינוי דרישה וכשל של מערכת תלויה. העיקרון המנחה כאן הוא דוחות המבוססים על הגדרות KPI אחידות ולא רק על יכולות Dashboard.

תוצר עבודה מתאים הוא Decision Log קצר שמציג את החלופות, ההנחות והסיבה לבחירה. הוא צריך להיות קצר מספיק לשימוש ושיטתי מספיק לביקורת: מטרה, Owner, הנחות, חלופות, החלטה, קריטריון קבלה ותאריך לבחינה מחדש. אם אין קריטריון קבלה או Decision Record עבור אובייקטים וממשקי עבודה, הנושא עדיין אינו בשל לפיתוח או להתחייבות מסחרית.

אוטומציות ומדדים

כדי לנהל נכון את אוטומציות ומדדים, צריך להפריד בין צורך, אילוץ ופתרון. במקרה של Sales Cloud לעומת Service Cloud, המשמעות היא אוטומציה שמפחיתה עבודה ידנית אך שומרת על חריגים ושיקול דעת אנושי. צריך לכתוב מי מקבל את ההחלטה, מהו הגבול ואיזו ראיה נדרשת לפני שמתקדמים. הפער בדרך כלל אינו מופיע ב-Demo הראשון; הוא מופיע בחריג, בעומס או בשינוי הבא.

מבחינה ארכיטקטונית ותפעולית, יש לבחון את אוטומציות ומדדים דרך Source of Truth, תלויות, חריגים ויכולת תחזוקה. בדיקה מקצועית כוללת לא רק את ה-Happy Path אלא גם נתון חסר, משתמש ללא הרשאה, עומס, שינוי דרישה וכשל של מערכת תלויה. העיקרון המנחה כאן הוא שילוב Sales, Service, ערוצים ומערכות תפעוליות בהתאם למסע הלקוח.

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

הנושא מתחבר ישירות לעבודה על Sales Cloud לעומת Service Cloud שמתוארת בSalesforce Forecast, שם מוצג הפירוט המלא.

מתי צריך את שניהם

ב-מתי צריך את שניהם חשוב לאשר את ההיגיון לפני שמאשרים את המימוש. במקרה של Sales Cloud לעומת Service Cloud, המשמעות היא דוחות המבוססים על הגדרות KPI אחידות ולא רק על יכולות Dashboard. צריך לכתוב מי מקבל את ההחלטה, מהו הגבול ואיזו ראיה נדרשת לפני שמתקדמים. העלות האמיתית של החלטה עמומה מתגלה לאחר שהפתרון כבר תלוי במערכות ובצוותים נוספים.

מבחינה ארכיטקטונית ותפעולית, יש לבחון את מתי צריך את שניהם דרך Auditability, Least Privilege, ניטור ותהליך שינוי. בדיקה מקצועית כוללת לא רק את ה-Happy Path אלא גם נתון חסר, משתמש ללא הרשאה, עומס, שינוי דרישה וכשל של מערכת תלויה. העיקרון המנחה כאן הוא הגדרת תהליך מכירה או שירות מקצה לקצה לפני התאמת מסכים ואובייקטים.

תוצר עבודה מתאים הוא תרחיש End-to-End שמתחיל באירוע עסקי ומסתיים בתוצאה נמדדת. הוא צריך להיות קצר מספיק לשימוש ושיטתי מספיק לביקורת: מטרה, Owner, הנחות, חלופות, החלטה, קריטריון קבלה ותאריך לבחינה מחדש. אם אין קריטריון קבלה או Decision Record עבור מתי צריך את שניהם, הנושא עדיין אינו בשל לפיתוח או להתחייבות מסחרית.

תהליך עבודה מומלץ

1. מפו מסע לקוח ותהליך ליבה

יש לנסח את התוצאה במונחי תהליך או סיכון: זמן מחזור, שיעור השלמה, איכות, קיבולת או חשיפה. יעד כמו 'להטמיע Salesforce' אינו מדד משום שהוא מתאר אמצעי ולא תוצאה. בהקשר של Sales Cloud לעומת Service Cloud, השלב קשור במיוחד ל-מטרות ותהליכי ליבה. העיקרון המקצועי הוא תמונת לקוח אחת הנשענת על בעלות ואיכות נתונים, לא על ריבוי שדות. התוצר צריך לציין קלט, Owner, החלטה, קריטריון קבלה ותלות; רק כך ניתן לדעת שהצוות התקדם ולא רק השקיע זמן.

2. הגדירו שלבים, סטטוסים, בעלות ו-SLA

האיסוף צריך להתבסס על ראיונות, צפייה בעבודה ונתונים קיימים. מסמך הנהלה לבדו כמעט תמיד מחמיץ חריגים, Shadow Systems ועבודה ידנית שמבצעים המשתמשים. בהקשר של Sales Cloud לעומת Service Cloud, השלב קשור במיוחד ל-אובייקטים וממשקי עבודה. העיקרון המקצועי הוא אוטומציה שמפחיתה עבודה ידנית אך שומרת על חריגים ושיקול דעת אנושי. התוצר צריך לציין קלט, Owner, החלטה, קריטריון קבלה ותלות; רק כך ניתן לדעת שהצוות התקדם ולא רק השקיע זמן.

3. תכננו מודל נתונים ומסכי עבודה

ב-To-Be יש להסיר שלבים שאינם יוצרים ערך לפני שמבצעים להם אוטומציה. כל דרישה מסווגת כ-Must, Should או Later ומקבלת Owner ותלות. בהקשר של Sales Cloud לעומת Service Cloud, השלב קשור במיוחד ל-אוטומציות ומדדים. העיקרון המקצועי הוא דוחות המבוססים על הגדרות KPI אחידות ולא רק על יכולות Dashboard. התוצר צריך לציין קלט, Owner, החלטה, קריטריון קבלה ותלות; רק כך ניתן לדעת שהצוות התקדם ולא רק השקיע זמן.

4. הוסיפו Routing, אוטומציה וחריגים

הארכיטקטורה צריכה להיות מתועדת בהחלטות קצרות: מודל נתונים, גישה, Automation, Integration, Failure handling ויכולת תחזוקה. לכל החלטה מציינים חלופה שנפסלה והסיבה. בהקשר של Sales Cloud לעומת Service Cloud, השלב קשור במיוחד ל-מתי צריך את שניהם. העיקרון המקצועי הוא שילוב Sales, Service, ערוצים ומערכות תפעוליות בהתאם למסע הלקוח. התוצר צריך לציין קלט, Owner, החלטה, קריטריון קבלה ותלות; רק כך ניתן לדעת שהצוות התקדם ולא רק השקיע זמן.

5. בנו דוחות לפי החלטות ניהוליות

בנייה במחזורים קצרים אינה פוטרת מתכנון. כל מחזור צריך להציג Vertical Slice עובד, עם נתונים והרשאות מייצגים, ולא אוסף מסכים שאינם משלימים תהליך. בהקשר של Sales Cloud לעומת Service Cloud, השלב קשור במיוחד ל-מטרות ותהליכי ליבה. העיקרון המקצועי הוא הגדרת תהליך מכירה או שירות מקצה לקצה לפני התאמת מסכים ואובייקטים. התוצר צריך לציין קלט, Owner, החלטה, קריטריון קבלה ותלות; רק כך ניתן לדעת שהצוות התקדם ולא רק השקיע זמן.

6. בדקו עם משתמשים ונציגים אמיתיים

לפני Go Live מריצים תרחישים מלאים, עומסים רלוונטיים ו-Rehearsal. תקלות מסווגות לפי השפעה עסקית, ובעלי התהליך חותמים על קריטריוני הקבלה. בהקשר של Sales Cloud לעומת Service Cloud, השלב קשור במיוחד ל-אובייקטים וממשקי עבודה. העיקרון המקצועי הוא תמונת לקוח אחת הנשענת על בעלות ואיכות נתונים, לא על ריבוי שדות. התוצר צריך לציין קלט, Owner, החלטה, קריטריון קבלה ותלות; רק כך ניתן לדעת שהצוות התקדם ולא רק השקיע זמן.

7. מדדו אימוץ ותוצאה לאחר ההשקה

לאחר ההשקה מודדים שימוש, איכות ותוצאה מול Baseline. פריטים שלא עמדו ביעד נכנסים ל-Improvement Backlog עם Owner, עדיפות ותאריך בדיקה. בהקשר של Sales Cloud לעומת Service Cloud, השלב קשור במיוחד ל-אוטומציות ומדדים. העיקרון המקצועי הוא אוטומציה שמפחיתה עבודה ידנית אך שומרת על חריגים ושיקול דעת אנושי. התוצר צריך לציין קלט, Owner, החלטה, קריטריון קבלה ותלות; רק כך ניתן לדעת שהצוות התקדם ולא רק השקיע זמן.

תרחיש ארגוני לדוגמה

נניח מוסד אקדמי שבוחנת Sales Cloud לעומת Service Cloud. הארגון מפעיל כמה צוותים, חלק מהמידע נמצא ב-Salesforce וחלקו במערכות נוספות, והנהלה רוצה להתקדם מהר. בתרחיש כזה, התחלה מפיתוח הייתה מסתירה את המחלוקת לגבי מטרות ותהליכי ליבה. הצוות בוחר תחילה תהליך אחד, מגדיר Owner, נתוני קלט ותוצאה רצויה, ורושם אילו מקרים יישארו מחוץ לגרסה הראשונה.

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

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

ארגונים שנתקלים כאן בקושי חוזר בתוך Sales Cloud לעומת Service Cloud מוצאים מענה נוסף בSalesforce Knowledge.

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

סיכוןכיצד הוא נראה בפועלפעולת מניעה
תהליך לא מוסכםהמערכת מקבעת מחלוקת בין צוותיםלאשר שלבים, בעלות וקריטריוני מעבר
שדות ללא שימושהמסך מתארך והאימוץ יורדלכל שדה Owner, שימוש ודוח
Routing לא מדויקפניות או לידים מגיעים לצוות הלא נכוןכללי קיבולת, Skill וחריגים
Forecast לא אמיןהנהלה מפסיקה להשתמש בנתוני CRMהגדרות Stage, Hygiene וקצב Review
Knowledge ללא Governanceנציגים וסוכנים מקבלים תשובות סותרותתהליך כתיבה, אישור ו-Retirement

ברמת הניהול של Sales Cloud לעומת Service Cloud, הטבלה הזו היא נקודת פתיחה ולא Risk Register מלא. עבור מנהלים הבוחנים Salesforce כדאי לתחזק רישום סיכונים ייעודי לאשכול Sales Cloud ו-Service Cloud, שבו לכל סיכון יש Owner, הסתברות, השפעה, פעולת מניעה ו-Trigger שמפעיל תוכנית תגובה לפני שהסיכון הופך לתקלה בייצור.

כיצד מודדים הצלחה

תחוםמה מודדיםקצב בדיקה
מכירותConversion, Velocity, Coverage ו-Forecast accuracyשבועי וחודשי
שירותFRT, Resolution, SLA, Reopen ו-Escalationיומי ושבועי
פרודוקטיביותזמן עבודה ידנית ופעולות למשתמשחודשי
איכותשלמות נתונים ושימוש נכון בשלבים או בסטטוסיםשבועי

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

כאשר חסרה קיבולת פנימית לSales Cloud לעומת Service Cloud, שירות הטמעת Salesforce הוא המסלול המעשי להמשך.

Checklist לפני קבלת החלטה

  • ☐ הבעיה העסקית וה-Outcome מוגדרים במשפט אחד
  • ☐ קיים Sponsor ובעל תהליך עם סמכות החלטה
  • ☐ ה-Scope וה-Out of Scope כתובים
  • ☐ מקורות המידע וה-Source of Truth ידועים
  • ☐ מודל הרשאות ורגישות מידע נבדקו
  • ☐ תרחישי חריג וכשל כלולים בתכנון
  • ☐ קיימים קריטריוני קבלה שניתן לבדוק
  • ☐ תלויות, הנחות וסיכונים מתועדים
  • ☐ הוגדרו מדדי הצלחה ו-Baseline
  • ☐ קיימת תוכנית תפעול, תמיכה ושינוי לאחר ההשקה

מקורות מקצועיים