CRM שאף אחד לא מעדכן: איך לבנות שלבים ושדות שאנשים באמת ממלאים

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

CRM שאף אחד לא מעדכן: איך לבנות שלבים ושדות שאנשים באמת ממלאים

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

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

זה כמעט אף פעם לא עניין של הכלי. אותו מבנה עמוס ייכשל בכל מערכת, והמעבר למערכת אחרת רק יעתיק את הכישלון. מה שקובע אם CRM חי או מת הוא המבנה שבונים בתוכו: כמה שלבים, מה מגדיר מעבר בין שלבים, וכמה שדות מבקשים מאדם למלא לפני שהוא יכול להמשיך לעבוד.

למה נציגים מפסיקים לעדכן

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

יש שלושה מנגנונים שחוזרים כמעט בכל מערכת שהפסיקה להתעדכן:

❌ הסימן המובהק: אם הערך הנפוץ ביותר בשדה מסוים הוא "אחר" או הערך הראשון ברשימה, השדה הזה לא נאסף באמת. הוא נמלא כדי להיפטר ממנו.

שלבים שמוגדרים על ידי אירוע

הכלל הכי שימושי בבניית משפך הוא שכל שלב צריך להיות מוגדר על ידי דבר שקרה ואפשר להצביע עליו, ולא על ידי הערכה של מישהו. "נקבעה פגישה" הוא אירוע. "נשלחה הצעת מחיר" הוא אירוע. "הלקוח מתלבט" הוא לא.

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

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

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

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

כמה שדות, ואילו

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

בפועל, כמעט כל עסק צריך בליבה את אותם שדות:

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

נוהל לסידור מערכת קיימת

אם המערכת כבר עמוסה, לא צריך לבנות אותה מחדש. אפשר לעבור עליה בשישה צעדים, בדרך כלל בחצי יום עבודה:

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

מתי לא לגעת במבנה

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

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

עוד חומרים על בחירה וניהול של מערכות לקוחות נמצאים בקטגוריית ה-CRM, כולל המדריך ל-HubSpot CRM.

שאלות נפוצות

כמה שלבים צריך במשפך מכירות של עסק קטן?

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

איך יודעים ששדה מסוים מיותר?

מושכים את הרשומות מהחודשיים האחרונים ובודקים כמה מהן מכילות ערך אמיתי בשדה, ולא ערך ברירת מחדל או "אחר". אם השדה ממולא בפחות ממחצית הרשומות, או שאף אחד לא משתמש בו בדוח, הוא מועמד להסרה או להפיכה לאופציונלי.

האם להחליף מערכת אם אף אחד לא מעדכן אותה?

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

מה השדה הכי חשוב ב-CRM?

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