מרכז הידע של HPI Pro
מדריכים מעשיים לתכנון, הטמעה, שיפור וניהול מערכות Salesforce ו-CRM בארגונים.
אשכולות תוכן
מאמרים
80 מאמרים מתוך 80
בחירת חברה, עלויות ומכרזים
עלות הטמעת Salesforce בנויה משבעה מרכיבים שונים לגמרי בהתנהגות שלהם - מרישוי דרך אינטגרציות ועד עלות פנימית נסתרת. מי שמאשר תקציב לפי מספר אחד בלבד לרוב מגלה חריגה בסבב השני.
בחירת חברה, עלויות ומכרזים
בחירת חברת הטמעת Salesforce נופלת בדרך כלל בין שני קטבים: התרשמות מדמו מרשים או השוואת מחיר גרידא. תהליך בחירה נכון בודק עומק מקצועי, ממליצים אמיתיים ומודל התקשרות - לפני שמסתכלים על המספר בתחתית ההצעה.
הטמעה ויישום Salesforce
פרויקט Salesforce ממוצע נמשך בין שישה שבועות לתשעה חודשים, אבל טווח התאריכים בהצעת המחיר כמעט אף פעם לא נובע מהיקף הפיתוח - הוא נובע מקצב ההחלטות, מוכנות הנתונים ומזמינות אנשי המקצוע בארגון.
הטמעה ויישום Salesforce
מעל 500 משתמשים, הבעיה כבר אינה 'איך בונים', אלא מי מחליט, מי מאשר שינוי ואיך מתואמות תוכניות מקבילות. המאמר מציג מודל Governance, בחירת Single-org מול Multi-org ותבניות כשל אופייניות.
הטמעה ויישום Salesforce
מעבר בין מערכות CRM נכשל לרוב לא בגלל Salesforce אלא בגלל נתונים היסטוריים שהוחלט להעביר בלי בדיקה. המאמר מפרט איך למפות תהליך קיים, לבחור מה משאירים מאחור ומתי לנתק את המערכת הישנה בבטחה.
ארכיטקטורה ואינטגרציות
בכל חיבור בין Salesforce ל-ERP יש רגע שבו שני מספרים סותרים - מלאי, יתרת חוב או סטטוס הזמנה - ומישהו צריך להכריע איזה מהם נכון. המדריך בונה את ההחלטה סביב מקור אמת, דפוס סנכרון ותכנון כשלים, ולא סביב רשימת חיבורי API.
Data, Migration ואיכות מידע
רוב תקלות המיגרציה לא נובעות מהכלי אלא מסדר טעינה שגוי, מיפוי שדות שנעשה בחיפזון והיעדר Reconciliation. המדריך בונה תהליך מלא: פרופיילינג, ניקוי, External IDs, Dry Run ותיקונים אחרי Go Live.
Agentforce ו-AI
לא כל תהליך ראוי לסוכן AI עצמאי. המדריך בונה מסגרת החלטה תפעולית - בשלות דאטה, Grounding, הרשאות ו-Human-in-the-loop - שמבחינה בין Use Case שבשל ל-Agentforce לבין כזה שעדיף להשאיר לאוטומציה קלאסית.
בחירת חברה, עלויות ומכרזים
רוב ההצעות ל-Salesforce נראות דומות על הנייר עד שבודקים אותן בעזרת 15 שאלות ממוקדות. המדריך מפרק אותן לשישה נושאים - מצוות ועד המשכיות - ומראה איך נשמעת תשובה חלשה מול תשובה שאפשר לסמוך עליה.
שיפור וחילוץ פרויקטים
פרויקט Salesforce תקוע נראה כמו בעיית פיתוח, אבל ברוב המקרים מדובר בערבוב של Scope לא ברור, החלטות ארכיטקטורה שלא נלקחו ואמון שהתפוגג. המדריך מציג תוכנית אבחון של 10 ימים ותוכנית חילוץ ל-90 יום.
הטמעה ויישום Salesforce
ההבדל בין MVP לבין מערכת חצי בנויה אינו בכמות הפיצ'רים אלא בשאלה אילו החלטות נסגרו. גל ראשון נכון סוגר את מודל הנתונים וההרשאות במלואם ומצמצם דווקא את הרוחב העסקי. המאמר מציג מבחן חד לגבולות MVP וטבלת החלטות שמותר ואסור לדחות.
הטמעה ויישום Salesforce
שני התפקידים שקובעים אם פרויקט Salesforce יעמוד בזמנים כמעט תמיד יושבים בצד הלקוח ולא בצד הספק. כאן מוגדרים תשעת התפקידים הנדרשים, מה כל אחד מכריע, אילו מהם אי אפשר לקנות מבחוץ, וכיצד נראית טבלת RACI שמונעת המתנה להחלטות.
הטמעה ויישום Salesforce
UAT שנראה כמו סיור מודרך במסכים לא ימצא את התקלות שיפילו את העלייה לאוויר. הבדיקה צריכה לרוץ על תרחישים שלמים, על נתונים שדומים לאמת ובידי מי שיעבוד במערכת. המדריך מציג שיטת בנייה לתסריטים, מודל חומרה לתקלות ותנאי מעבר ברורים.
בחירת חברה, עלויות ומכרזים
בחירת מודל התמחור היא בעיקר החלטה על מי נושא בסיכון של אי-ודאות. Fixed Price אינו זול יותר ו-T&M אינו מסוכן יותר — כל אחד מתאים לרמת בשלות אחרת של הגדרת ה-Scope. כאן מפת התאמה, מנגנוני הגנה לכל מודל ומודלים היברידיים שעובדים.
ארכיטקטורה ואינטגרציות
הבחירה בין Flow ל-Apex לא נופלת לפי מיומנות הצוות אלא לפי אופי הלוגיקה: כמות רשומות בטרנזקציה, תלות ב-Governor Limits, צורך ב-Transaction Control ומורכבות תנאים. המאמר מציג מבחן החלטה תפעולי ולא עוד השוואת יכולות כללית.
ארכיטקטורה ואינטגרציות
בחירת דפוס אינטגרציה שגויה לא מתגלה בדמו - היא מתגלה כשעומס גדל, כשמערכת חיצונית נופלת לדקה, או כששני משתמשים מעדכנים אותו לקוח בו-זמנית. המדריך מציג מסגרת החלטה לפי שלוש שאלות בלבד: כמה מהר צריך לדעת, מי הבעלים של האמת, ומה קורה כשמשהו נכשל.
ארכיטקטורה ואינטגרציות
רוב הארגונים בונים מודל הרשאות מלמעלה למטה - קודם Profile רחב, ואז תיקונים פרטניים עד שאיש לא זוכר למה למשתמש יש גישה מסוימת. הדרך הנכונה הפוכה: Profile מצומצם לגישת בסיס, ו-Permission Set Groups שמרכיבים את יכולת העבודה לפי תפקיד. המאמר מציג זאת כמסגרת עבודה תפעולית.
ארכיטקטורה ואינטגרציות
Multi-Org לא נולד מהחלטה אחת אלא מהצטברות של יחידות עסקיות, רגולציה ומודלי נתונים שלא מסתדרים באותו מרחב. המאמר מציג מבחן שלוש שאלות לבדיקת הצורך האמיתי, מטריצת השוואה עלות-תועלת, ומסלול מדורג למי שכבר בדרך לפיצול.
Data, Migration ואיכות מידע
רוב כשלי ההסבה ל-Salesforce אינם כשלי כלי אלא כשלי משמעות: שדה שנקרא אותו דבר בשתי מערכות ומתאר שני דברים שונים. המדריך מראה איך בונים מסמך Mapping שמתעד משמעות עסקית, כללי Transformation, ערכי ברירת מחדל ואחריות - לפני שמריצים טעינה ראשונה.
Data, Migration ואיכות מידע
כפילות אינה תקלת נתונים אלא תקלת זהות: הארגון לא הכריע מה הופך שתי רשומות לאותו לקוח. המדריך מציג איך קובעים כללי Matching, בונים Golden Record, מחליטים מה נמחק ומה נשמר בהיסטוריה, ואיך מונעים שהכפילויות יחזרו שבועיים אחרי הטעינה.
Data, Migration ואיכות מידע
כשאין הכרעה מי מוסמך לשנות נתון, כל אינטגרציה הופכת למשא ומתן ובסוף שתי מערכות דורסות זו את זו. המדריך מציג איך מחליטים מקור אמת לכל ישות ברמת השדה, איך מבדילים בין מערכת שמציגה למערכת שמוסמכת, ואיך אוכפים את ההחלטה בקוד ולא במסמך.
Data, Migration ואיכות מידע
איכות נתונים הופכת לניתנת לניהול רק כשיש לה מספר, סף ובעלים. המדריך מסביר אילו ממדים באמת שווה למדוד ב-Salesforce, איך קובעים סף שאינו שרירותי, איך מחברים כל מדד להשלכה עסקית, ואיך בונים Scorecard שמישהו מסתכל עליו יותר מפעם אחת.
Agentforce ו-AI
לא כל פנייה מתאימה לסוכן, וסדר ההתחלה קובע אם הפרויקט יתרחב או ייעצר. המדריך מדרג תרחישי שירות נפוצים לפי בשלות, מסביר מה נדרש לכל אחד, ומראה אילו תרחישים נראים מפתים ובפועל שורפים את האמון בשלב מוקדם.
Agentforce ו-AI
סוכן לא ממציא תשובות מרוע לב - הוא ממציא כשמקור המידע חלקי, סותר או לא מורשה. המדריך מפרק את שכבת ה-Grounding לרכיביה: אילו מקורות מחברים, איך חותכים ומתייגים תוכן, איך ההרשאות נשמרות באחזור, ואיך מודדים דיוק לפני שנותנים לסוכן לדבר עם לקוח.
Agentforce ו-AI
אישור אנושי על כל פעולה הורג את הערך; אישור על אף פעולה מייצר סיכון. המדריך מציג שיטה לקביעת נקודות עצירה לפי הפיכות, השפעה ורגישות, שלושה דפוסי אישור שונים, ותנאים מדידים להסרת נקודת אישור בלי לוותר על בקרה.
Sales Cloud ו-Service Cloud
הטמעת Sales Cloud נכשלת בדרך כלל לא בגלל הגדרות שגויות אלא בגלל שלבי מכירה שאיש לא יודע להגדיר מתי בדיוק עוברים ביניהם. המדריך מראה איך בונים שרשרת אחת - Lead, Opportunity, Forecast - שבה לכל שלב יש קריטריון יציאה מדיד, ולמה זה התנאי לתחזית שאפשר לסמוך עליה.
Sales Cloud ו-Service Cloud
מוקדי שירות רבים מטמיעים Service Cloud ומגלים שזמן התגובה לא השתפר. הסיבה כמעט תמיד אינה הכלי אלא ארבע הכרעות שלא נסגרו: מה נחשב Case, מי מקבל אותו, ממתי נספר הזמן ומה קורה כשהתשובה כבר קיימת. המדריך מפרק את ארבעתן לתוצרים ניתנים לבדיקה.
Sales Cloud ו-Service Cloud
השאלה איזה Cloud לקנות מוצגת כהשוואת מוצרים, אבל היא בעצם שאלה על מבנה העבודה: האם היחידה שמנהלים היא עסקה עם התקדמות, או פנייה עם זמן תגובה. המדריך מפריד בין השניים לפי אובייקטים, מדדים ורישוי, ומראה מתי צריך את שניהם ואיך מחברים ביניהם בלי לשכפל נתונים.
אימוץ משתמשים וניהול שינוי
ניהול שינוי אינו שבוע ההדרכה שלפני העלייה לאוויר. תוכנית עבודה בארבעה שלבים — מיפוי השפעה, גיוס בעלי עניין, תקשורת ומחזור ניהולי — עם תוצרים, אחראים ומדדים לכל שלב.
אימוץ משתמשים וניהול שינוי
הדרכה שמסבירה מסכים נשכחת תוך שבוע. מבנה תוכנית הדרכה מבוססת תרחישים: מסלול נפרד לכל תפקיד, תרגול על נתוני אמת בסנדבוקס, מבחן עצמאות ותחזוקה מתמשכת למצטרפים חדשים.
אימוץ משתמשים וניהול שינוי
Login הוא מדד נוכחות, לא מדד ערך. מדריך מעשי לבניית סט מדדי אימוץ שמודד פעולות ליבה, איכות נתונים ותוצאה עסקית — כולל Baseline, פילוח לפי תפקיד ותוכנית פעולה לכל ממצא.
שיפור וחילוץ פרויקטים
מערכת CRM כמעט אף פעם לא מתקלקלת בבת אחת. היא נשחקת - ומי שעובד בה מדי יום מפסיק לשים לב. שמונת הסימנים כאן ניתנים למדידה בלי סקר ובלי יועץ, וכל אחד מהם מצביע על שורש אחר: תהליך, נתונים, ארכיטקטורה או ממשל.
הטמעה ויישום Salesforce
מסלול השינוי מהפיתוח ועד Production הוא מה שקובע אם אפשר לשחרר בביטחון. המדריך מפרט אילו סוגי Sandbox נדרשים בכל שלב, איך בונים מסלול Source-Driven עם Git ו-CI, ומה עושים עם Config שנעשה ידנית ב-Production.
הטמעה ויישום Salesforce
Hypercare אינו הארכה של הפרויקט אלא גשר מתוכנן ל-BAU. מבנה תקופת ייצוב: הרכב צוות, SLA זמני, טריאז' יומי, קריטריוני יציאה מדידים והעברת בעלות מסודרת לצוות הפנימי.
הטמעה ויישום Salesforce
Backlog של פרויקט Salesforce נכשל כמעט תמיד באותה נקודה: סיפורים שמתארים מסך במקום תוצאה, וקריטריוני קבלה שנכתבים אחרי הפיתוח. המדריך מציג מבנה סיפור שניתן לבדיקה, שיטת פירוק לפי Vertical Slice, ותעדוף שמחזיק גם כשהלחץ עולה.
הטמעה ויישום Salesforce
Scope Creep אינו נובע מבקשות רבות מדי אלא מהיעדר מנגנון שמתמחר אותן בזמן אמת. המדריך מציג Baseline מוקפא, טופס Change Request קצר, מועצת שינויים שמתכנסת שבועית ותקציב שינוי מוקצה מראש — כך שאפשר לומר 'כן' בלי לאבד תאריך.
הטמעה ויישום Salesforce
הוויכוח על מתודולוגיה בפרויקט Salesforce הוא כמעט תמיד ויכוח על משהו אחר: כמה החלטות אפשר לדחות, וכמה זמן משתמשים באמת פנויים. המדריך מפרק את הבחירה לשלושה משתנים מכריעים ומתאר את המודל ההיברידי שרוב הארגונים מגיעים אליו בפועל.
הטמעה ויישום Salesforce
ההחלטה נקבעת על ידי תלות נתונים ותהליכים, לא על ידי העדפה מתודולוגית. מסגרת בחירה בין השקה חד-פעמית להשקה בגלים — כולל עלות Coexistence, סיכוני מיגרציה וטבלת החלטה לפי סוג ארגון.
הטמעה ויישום Salesforce
רוב חישובי ה-ROI לפרויקט CRM נכתבים פעם אחת, בשקף אישור התקציב, ואיש אינו חוזר אליהם. המדריך מציג מבנה שונה: ארבעה סוגי ערך שנמדדים אחרת, Baseline שנקבע לפני העלייה לאוויר, וכלל ייחוס שמונע ייחוס של כל שיפור עסקי למערכת.
בחירת חברה, עלויות ומכרזים
RFP שמפרט רשימת דרישות מקבל בחזרה רשימת הבטחות. מסמך פנייה טוב מתאר במקום זאת תהליכים, נפחים והחלטות פתוחות — ומכריח כל ספק להראות איך הוא חושב. כאן מבנה מסמך בן תשעה חלקים, השאלות שמפרידות בין ספקים ומה לדרוש כתוצר בהצעה.
בחירת חברה, עלויות ומכרזים
הצעה זולה ב-30% היא כמעט תמיד הצעה אחרת, לא הצעה טובה יותר. השוואה נכונה מתחילה בנרמול: אותו היקף, אותה תקופת אחריות, אותם רכיבים סמויים. כאן שיטת נרמול בשישה צעדים, מפת עלויות שנעלמות מההצעה ומודל השוואה לעלות תלת-שנתית.
בחירת חברה, עלויות ומכרזים
רוב הסכסוכים בפרויקטי Salesforce אינם על מחיר אלא על השאלה מה נחשב שהושלם. SOW טוב מגדיר קבלה, תלות דו-כיוונית, בעלות על תוצרים ויציאה מסודרת. כאן שנים עשר סעיפים עם ניסוח מומלץ והסבר מה כל אחד מונע בפועל.
בחירת חברה, עלויות ומכרזים
ועדת בחירה בלי מודל ניקוד מוסכם מגיעה כמעט תמיד להחלטה שמנומקת בדיעבד. Scorecard מוגדר מראש קובע במה מודדים, איזו ראיה נדרשת לכל ציון ומה פוסל מיידית. כאן מודל בן שבעה ממדים עם משקולות לדוגמה ותהליך ניקוד שמונע הטיה.
ארכיטקטורה ואינטגרציות
Salesforce סופרת קריאות API בחלונות של 24 שעות, ומעל הסף היא פשוט חוסמת - לא מאטה. ארגון שמריץ סנכרון לילי, Webhook נכנס וריפורטינג במקביל צריך תקציב קריאות מתוכנן, לא רק Retry אחרי שהמכסה נגמרת. המדריך מפרק את הגבולות בפועל: איך למדוד צריכה, מתי לעבור ל-Bulk API, ואיך בונים Backoff שלא מציף את המערכת בגל שני של כשלים.
ארכיטקטורה ואינטגרציות
Platform Events ו-CDC פותרים בעיה אחת בלבד: ניתוק בין מערכות שלא צריכות לחכות זו לזו. הבעיה מתחילה כשבוחרים ביניהם לפי נוחות טכנית ולא לפי מי הבעלים של הנתון, מה סדר האמינות הנדרש, ומה קורה כשהודעה מגיעה פעמיים או לא מגיעה בכלל.
ארכיטקטורה ואינטגרציות
SAML או OIDC, IdP-initiated או SP-initiated, JIT או SCIM לניהול מחזור חיים - כל בחירה ב-Identity architecture ל-Salesforce קובעת מי נכנס למערכת, באילו הרשאות ומה קורה ביום שהוא עוזב. המאמר פורש מסגרת החלטה קונקרטית, כולל תרחיש Offboarding שנכשל ומה מתקן אותו.
ארכיטקטורה ואינטגרציות
OWD פתוח שנפתח 'כדי לא לחסום אף אחד' וRole Hierarchy שגדל אד-הוק הם הדרך הכי מהירה לדוח שהמנהל האזורי רואה בו את כל הלקוחות של המתחרה הפנימי שלו. המאמר בונה סדר עבודה הפוך: קודם ממפים מי חייב לראות מה ולמה, ורק אז בוחרים בין OWD, Role Hierarchy, Sharing Rules, Teams ו-Apex Sharing.
ארכיטקטורה ואינטגרציות
רוב תקלות האינטגרציה שמגיעות ללקוחות אינן נגרמות מ-API שנפל, אלא מהודעה שנכשלה בשקט ואף אחד לא ידע לחפש אותה. המאמר מפרק את שרשרת הטיפול בשגיאות לארבע שכבות - Idempotency, Retry, Dead Letter ו-Reconciliation - ומראה איפה כל אחת מהן נשברת בפועל.
ארכיטקטורה ואינטגרציות
חוב טכני באוטומציות Salesforce לא נולד מבחירה שגויה בין Flow ל-Apex, אלא ממאות בחירות קטנות שנעשו בלי מדיניות ובלי ראייה מצטברת. המאמר מציג איך לזהות את זה בפועל — דרך מספרים, לא תחושת בטן — ואיך בונים תוכנית צמצום שלא עוצרת את קצב הפיתוח.
Data, Migration ואיכות מידע
מודל הנתונים הוא ההחלטה הכי יקרה לשינוי אחרי Go Live. המדריך עובר על מתי להישאר ב-Standard Objects, מתי Custom Object מוצדק, איך בוחרים בין Lookup ל-Master-Detail, ואיך מודל שנראה נקי בסדנה מייצר מגבלות דיווח, הרשאות וביצועים שנתיים אחר כך.
Data, Migration ואיכות מידע
MDM נכשל כשהוא מוגדר כפרויקט טכנולוגי ומצליח כשהוא מוגדר כמשטר בעלות. המדריך מסביר אילו ישויות באמת דורשות ניהול Master, איך בונים Golden Record בין CRM ל-ERP בלי לשבור אף מערכת, מתי נדרש כלי MDM ייעודי ומתי Salesforce מספיק, ואיך מודדים אם המשטר עובד.
Data, Migration ואיכות מידע
לא כל נתון שקשור ללקוח צריך לשבת ב-CRM. המדריך מפריד בין נתון תפעולי שמניע תהליך יומיומי לבין נתון התנהגותי בנפח גבוה שנועד לאיחוד פרופיל, פילוח והפעלה, ומראה איך ההחלטה הזו משפיעה על ביצועים, עלות, הרשאות ועל מה שאפשר יהיה לעשות עם AI.
Data, Migration ואיכות מידע
כל העתקה של נתון היא התחייבות: צינור, עלות, פער וסיכון. Zero Copy מאפשר לשאול נתון במקום שבו הוא יושב, אבל הוא אינו פתרון לכל מקרה. המדריך מציג מתי גישה וירטואלית עדיפה, מתי דווקא Ingestion נכון יותר, ואיך מחליטים לפי Freshness, ביצועים, ממשל ועלות תנועה.
Data, Migration ואיכות מידע
יום המעבר נכשל בדרך כלל לא בגלל הטעינה אלא בגלל מה שקרה סביבה: Delta שלא נקלט, אינטגרציה שהתעוררה מוקדם, או החלטה שלא היה מי שיקבל בשתיים בלילה. המדריך מציג תוכנית Cutover ברמת שעה, כללי Freeze, שיטת Reconciliation בארבע רמות וקריטריוני Go/No-Go ברורים.
Agentforce ו-AI
עלות הרישוי היא החלק הקל לחשב ולרוב לא החלק הגדול. המדריך מפרק את ה-TCO האמיתי לחמישה רכיבים - רישוי, צריכה, בנייה, תפעול ותחזוקת תוכן - ומציג נוסחת עלות למשימה שמאפשרת להשוות את הסוכן לעלות הטיפול האנושי במקום להסתמך על הבטחות.
Agentforce ו-AI
הפלטפורמה מאבטחת את התשתית; הארגון אחראי למה שהסוכן רשאי לראות ולעשות. המדריך משרטט את קו הגבול בפועל - נתונים, הרשאות, הוראות, פעולות וניטור - ומראה אילו סיכונים חדשים נכנסים עם סוכן שאין להם מקבילה במערכת CRM רגילה.
Agentforce ו-AI
אי אפשר לבדוק סוכן כמו שבודקים Flow: אותה שאלה יכולה לקבל שתי תשובות תקינות. המדריך מציג איך בונים סט בדיקה שמייצג את המציאות, אילו ממדים מודדים בנפרד, מתי אוטומציה מספיקה ומתי נדרש שיפוט אנושי, ואיזה סף מאפשר לעלות לאוויר.
Agentforce ו-AI
סוכן בלי ניטור הוא קופסה שחורה שאיש לא יודע להגן עליה בדיון הנהלה. המדריך מפרק את שכבת הניטור לשלוש רמות - שיחה בודדת, מגמה ותוצאה עסקית - מסביר מה חייב להופיע ב-Trace, ואיך הופכים שיחות שנכשלו לתור עבודה שבועי במקום לדוח שאיש לא קורא.
Agentforce ו-AI
לכל פעולה שסוכן מבצע יש ארבע דרכי מימוש, וההבדל ביניהן אינו טכני בלבד: הוא נוגע למי יתחזק, איך בודקים, וכמה זמן ייקח לשנות. המדריך מציג סדר בחירה ברור, את מחיר התחזוקה של כל אפשרות, ואת המקרים שבהם Apex הוא הבחירה הנכונה למרות העלות.
Agentforce ו-AI
מאגר ידע שנבנה לבני אדם אינו מוכן לסוכן: הוא מכיל גרסאות סותרות, מסמכים בלי בעלים ותוכן פנימי שמעורבב בתוכן ללקוח. המדריך מציג תהליך הכשרה בן חמישה שלבים - ביקורת, ארכוב, מבנה, תיוג ובעלות - עם ספי כניסה לאינדקס ומודל תחזוקה שמחזיק לאורך זמן.
Agentforce ו-AI
ממשל AI נכשל בשני קצוות: ועדה שחוסמת כל יוזמה, או היעדר בקרה שמתגלה בביקורת. המדריך מציג מודל מדורג לפי סיכון - מי מאשר מה, אילו בקרות חובה בכל דרג, אילו מסמכים נדרשים באמת, ואיך שומרים על מהירות בלי לוותר על אחריות.
Sales Cloud ו-Service Cloud
Lead-to-Cash נשבר כמעט תמיד באותן שלוש נקודות מעבר: מהפנייה לעסקה, מהעסקה להצעת מחיר מאושרת, ומההצעה להזמנה ב-ERP. המדריך מתאר מה חייב להיות מוגדר בכל אחת מהן, איך מחליטים היכן חי התמחור, ולמה אישור הנחות הוא לרוב צוואר הבקבוק האמיתי.
Sales Cloud ו-Service Cloud
כשמנהל מכירות מנהל תחזית בגיליון נפרד, הבעיה אינה בדשבורד. תחזית אמינה נשענת על ארבעה תנאים מוקדמים - היררכיה תקינה, תאריכי סגירה נקיים, קטגוריות מוסכמות ומחזור סקירה קבוע. המדריך מסביר איך בונים אותם, ומה למדוד כדי לדעת אם התחזית באמת השתפרה.
Sales Cloud ו-Service Cloud
Omni-Channel נכשל בדרך כלל לא בהגדרות הניתוב אלא במודל הקיבולת: כשצ'אט, מייל וטלפון נמדדים באותה יחידת משקל, הנציגים מוצפים או פנויים לסירוגין. המדריך מסביר איך קובעים משקלי עבודה, איך מחברים Entitlements ל-Routing, ואיך מזהים מבעוד מועד שהמודל לא מחזיק בעומס.
Sales Cloud ו-Service Cloud
מאגרי ידע נכשלים בדרך כלל בשנה השנייה, לא בהשקה: המאמרים נכתבו פעם אחת, איש לא תחזק אותם, והנציגים חזרו לשאול בצ'אט הפנימי. המדריך מתאר מחזור חיים שמחזיק לאורך זמן - בעלות, טריגר ליצירה, בחינה תקופתית ומדידת שימוש - ומה משתנה כשסוכן AI קורא מאותו מאגר.
Sales Cloud ו-Service Cloud
חיבור טלפוניה ל-Salesforce נמדד בשניות: כמה זמן עובר עד שהנציג רואה מי מתקשר ולמה. המדריך עוסק בהכרעות שקובעות את התוצאה - זיהוי מתקשר, Screen Pop, בעלות על ה-Routing, טיפול בהעברות ובניתוקים, ובחירה בין Service Cloud Voice לבין מתאם CTI קיים.
אימוץ משתמשים וניהול שינוי
Champion שהוא רק תואר סמלי לא משנה דבר. איך בוחרים נציגים בשטח, כמה זמן להקצות להם, מה בדיוק התפקיד כולל, איך מתגמלים ואיך מונעים שהרשת תתפוגג אחרי חודשיים.
אימוץ משתמשים וניהול שינוי
כל שדה מיותר הוא מס יומי על כל משתמש. שיטת עבודה מעשית לצמצום מסכים ב-Salesforce: ביקורת שימוש בשדות, מבחן שלוש הקליקים, Layout לפי תפקיד ומדידה של זמן משימה לפני ואחרי.
אימוץ משתמשים וניהול שינוי
השקה שנכשלה אינה בעיית הדרכה. מדריך שיקום מעשי: איך מאבחנים את סיבת הנטישה, מה מתקנים ב-30 הימים הראשונים, איך מחזירים אמון בלי הכרזה על 'השקה מחדש' — ומתי עדיף לצמצם את המערכת במקום להרחיב אותה.
שיפור וחילוץ פרויקטים
ההחלטה בין תיקון נקודתי, Refactor ובנייה מחדש מוכרעת לרוב לפי תחושה - וזו הסיבה שהיא חוזרת שוב אחרי שנתיים. המדריך מציג ארבעה מבחנים אובייקטיביים, מסביר מדוע Rebuild כמעט תמיד יקר מהאומדן, ומתאר את המסלול המעשי של החלפה הדרגתית.
שיפור וחילוץ פרויקטים
רשימת חוב טכני שאורכה מאה שורות אינה כלי עבודה אלא מקור לתסכול. המדריך מציג ניקוד בארבעה ממדים שמייצר סדר ברור, מסביר איזה סוג חוב חייב לעלות ראשון בלי קשר לניקוד, ואיך מתרגמים חוב לשפה שמקבלת תקציב.
שיפור וחילוץ פרויקטים
איטיות ב-Salesforce כמעט אף פעם אינה בעיה אחת גדולה, אלא הצטברות של מסך עמוס, שאילתה לא סלקטיבית ואוטומציה שרצה פעמיים. המדריך מציג שיטת אבחון לפי שכבות — דפדפן, מסך, שרת, נתונים, אינטגרציה — ומדדים שמאפשרים להוכיח שיפור.
הטמעה ויישום Salesforce
רוב הטמעות Salesforce לא נכשלות בפיתוח אלא בין השלבים: מעבר חפוז מ-Discovery לבנייה, מיגרציה בלי חזרה כללית ו-UAT שאין לו באמת בעלים. המדריך פורש את המסלול המלא לפי שלבים, תוצרים ואישורים.
ארכיטקטורה ואינטגרציות
ארגון שמוסיף עוד Custom Object, עוד Flow ועוד אינטגרציית Point-to-Point בלי שכבת ארכיטקטורה מתועדת - צובר חוב שמתגלה רק כשמנסים להוסיף עסק חדש או מדינה חדשה. המאמר מפרק את הארכיטקטורה לשש שכבות מעשיות.
הטמעה ויישום Salesforce
Discovery שנגמר במצגת מנוסחת יפה אינו Discovery. בסוף שלב האפיון צריכים לשבת על השולחן שבעה תוצרים שאפשר לבנות מהם, לתמחר לפיהם ולבדוק מולם. המדריך מפרט מה כל תוצר מכיל, איך יודעים שהוא בשל, וכמה זמן סביר להשקיע בו.
הטמעה ויישום Salesforce
רוב הכשלים בפרויקטי CRM אינם תקלות טכניות אלא החלטות שנדחו. כאן מרוכזות עשר טעויות שחוזרות בפרויקטי Salesforce, הסימן המוקדם שמזהה כל אחת מהן בזמן, ופעולת המניעה שעולה מעט אם עושים אותה מוקדם ויקר מאוד אם עושים אותה אחרי Go Live.
בחירת חברה, עלויות ומכרזים
רוב הארגונים פונים לספק ומבקשים "הטמעה", גם כשמה שהם צריכים הוא אבחון או ליווי. הבחירה בסוג השירות הלא נכון היא הסיבה השכיחה לפרויקט שמסתיים בתוצר שאיש לא ביקש. כאן מיפוי לפי סימפטום: מה מזמינים בכל מצב, מה התוצר, ומה סימני האזהרה.
בחירת חברה, עלויות ומכרזים
יועץ Salesforce נדרש בעיקר בנקודות שבהן טעות יקרה לתיקון — לא בכל שאלה טכנית. המאמר מגדיר חמישה טריגרים שמצדיקים ייעוץ חיצוני, מפריד בין יועץ לארכיטקט ולאדמין, ומפרט את התוצרים שבלעדיהם שילמתם על פגישות ולא על החלטות.
Agentforce ו-AI
לפני שבונים סוכן ראשון כדאי לענות על שאלה זולה יותר: האם הארגון בכלל מוכן. המדריך מציג בדיקת מוכנות בחמישה צירים - תהליך, נתונים, ידע, הרשאות ותפעול - עם ציון לכל ציר, סף מינימלי לפיילוט ומה עושים עם הפערים שנמצאו.
שיפור וחילוץ פרויקטים
Health Check אינו סקר דעות על המערכת אלא אבחון מבוסס ראיות: מטא-דאטה, לוגים, נתוני שימוש ותצפית על משתמשים אמיתיים. המדריך מפרט את שבעת צירי הבדיקה, את שיטת דירוג החומרה ואת מבנה התוצר שממנו אפשר לגזור החלטות תקציב.
