הגדרת טפסי CRM ב-Bitrix24: היכן הולכות לאיבוד פניות מהאתר
תקלה טיפוסית נראית תמימה: מבקר ממלא טופס, רואה אישור, והמייל נוחת לתיבת הדואר המשותפת של המחלקה. ב-CRM לעומת זאת אין ליד — המטפל שולח התראה במייל ולא יוצר כרטיס. אם את התיבה קוראים כמה אנשים, הפנייה או נתקעת בלי בעלים, או שנלקחת לעבודה פעמיים.
מכאן מתחילה העברה ידנית: המנהל מעתיק שדות מהמייל לכרטיס, בוחר ידנית אחראי ושלב. בסופי שבוע ובלילה פשוט אין מי שיעשה את השלב הזה — הפנייה שוכבת עד הבוקר, ובזמן הזה הלקוח כבר כותב לספק הבא. אובדן לידים בשעות שאינן שעות עבודה הוא היקר מכולם: הפנייה מגיעה ממי שבוחר ממש עכשיו.
כפילויות של פניות — שכבה נפרדת של אובדן. לקוח כותב מטופס בשני עמודים, אחר כך מתקשר, ויצירת כרטיס ידנית אינה משווה טלפון וכתובת. במאגר מופיעים שני אנשי קשר עם היסטוריות התכתבות שונות, המנהלים לא רואים תמונה כוללת, והלקוח מקבל שתי תשובות עם תנאים לא מתואמים.
הסיבה לכל שלוש התקלות משותפת — הנתק בין האתר ל-CRM: הטופס לא יודע על שדות הכרטיס, על כללי איחוד אנשי קשר ועל מי שאליו מיועד הליד.
הגדרה נכונה של טפסי CRM ב-Bitrix24 סוגרת בדיוק את הגבול הזה: הפנייה הופכת לכרטיס עם אחראי ושלב, פניות חוזרות נמשכות לאיש קשר קיים, ופניות לילה נכנסות לתור עם תשובה אוטומטית. נפרט איך זה בנוי ומה לבדוק בהגדרה.
מה נותנת החיבור בין האתר ל-CRM: מהירות, שלמות נתונים, שליטה
החיבור מניב אפקטים מדידים לא מעצם קיומו, אלא כאשר מוגדרים מסלול, שדות וכללי הסלמה. Bitrix24 פועל כאן כנקודה אחת שבה פנייה מהאתר הופכת לעסקה עם היסטוריית נגיעות.
מהירות תגובה והפצה
הטופס כותב את הפנייה ל-CRM מיד, ולא אחרי מיון הדואר — ולכן זמן התגובה לפנייה נמדד בדקות. האחראי נקבע על ידי כלל: לפי אזור, מוצר או תור עם רוטציה בתוך הקבוצה.
אם בתוך הזמן שנקבע אף אחד לא לקח את הפנייה, מופעלת הסלמה למנהל — שיעור הפניות בלי אחראי נשאר באפס ולא «הולך לאיבוד» בזמן החלפת משמרת או חופשה.
שלמות הנתונים על הליד
לכרטיס נכנסים המקור, עמוד הכניסה, פרמטרי המעבר, הרכב השדות שנשלחו והיסטוריית הנגיעות. המנהל רואה מה האדם צפה בו ומה כבר שאל — שיחות הבהרה ושאלות חוזרות נעשות פחות. חלון מכירות אחיד אוסף טפסים, שיחות חזרה, צ'אט ודואר לתור אחד, וכך נסגר סוג התקלות של «הפנייה נעלמה לשום מקום».
פחות שגרה למנהל
השלמה אוטומטית של תבניות, תזכורות על הצעד הבא והפרדת הרשאות מסירים העברה ידנית של כרטיסים בין שלבים. הזמן שהתפנה מוקדש לעסקאות, ולא לחיפוש נתונים בהתכתבויות.
«לא הטופס הוא שקובע, אלא המסלול: לאן הרשומה מגיעה, מי אחראי ומה קורה אם אף אחד לא לקח אותה».
דרכים לאיסוף פניות: טופס באתר, ווידג'ט, דואר, טלפוניה
הקהל מגיע בדרכים שונות, וקנה אחד כמעט אף פעם לא מכסה את כל הזרימה. טופס באתר אוסף את מי שמוכן למלא שדות, אבל מפסיד את מי שקל לו יותר ללחוץ «התקשרו אליי». לכן את מערך האפשרויות מתאימים לתרחישי הלקוח, ולא לנוחות של מחלקת המכירות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| טופס אינטרנט באתר | דרושים נתונים מובנים: משימה, לוחות זמנים, הרכב הבקשה | חלק מהמבקרים לא ממלאים שדות, ובלי בדיקות מגיע זבל |
| שיחה חוזרת מהאתר | הלקוח לא מוכן לכתוב, אבל מוכן לדבר | עד השיחה אין נתונים, והמנהל מבזבז זמן על סינון ראשוני |
| תיבת דואר כערוץ | התכתבות עם קבצים מצורפים, מכרזים, בקשות גדולות | בלי מיון המיילים הפניות לא נכנסות לכרטיס והולכות לאיבוד בתיקייה המשותפת |
| טלפוניה ומסרים | שאלות מהירות, פניות חוזרות, תנועה מהנייד | בלי קישור לכרטיס היסטוריית השיחה מתקיימת בנפרד מהעסקה |
הסכמה לעיבוד נתונים ואנטי-ספאם
בכל טופס — תיבת סימון נפרדת להסכמה עם קישור למדיניות ושמירת עובדת ההסכמה בכרטיס: זה מגן גם מפני תביעות וגם מפני מחלוקות על מקור איש הקשר.
נגד בוטים פועלים שדה מלכודת מוסתר והגבלת תדירות השליחות מכתובת אחת, וקפצ'ה בכל שלב בדרך כלל מפחיתה את שיעור אלה שמגיעים לשליחה — שמים אותה בנקודות ממוקדות.
הקשר בין הערוץ למקור הפנייה
ערוץ ומקור הפנייה הם שדות שונים. הראשון עונה איך האדם יצר קשר, השני — מאיפה הוא הגיע: תגיות בכתובת הקישור, מספר נפרד לקמפיין, תיבה לייעוד מסוים. אז בדוח רואים את התפוקה של כל ערוץ, ואת הזרימה אפשר לחלק מחדש לפי העובדות, לא לפי תחושות.
איך אנחנו מיישמים: מביקורת נקודות האיסוף ועד מסירת נהלים
תחילה מפרקים איך הפנייה נכנסת למערכת היום: אילו טפסים עומדים באתר, לאן הולכים המיילים, מי ומתי רואה את הפנייה. אחרת הגדרת השדות מתפספסת עם תהליך המכירה בפועל, והמנהלים ממשיכים לעבוד «מחוץ» למשפך. להלן סדר העבודות שלפיו מתבצעת ההטמעה ב-Bitrix24.
ביקורת ומפת הזרימה הנוכחית
- ביקורת נקודות האיסוף. אוספים את כל הטפסים, השאלונים, הצ'אטים ותיבות הדואר, כולל עמודי מבצעים ישנים, ומסמנים היכן הפניות הולכות לאיבוד: ספאם בדואר, כפילויות, היעדר אחראי.
- מפת שדות וסטטוסים. משווים את שדות הטופס לכרטיס העסקה: מה חובה, מה מושלם אוטומטית, אילו ערכים הרשימה מתירה. מגדירים את סטטוסי המשפך שבהם האחראי מקבל התראה.
- סכימת ניתוב לידים. מפזרים את הפניות בין מחלקות, אזורים ומקורות, קובעים כללי נגיעה חוזרת — כפילויות מאוחדות ולא יוצרות עסקה שנייה.
- הגדרת הערוצים. מעבירים את הטפסים לבונה הטפסים, מחברים דואר וטלפוניה, קובעים שדות חובה והגנה מפני ספאם אוטומטי.
בדיקה בפניות לדוגמה
- פניות לבדיקה. מריצים כל תרחיש בפנייה חיה: מהטלפון, עם שדות ריקים, שוב עם אותו איש קשר. בודקים אם הכרטיס הגיע, ואם הסטטוס והאחראי נכונים.
- נוהל טיפול. מתעדים מי ובאיזה מועד לוקח את הפנייה, איך משנה סטטוס, מה עושים עם סירוב ואיך מעבירים את הליד הלאה במשפך.
- מסירה. מוסרים סכימות, נהלים והרשאות, ומכשירים את המנהלים לעבודה עם הסטטוסים החדשים.
ההגדרה אינה נחשבת מוכנה עד שפנייה לא עברה את הדרך מהטופס ועד האחראי בתרחיש חי.
מה נשאר אצלכם: תצורות, סכימות, נהלי טיפול
טופס מוגדר הוא לא רק כפתור באתר. אחרי ההשקה נשאר אצלכם מערך מסמכים שלפיו אפשר להעביר את התהליך לעובד חדש, להרחיב או לשחזר בלי אנחנו: תצורות, מפת שדות וסכימת הטיפול בפניות.
- ערוצי קליטה מוגדרים — אתר, דואר, מסרים: כניסה אחת שבה הפנייה לא הולכת לאיבוד כשמקור משתנה.
- מפת שדות וסטטוסים: איזו תשובה של הטופס נכנסת לאיזה שדה, איזה סטטוס מוקצה בכניסה ולפי אילו אירועים הוא משתנה בהמשך.
- סכימת ניתוב ואחראים: לפי איזה סימן הפנייה עוברת למנהל מסוים או לתור משותף, ומה קורה אם לא הוקצה אחראי.
- כללי הגנה מפני כפילויות: לפי אילו שדות המערכת מחשיבה איש קשר כקיים ואיך פנייה חוזרת נרשמת לכרטיס במקום ליצור חדש.
- התראות ומועדי בקרה: למי נשלח אות על פנייה חדשה ואחרי כמה זמן הוא מוסלם אם אף אחד לא לקח אותה לעבודה.
- סכימת החלפה עם מערכת החשבונות: אילו נתונים יוצאים וחוזרים, ומה עושים במקרה של אי-התאמה.
הנחיות למנהל
מסמך של עמוד-שניים: היכן לראות פניות חדשות, מה לעשות עם נתונים חסרים, איך לתעד סירוב והעברת עסקה. המנהל לא מנחש למה הפנייה לא הגיעה, אלא נעזר בסדר הפעולות.
נוהל טיפול בתקלות
מתארים במה להתחיל אם הפנייה לא הופיעה ב-CRM: בדיקת נקודת הכניסה, יומן האירועים וההכנסה לתור. בנוהל מעוגנים האחראי, זמן התגובה וסדר תיעוד הסיבה — תקלה חוזרת מנותחת לפי אותה סכימה, ולא מאפס.
מקרה בוחן: איך זרימת הפניות מהאתר הפכה לניהולית
מחלקת המכירות של התחום הסיטונאי קיבלה פניות מהאתר לתיבת דואר משותפת ולצ'אט העבודה. הטפסים ב-Bitrix24 אספו אנשי קשר, אבל משם הפנייה חיה מעצמה: התקשר מי שראה ראשון את המייל. על פנייה שאבדה המנהל למד מהלקוח.
מה היה לפני ההטמעה
מדידות במשך חודש: 38% מהפניות נשארו בלי אחראי בשעה הראשונה, וזמן התגובה הממוצע לפנייה — כשבע שעות. כל פנייה חמישית הגיעה ככפילות, והלקוח נפל לשני מנהלים בבת אחת. לעסקה הגיעה בערך כל פנייה עשירית.
מה השתנה אחרי
הטפסים קושרו לעסקאות ב-CRM, נוספו שדות חובה והפצה לפי אזור ושיוך לקוח. כפילויות נחסמות לפי טלפון וכתובת דואר ברגע השליחה: פנייה חוזרת לא יוצרת כרטיס חדש, אלא מצורפת לקיים. על התשובה הראשונה חל תקן עם הסלמה למנהל.
שיעור הפניות בלי אחראי — פחות מ-1%, זמן התגובה בשעות העבודה הצטמצם ל-10–15 דקות. מספר הכפילויות ירד כמעט לאפס, והמרת הטיפול עלתה: לעסקה מגיעה כל פנייה רביעית.
«בעבר על פנייה שאבדה למדתי מהלקוח. היום אני רואה את הזרימה ואת זמן התגובה בחלון אחד ומתערב לפני שהלקוח עוזב», — מנהל התחום של המכירות הסיטונאיות.
את המדידות אנחנו לוקחים לפני ואחרי ההטמעה — לפיהן רואים באיזה שלב זרימת הפניות מאבדת פניות.
במה שונה טופס באתר מטופס בתוך Bitrix24?
ההבדל בנקודה אחת: איפה הפנייה נוצרת. טופס באתר יוצר רשומה ב-CRM אוטומטית ברגע השליחה — הליד מגיע עם שדות, מקור ושיוך לעמוד. פנייה בתוך המערכת מזינים ידנית: המנהל ממלא את הכרטיס אחרי שיחה או מייל.
כלומר, מצבי העבודה של הטפסים נבדלים לא במראה, אלא בנקודת יצירת הרשומה — ומכאן נבדלים מהירות התגובה, שלמות הנתונים וסוג השגיאות.
| אפשרות | היכן נוצרת הפנייה | מי רואה ומתי | מגבלות |
|---|---|---|---|
| טופס באתר עם העברה ל-CRM | אוטומטית בעת השליחה | המנהל האחראי מיד | דרושים ולידציה, הגנה מפני ספאם, כללי הפצה |
| יצירת ליד ידנית בתוך המערכת | המנהל בכרטיס אחרי יצירת הקשר | רק המחבר והמנהל שלו | אובדן בזרימה, כפילויות, מקור לפי זיכרון |
| טופס בלי אינטגרציה (מייל לתיבה) | לא נכנס ל-CRM | מי שמיון את הדואר | אין דיווח ובקרת מועדים |
יצירה ידנית נותנת שליטה מלאה על השדות, אבל לא מתרחבת: בעשרה פניות ביום חלק הולך לאיבוד, והתאריך והמקור נרשמים בדיעבד. טופס אוטומטי מסיר את השגרה, אבל דורש ולידציה מוגדרת, אנטי-ספאם ותור הפצה — אחרת המנהלים מקבלים זבל.
לכן לרוב משלבים בין ערוצים: אתר, מסרים וצ'אט עוברים דרך הטופס, ושיחות וקשרים אישיים — דרך יצירת ליד ידנית לפי תבנית עם שדות חובה. שתי הזרימות מתאחדות למשפך אחד, אחרת האנליטיקה לפי מקורות מתפרקת. אין מצב אוניברסלי: הבחירה תלויה בהיקף הפניות ובמספר הערוצים.
שאלות טכניות על טפסים, לידים וכפילויות ב-CRM
חמש התלבטויות טכניות שעולות לרוב לפני השקת טפסים: למה הפנייה לא מגיעה, איך לתפוס כפילויות של פניות, מה לעשות עם טופס שכבר עובד, האם צריך להעביר את ההיסטוריה ואיך לוודא שבתקלה אף פנייה לא אבדה.
הפנייה לא מגיעה — במה להתחיל?
בודקים את השרשרת חוליה אחר חוליה: ולידציה של שדות בדפדפן, תשובת המטפל בשרת, יצירת הרשומה ב-CRM. יומן השליחות ולוג השגיאות מראים היכן בדיוק הנתק — בדרך כלל זה שדה לא חובה או הרשאה חסומה של חשבון שירות.
איך לתפוס כפילויות של פניות?
משווים לפי טלפון וכתובת דואר מנורמלים, ולחברות — לפי פרטי הזיהוי. במקרה של התאמה הפנייה נקשרת לאיש קשר קיים, ומקרים שנויים במחלוקת עוברים לבדיקה ידנית, כדי שהמנהל יראה היסטוריה אחת ולא שתיים.
האם טופס שכבר מוגדר יצטרך לעבור בנייה מחדש?
תחילה מתעדים את הלוגיקה הנוכחית — שדות, מסלול הפנייה, רובוטים, הרשאות — ומעבירים אותה שלב אחר שלב. הטופס העובד נשאר פעיל עד שהסכימה החדשה תעבור שליחות בדיקה ותתאים לקודמת בתוצאה.
האם צריך להעביר את היסטוריית הפניות?
כן, אם העבודה עם הלקוחות נמשכת: בלי עסקאות והתכתבויות קודמות המנהל מאבד את ההקשר. מעבירים רשומות וקבצים מצורפים, ומשווים את מספרם ואת הקשרים לפניכן ואחריכן — כך רואים ששום דבר לא נפל בהחלפה.
איך לוודא שהפנייה לא אבדה בתקלה?
מגדירים לוג עם מזהה שליחה והתראה לאחראי, ושליחה שלא הגיעה נשמרת בתור לניסיון חוזר. השוואה יומית בין טפסים שנשלחו לרשומות שנוצרו מראה מיד את הפער.
נדון במשימה: מה להכין לשיחה
כדי שההערכה ותוכנית העבודה יתבססו על עובדות ולא על הנחות, כדאי לאסוף כמה נתוני פתיחה לשיחה. אין חובה להכין משהו מראש — חלק מהתמונה המהנדסים שלנו ישחזרו בעצמם, אבל מה שמפורט להלן חוסך סיבוב או שניים של הבהרות ומיד קובע את סדר העבודה.
- כתובות של עמודים ונקודות איסוף שבהן מוצבים היום טפסים, כפתורי יצירת קשר או חלונות קופצים.
- ערוצי הפניות הנוכחיים: טפסים באתר, דואר, מסרים, פניות טלפוניות, פרופילים ברשתות חברתיות.
- מי אחראי על הטיפול בלידים ואיך הפניות מופצות בין המנהלים והמחלקות.
- תרחישים בעייתיים: פניות חוזרות של אותו לקוח, פניות מחוץ לשעות העבודה, ספאם ושליחות בדיקה.
- דרישות לשדות חובה ולהסכמה לעיבוד נתונים אישיים.
- לוחות הזמנים הצפויים להשקה — התאריכים שעד אליהם הטפסים כבר אמורים לקלוט פניות.
- הרשאות גישה לפורטל והרשאות לשינוי ישויות, אם אנחנו מתכננים לגעת במשפכים ובכרטיסים קיימים.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית עבודה: סדר העבודות לפי שלבים, מה נעשה בצד הפורטל, מה בצד האתר ואיפה יידרש שיתוף הפעולה שלכם. אם חלק מהנתונים חסר, נתחיל ממה שיש ונשלים את השאר תוך כדי.