CRM שאף אחד לא מעדכן: איך לבנות שלבים ושדות שאנשים באמת ממלאים
רוב מערכות ה-CRM לא נכשלות בגלל הכלי אלא בגלל המבנה: יותר מדי שלבים, יותר מדי שדות חובה ושלב שאף אחד לא יודע מתי עוברים ממנו. כך בונים מבנה שמתעדכן מעצמו.

רוב העסקים שמטמיעים מערכת ניהול לקוחות מתחילים מאותו מקום: יושבים עם מנהל המכירות, רושמים כל מה שאולי יהיה מעניין לדעת על ליד, והופכים כל פריט כזה לשדה. מקור הליד, גודל החברה, תקציב משוער, מתחרה נוכחי, תאריך החלטה צפוי, רמת עניין, ועוד עשרה כאלה. זה נראה אחראי. מי שמשלם על מערכת רוצה להפיק ממנה את המקסימום, ונתונים שלא נאספים היום לא יהיו שם כשירצו לנתח אותם בעוד שנה.
הבעיה מתגלה אחרי חודשיים. השדות החשובים באמת, כמו מתי דיברו לאחרונה עם הלקוח ומה הצעד הבא, ממולאים פחות ופחות. השלבים במשפך מפסיקים לשקף את המציאות, כי אף אחד לא זוכר להזיז עסקה משלב לשלב. ובסוף מנהל המכירות מבקש מהנציגים לשלוח לו עדכון בוואטסאפ, כי "במערכת זה לא מעודכן". מאותו רגע המערכת היא ארכיון יקר, ולא כלי עבודה.
זה כמעט אף פעם לא עניין של הכלי. אותו מבנה עמוס ייכשל בכל מערכת, והמעבר למערכת אחרת רק יעתיק את הכישלון. מה שקובע אם CRM חי או מת הוא המבנה שבונים בתוכו: כמה שלבים, מה מגדיר מעבר בין שלבים, וכמה שדות מבקשים מאדם למלא לפני שהוא יכול להמשיך לעבוד.
למה נציגים מפסיקים לעדכן
עדכון של מערכת הוא עבודה שלא מחזירה לנציג כלום באותו רגע. הוא סיים שיחה, הלקוח ביקש הצעת מחיר, והדבר הבא שהוא רוצה לעשות הוא לשלוח אותה. כל שדה שעומד בינו לבין הפעולה הבאה הוא חיכוך, וחיכוך מצטבר.
יש שלושה מנגנונים שחוזרים כמעט בכל מערכת שהפסיקה להתעדכן:
- שדות חובה שלא קשורים לפעולה. אם כדי להזיז עסקה לשלב "הצעה נשלחה" צריך למלא את גודל החברה ואת המתחרה הנוכחי, הנציג ימלא ערך כלשהו רק כדי לעבור. הנתון נראה מלא, אבל הוא זבל.
- שלבים בלי הגדרת יציאה. "בטיפול", "מתעניין" ו"חם" הם תחושות, לא אירועים. כששלב לא מוגדר על ידי משהו שקרה, כל נציג מזיז אותו בזמן אחר, ודוח המשפך הופך לממוצע של מצבי רוח.
- יותר מדי שלבים. משפך של תשעה שלבים דורש שמונה פעולות עדכון לכל עסקה. בעסק קטן, שבו אותו אדם גם מוכר, גם שולח הצעות וגם גובה, זה פשוט לא יקרה.
❌ הסימן המובהק: אם הערך הנפוץ ביותר בשדה מסוים הוא "אחר" או הערך הראשון ברשימה, השדה הזה לא נאסף באמת. הוא נמלא כדי להיפטר ממנו.
שלבים שמוגדרים על ידי אירוע
הכלל הכי שימושי בבניית משפך הוא שכל שלב צריך להיות מוגדר על ידי דבר שקרה ואפשר להצביע עליו, ולא על ידי הערכה של מישהו. "נקבעה פגישה" הוא אירוע. "נשלחה הצעת מחיר" הוא אירוע. "הלקוח מתלבט" הוא לא.
הטבלה הבאה משווה בין שני סוגי שלבים, כפי שהם נראים ברוב המערכות שנבנו בלי הגדרה כזאת:
| שלב מבוסס תחושה | שלב מבוסס אירוע | מה מזיז את העסקה |
|---|---|---|
| ליד חדש | פנייה התקבלה | טופס, שיחה או מייל נכנסים |
| מתעניין | שיחת היכרות התקיימה | נרשמה שיחה עם תאריך |
| חם | הצעת מחיר נשלחה | יש מסמך הצעה מצורף |
| במשא ומתן | הלקוח הגיב להצעה | תשובה כלשהי, גם שלילית |
| כמעט סגור | נסגר או אבד | חתימה, תשלום או סירוב מפורש |
היתרון של העמודה האמצעית הוא לא רק דיוק. כששלב מוגדר על ידי אירוע, חלק מהמעברים אפשר להזיז אוטומטית: הצעה שנשלחה מתוך המערכת יכולה להזיז את העסקה בעצמה, ופגישה שנקבעה ביומן המחובר יכולה לעשות אותו דבר. כך העדכון מפסיק להיות עבודה נפרדת. מי שרוצה להבין את ההבדל בין חיבור מובנה לבין אוטומציה שבונים בעצמם ימצא אותו מפורט במדריך על אינטגרציה מול אוטומציה.
✅ כלל אצבע: חמישה או שישה שלבים מספיקים לרוב העסקים הקטנים. אם צריך יותר, כדאי לבדוק אם זה בעצם שני תהליכים שונים שנדחסו למשפך אחד.
כמה שדות, ואילו
המבחן לכל שדה הוא שאלה אחת: האם מישהו מקבל החלטה על סמך הערך הזה בחודש הקרוב? אם כן, השדה נשאר. אם התשובה היא "אולי יום אחד נרצה לנתח את זה", השדה יכול להיות אופציונלי, או לא להיות בכלל.
בפועל, כמעט כל עסק צריך בליבה את אותם שדות:
- איש קשר ודרך יצירת קשר. בלי זה אין רשומה.
- הצעד הבא ותאריך שלו. זה השדה החשוב ביותר במערכת, והוא זה שנעלם ראשון במבנים עמוסים. עסקה בלי צעד הבא היא עסקה שאף אחד לא מטפל בה.
- סכום משוער. גם הערכה גסה, כי בלעדיה אי אפשר לתעדף.
- מקור. רק אם מישהו באמת מחליט על תקציב שיווק לפי הנתון הזה.
כל השאר, כמו גודל החברה או המתחרה הנוכחי, יכול להיאסף בהמשך, כשהעסקה מתקדמת ויש סיבה לדעת. שדה שנדרש בשלב ההצעה ולא בשלב הפנייה ימולא בערך אמיתי, כי בשלב הזה הנציג באמת יודע את התשובה.
נוהל לסידור מערכת קיימת
אם המערכת כבר עמוסה, לא צריך לבנות אותה מחדש. אפשר לעבור עליה בשישה צעדים, בדרך כלל בחצי יום עבודה:
- צעד 1: למשוך דוח מילוי. לכל שדה, כמה אחוז מהרשומות מהחודשיים האחרונים מכילות ערך שהוא לא ברירת המחדל. רוב המערכות מאפשרות לייצא את הרשומות לקובץ ולספור שם.
- צעד 2: לסמן את השדות שאף אחד לא קורא. לשאול את מי שמקבל החלטות אילו דוחות הוא פותח בפועל. שדה שלא מופיע באף דוח ובאף תצוגה הוא מועמד להסרה.
- צעד 3: להוריד שדות חובה. להשאיר חובה רק על השדות מהרשימה שלמעלה, ולהעביר את השאר לשלב המאוחר שבו הם רלוונטיים.
- צעד 4: לכתוב הגדרת יציאה לכל שלב. משפט אחד: "עסקה עוברת מכאן כש...". שלב שאי אפשר לכתוב לו משפט כזה צריך להתמזג עם שלב אחר.
- צעד 5: לחבר את מה שאפשר. יומן, מייל ומסמכי הצעה הם שלושת המקורות הנפוצים ביותר למעבר שלבים אוטומטי. כל חיבור כזה הוא עדכון שנציג לא צריך לזכור.
- צעד 6: לבדוק שוב אחרי חודש. אותו דוח מילוי. אם השדה "הצעד הבא" ממולא ביותר משמונים אחוז מהעסקאות הפתוחות, המבנה עובד.
לפני שמוחקים שדה, כדאי לייצא את הערכים שלו לקובץ נפרד. גם נתון חלקי יכול להיות שימושי פעם, וכל מעבר בין מערכות בלי לאבד היסטוריה מתחיל מאותו הרגל.
מתי לא לגעת במבנה
יש מצבים שבהם העומס הוא לא הבעיה, ופישוט רק יזיק. אם העסק פועל בתחום מפוקח, שבו חובה לתעד פרטים מסוימים על כל פנייה, השדות האלה נשארים גם אם הם מעצבנים. אם צוות המכירות גדול ויש מנהל שבאמת מנתח את הנתונים כל שבוע ומשנה החלטות לפיהם, שדות נוספים יכולים להצדיק את עצמם. ואם המערכת מתעדכנת היטב כבר עכשיו, אין סיבה לתקן משהו שעובד רק כי מאמר אמר שחמישה שלבים זה המספר הנכון.
יש גם מצב הפוך: כשהתהליך שלכם באמת לא דומה למשפך מכירות. עסקים שמוכרים פרויקטים ארוכים עם כמה מקבלי החלטות, או שהמכירה בהם נמשכת לתוך הביצוע, מגלים לפעמים שכל מערכת מדף מכריחה אותם לדחוס תהליך מסועף לקו ישר. במקרה כזה מערכת לקוחות שנבנית סביב שלבי העבודה של העסק יכולה להתאים יותר מעוד סבב של עקיפים בכלי קיים. זו החלטה יקרה יותר בהתחלה ומעבירה אליכם את התחזוקה, אז כדאי להגיע אליה רק אחרי שניסיתם לפשט.
עוד חומרים על בחירה וניהול של מערכות לקוחות נמצאים בקטגוריית ה-CRM, כולל המדריך ל-HubSpot CRM.
שאלות נפוצות
כמה שלבים צריך במשפך מכירות של עסק קטן?
לרוב העסקים הקטנים חמישה או שישה שלבים מספיקים, כל עוד כל אחד מהם מוגדר על ידי אירוע ברור. אם יש יותר, כדאי לבדוק אם חלק מהשלבים הם בעצם תחושות ולא אירועים. משפך קצר שמתעדכן שווה יותר ממשפך מפורט שאף אחד לא מזיז.
איך יודעים ששדה מסוים מיותר?
מושכים את הרשומות מהחודשיים האחרונים ובודקים כמה מהן מכילות ערך אמיתי בשדה, ולא ערך ברירת מחדל או "אחר". אם השדה ממולא בפחות ממחצית הרשומות, או שאף אחד לא משתמש בו בדוח, הוא מועמד להסרה או להפיכה לאופציונלי.
האם להחליף מערכת אם אף אחד לא מעדכן אותה?
בדרך כלל לא. אם המבנה עמוס, הוא ייכשל גם במערכת החדשה, וההחלפה רק תוסיף עלות מעבר. כדאי קודם לפשט את השלבים והשדות במערכת הקיימת, ולשקול מעבר רק אם גם אחרי הפישוט הכלי עצמו מקשה על העבודה.
מה השדה הכי חשוב ב-CRM?
הצעד הבא והתאריך שלו. עסקה בלי צעד הבא היא עסקה שאף אחד לא מטפל בה, וזה השדה שנעלם ראשון כשהמבנה עמוס מדי. אם רק שדה אחד ממולא בעקביות, עדיף שזה יהיה הוא.