אילו נתונים צריכים לעבור מדף הנחיתה ל-CRM ואיך בודקים שהגיעו?

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

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

מתחילים מהמידע שנחוץ לשיחה

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

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

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

טבלת מיפוי שכדאי לבקש לפני החיבור

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

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

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

מבדילים בין תוכן הטופס לכללי העבודה במערכת

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

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

שומרים את ההצעה ולא מנחשים את המקור

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

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

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

מחברים תשובות המשך בלי לאבד את הפנייה המקורית

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

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

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

מבצעים מבחן קבלה לפני שמאשרים

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

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

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

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

מפרידים בין מידע לצוות לבין מידע למדידה

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

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

שאלות נפוצות על חיבור הטופס

האם כל טופס מתחבר אוטומטית ל-CRM?

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

האם צריך לשמור את כל הפרמטרים?

לא. שמרו רק מידע שיש לו שימוש מוגדר, ואל תעבירו מידע מזהה למערכת המדידה.

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

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

האם מילוי נוסף תמיד יוצר פנייה חדשה?

לא בהכרח. הגדירו מה אמור לקרות, ובדקו שליחה חוזרת ותשובות המשך בלי לאבד את ההיסטוריה.

האם מספיק שהתקבל מייל מהטופס?

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