מערכת CRM לארגונים: איך בוחרים, מאפיינים ומטמיעים

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

מה זה מערכת CRM, ומה היא לא

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

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

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

CRM או ERP: מי אחראי על מה

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

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

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

איך יודעים שהארגון צריך CRM

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

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

מה מגדירים לפני שבוחרים: תהליכים, משתמשים וערוצים

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

תהליכים

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

משתמשים ותפקידים

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

ערוצים

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

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

מערכת מדף או פיתוח מותאם

יש שלוש דרכים עיקריות לקבל CRM. הראשונה היא פלטפורמת מדף בענן, כמו Salesforce, Microsoft Dynamics 365, HubSpot, Zoho CRM או monday CRM, וגם ספקים ישראליים רבים. השנייה היא מודול CRM בתוך מערכת ERP שכבר יש לכם. השלישית היא מערכת שנבנית לפי התהליך שלכם, על תשתית קיימת או מאפס. אנחנו לא מדרגים פלטפורמות, ואין כאן מחירים: הם משתנים, תלויים במספר המשתמשים ובמודולים, וצריך לקבל אותם בכתב מכל ספק.

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

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

איך בוחרים מערכת CRM: שאלות לספק

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

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

אינטגרציות: אתר, טלפון, וואטסאפ, דואר ו-ERP

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

טפסים באתר ודפי נחיתה

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

טלפון ומעקב שיחות

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

וואטסאפ

חיבור וואטסאפ ל-CRM נעשה דרך WhatsApp Business Platform של מטא, ישירות או דרך ספק שמתממשק אליה. שני כללים של מטא משפיעים ישירות על התהליך. הראשון: לפי מדיניות ה-opt-in של מטא, צריך לקבל מהאדם הסכמה לקבל הודעות מהעסק, ולציין בבירור את שם העסק שהוא מסכים לקבל ממנו הודעות. השני: לפי התיעוד של Cloud API, כשאדם פונה לעסק נפתח חלון שירות של 24 שעות, ומחוצה לו אפשר לשלוח רק תבניות הודעה שאושרו מראש. נכון לאוקטובר 2026. המשמעות ל-CRM: צריך שדה הסכמה עם תאריך ומקור, וצריך תבניות מאושרות למעקב שנשלח אחרי יותר מיממה.

דואר אלקטרוני ומסרונים

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

ERP

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

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

הסבת נתונים וניקוי לפני העלייה לאוויר

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

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

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

פרטיות אחרי תיקון 13: מה זה אומר על ה-CRM

CRM הוא כמעט תמיד מאגר מידע לפי חוק הגנת הפרטיות, כי הוא מחזיק מידע אישי על אנשים מזוהים. תיקון 13 לחוק נכנס לתוקף ב-14 באוגוסט 2025, ולפי השאלות והתשובות של הרשות להגנת הפרטיות הוא מגדיר מחדש את המונחים ומטיל את החובות על הארגון עצמו, שנקרא עכשיו בעל השליטה במאגר. כל ספק שמעבד את המידע עבורו, כולל ספק ה-CRM בענן וחברת ההטמעה, הוא מחזיק. הנה מה שזה אומר בפועל, נכון לאוקטובר 2026. זו רשימת היכרות, לא ייעוץ משפטי.

מי צריך ממונה על הגנת הפרטיות

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

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

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

מה אומרים לאדם כשאוספים ממנו מידע

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

עיון, תיקון ומידע שיוצא מישראל

לכל אדם יש זכות לעיין במידע עליו שמוחזק במאגר ולבקש לתקן אותו. לפי הרשות, העיון מתאפשר בעברית, בערבית או באנגלית. המשמעות ל-CRM: צריך דרך לשלוף את כל מה שנשמר על אדם, כולל הערות של נציגים, ולכן כותבים הערות כאילו הלקוח יקרא אותן. ואם המערכת מאחסנת נתונים מחוץ לישראל, חלות תקנות העברת מידע אל מאגרי מידע שמחוץ לגבולות המדינה. גילוי הדעת של הרשות על תקנה 2(4) מסביר מה צריך לכלול הסכם עם מקבל המידע בחו״ל. זה בדיוק הסעיף שהיועץ המשפטי ירצה לראות בהסכם עם ספק ענן.

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

הרשאות ותיעוד גישה

תקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017 הן המקום שבו החוק פוגש את ההגדרות של ה-CRM. לפי התרגום לאנגלית שמפרסמת הרשות (הנוסח המחייב הוא העברי), ארבעה דברים רלוונטיים ישירות:

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

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

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

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

הטמעת CRM: הדרכה ואימוץ

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

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

איך מודדים שה-CRM הצליח

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

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

מה עושים עכשיו

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

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

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