הצוות צריך לקבל פרטי קשר נחוצים ואת ההקשר שמסביר מה האדם ביקש: איזו הצעה ראה, מאיזה עמוד פנה ומה בחר בטופס. לפני שמאשרים את החיבור ל-CRM, מערכת לניהול קשרי לקוחות ופניות, מומלץ לבקש טבלת מיפוי ובדיקת קליטה בפועל. בכל שורה כדאי להגדיר מה נשלח, היכן יישמר, למה צריך אותו ומי בודק שהגיע נכון. הודעת הצלחה בטופס אינה תחליף לבדיקה הזאת.
מתחילים מהמידע שנחוץ לשיחה
במקום לבקש ממי שמחבר את הטופס להעביר "את כל הנתונים", כדאי להתחיל בשאלה פשוטה: מה צריך לדעת מי שיפתח את הפנייה? למשל, באיזה אמצעי קשר להשתמש ועל איזה שירות לדבר.
המלצת Landing היא להפריד בין שלוש קבוצות: תשובות שהאדם מילא, מידע על העמוד והשליחה, וכללי עבודה שנקבעים בתוך המערכת. כך אפשר לבדוק כל חלק בנפרד, בלי להניח ששדה שהופיע בטופס גם נשמר במקום הנכון.
אם אתם עדיין בשלב בניית דף הנחיתה, כדאי להכין את המיפוי לצד הטופס. לכל שאלה שמוסיפים, הגדירו גם שימוש ברור אחרי הקליטה. אם אין שימוש כזה, שקלו לוותר עליה.
טבלת מיפוי שכדאי לבקש לפני החיבור
הטבלה הבאה היא המלצת Landing ודוגמה להמחשה בלבד. אלו אינם שדות חובה לכל עסק או דרישת חוק. שמות השדות צריכים להתאים למערכת ולדרך העבודה שלכם.
| מהיכן מגיע המידע | שדה מוצע ב-CRM | למה צריך אותו | איך בודקים ומי מאשר |
|---|---|---|---|
| פרט קשר נחוץ מהטופס | טלפון או מייל | לאפשר קשר בערוץ שנבחר | משווים לפרט בדיקה שבשליטת העסק; נציג הצוות מאשר |
| בחירה בטופס או הגדרת ההצעה בעמוד | שירות או הצעה | להבין מה האדם ביקש | בודקים שההצעה המדויקת מופיעה; בעל העסק מאשר |
| הגדרת העמוד והטופס | עמוד מקור ושם טופס | לזהות מאיפה נשלחה הפנייה | משווים לעמוד ולטופס שנבדקו; מבצע החיבור מאשר |
| זמן השליחה וזמן הקליטה, לפי התכנון | מועד שליחה ומועד קליטה | לברר מתי נשלח הטופס ומתי נקלט | מוודאים שהזמנים מוגדרים ומובנים; מבצע החיבור בודק |
| פרמטרי קמפיין, כשישנם | מקור, אמצעי וקמפיין | לשמור הקשר שיווקי ידוע | משווים לערכי קישור הבדיקה; אחראי השיווק מאשר |
| תשובות רלוונטיות מהטופס | שדות תשובה מתאימים | להכין את השיחה בלי לשאול הכול מחדש | משווים כל תשובה; נציג הצוות מאשר |
כדאי להוסיף למסמך העבודה גם את שם השדה המדויק בכל צד ואת ההתנהגות כשאין ערך. למשל: האם השדה נשאר ריק או מקבל סימון מוסכם של "לא ידוע". כך מי שבודק אינו צריך לנחש אם מדובר בחסר צפוי או בתקלה.
מבדילים בין תוכן הטופס לכללי העבודה במערכת
כדוגמה למבנה אצל ספק אחד, תיעוד HubSpot מפריד בין שמות וערכי שדות הטופס, מועד השליחה submittedAt והקשר context, הכולל pageUri ו-pageName. אין בכך הוכחה שהמידע הזה נשמר בחיבור שלכם, ואין צורך לבחור דווקא במערכת הזאת.
בנפרד ממיפוי הנתונים, מומלץ להגדיר מי אחראי לפנייה, מה הסטטוס הראשוני שלה ומה הפעולה הבאה. אלה כללי עבודה שצריך לתכנן ולבדוק, לא פרטים שכדאי להניח שהטופס כבר שלח.
בקשו שמות של אחראים גם בצד העסק וגם בצד החיבור. מי מתקן ערך שנכנס לשדה הלא נכון? מי מאשר שהפנייה מופיעה לצוות? את המשך הטיפול אפשר לתכנן בעזרת המדריך על לידים שלא עונים; כאן המטרה היא לוודא שהפנייה נמסרה עם ההקשר הנכון.
שומרים את ההצעה ולא מנחשים את המקור
מומלץ לשמור תיאור ברור של ההצעה שהוצגה בזמן הפנייה, לצד העמוד והטופס. לדוגמה, "בקשת שיחה על שירות א'" מועיל יותר לצוות מתווית פנימית כמו "טופס חדש". אם משנים הצעה בעמוד קיים, הגדירו כיצד הפניות הישנות יישארו מובנות לאחר השינוי.
לפי תיעוד Google Analytics על קישורי קמפיין, הפרמטרים utm_source, utm_medium ו-utm_campaign מסמנים מקור, אמצעי וקמפיין לצורכי המדידה. הערכים רגישים לאותיות גדולות וקטנות. עצם הופעתם בכתובת אינה מוכיחה שנשמרו גם ב-CRM, אינה מזהה לקוח ואינה מעידה על איכות הפנייה.
לכן כדאי לבדוק את מעבר הערכים בפועל. אל תציגו UTM כאילו הוא שאילתת החיפוש של האדם. כשאין מקור, המלצתנו היא לסמן את החסר כפי שהוא, בלי להשלים מקור משוער לפי שם העמוד או תחושת בטן.
מחברים תשובות המשך בלי לאבד את הפנייה המקורית
אם מתכננים שאלות נוספות אחרי השליחה, כדאי להגדיר מראש כיצד התשובות ייקשרו לפנייה המקורית. המלצת התכנון היא להשתמש במזהה פנייה מתאים ולבדוק שהקישור פועל. מזהה כזה נועד לסייע בקישור ובבירור; הוא אינו הבטחה למניעת כפילויות.
לצד זה, כתבו מה אמור לקרות בשליחה חוזרת: האם מעדכנים רשומה, מוסיפים פנייה נפרדת או מעבירים לבדיקה. אל תתכננו מיזוג אנשים לפי שם בלבד. מומלץ להגדיר דרך ששומרת את היסטוריית הפניות, ולא מחליפה בשקט את הבקשה הקודמת.
זהו תכנון מותאם לעסק ולמערכת, לא כלל מובנה בכל CRM. את התוכן והעיתוי של שאלות ההמשך אפשר לתכנן במדריך על דף תודה וחימום לידים. בבדיקת החיבור התמקדו בשאלה אחת: האם התשובה הנוספת הגיעה לפנייה הנכונה?
מבצעים מבחן קבלה לפני שמאשרים
מבחן הקבלה הבא הוא המלצת Landing. השתמשו בפניית בדיקה ובפרטי קשר שבשליטת העסק, לא בפרטי אדם אמיתי שנבחר באקראי.
- מכינים ערכים צפויים. רושמים מה אמור להופיע בכל שדה, כולל ההצעה, העמוד ותשובות הטופס.
- שולחים מהעמוד עצמו. משתמשים בקישור בדיקה עם ערכי קמפיין ידועים, ולא מסתפקים בהזנה ידנית במערכת.
- פותחים את הרשומה שהגיעה. משווים שדה מול שדה. בודקים גם שהאחראי והסטטוס תואמים לכללי העבודה שסוכמו.
- בודקים גם בלי UTM. מוודאים שהפנייה נקלטת ושמקור חסר לא מוחלף בערך מומצא.
- שולחים תשובת המשך וניסיון חוזר. משווים להתנהגות שסוכמה ובודקים שלא נמחקה היסטוריה ושלא נוצר קישור לאדם אחר.
מומלץ לשמור במסמך הקבלה את התוצאה הצפויה, התוצאה בפועל ומי אחראי לתיקון. אם משהו לא תואם, תקנו ובדקו שוב. אל תאשרו הבטחה של "אין כפילויות" בלי לבחון את התרחישים שסיכמתם.
מפרידים בין מידע לצוות לבין מידע למדידה
הנחיות Google Analytics אוסרות שליחת מידע שמאפשר זיהוי אישי, כגון כתובות מייל וטלפונים, למערכת המדידה. לכן אין לכלול שם, מייל, טלפון או תשובות מזהות בפרמטרי UTM או באירועי Analytics.
המלצתנו היא למפות בנפרד את המידע הדרוש לצוות ב-CRM ואת נתוני המדידה. אל תאספו מידע נוסף רק כי אפשר להוסיף שדה. לכל פרט בקשו מטרה ברורה והגדירו היכן הוא אמור להישמר. הנחיית הספק אינה ייעוץ משפטי, והבדיקות במדריך אינן הבטחה לעמידה בדין.
שאלות נפוצות על חיבור הטופס
האם כל טופס מתחבר אוטומטית ל-CRM?
אין להניח שכן. בקשו פירוט של החיבור המתוכנן ואשרו אותו רק אחרי השוואה בין פניית בדיקה לרשומה שהתקבלה.
האם צריך לשמור את כל הפרמטרים?
המלצתנו היא לשמור רק מידע בעל שימוש מוגדר. בחרו אילו פרמטרים נחוצים, והימנעו מהעברת מידע מזהה למדידה.
מה עושים כשמקור הפנייה לא ידוע?
מסמנים חסר לפי הכלל שסוכם. אם ציפיתם לקבל מקור, בדקו את החיבור; אל תשלימו ערך משוער.
האם מילוי נוסף תמיד יוצר פנייה חדשה?
אל תניחו זאת. הגדירו את ההתנהגות הרצויה ובדקו שליחה חוזרת ותשובות המשך, תוך שמירה על ההיסטוריה.
האם מספיק שהתקבל מייל מהטופס?
לא לצורך אישור החיבור. מבחן הקבלה המומלץ כולל פתיחת הרשומה ב-CRM ובדיקת המידע, ההקשר וכללי העבודה שסוכמו.
