הגדרת דוחות Bitrix24: היכן האנליטיקה נשברת
הסיכום בדוח כמעט תמיד שונה ממה שהמנהלים רואים בכרטיסים. הסיבה אינה באנליטיקה של ה-CRM עצמה, אלא בנתונים שנכנסים אליה: המשפך הוגדר למכירות ולא לדיווח, והפער בעסקאות מצטבר חודשים, עד שמישהו משווה את הייצוא עם המרשם ידנית.
הראשון — שלבים לא סגורים. העסקה למעשה נסגרה, התשלום עבר, אבל הכרטיס נשאר ב'בעבודה' או בשלב סופי עם תאריך סגירה ריק. הדוח סופר עסקאות כאלה לפי השלב הנוכחי ולא לפי המצב בפועל, והמספר זז ברגע שהמנהל מתקן את הכרטיס בדיעבד.
השני — כפילויות. אותו לקוח נוצר שלוש פעמים: מהדואר, מטופס באתר, משיחה נכנסת. הסכומים מפוזרים על שלושה כרטיסים, ההמרה מחושבת בכל אחד בנפרד, והמשפך המסכם מציג צמיחה במקום שבו היה אותו איש קשר.
השלישי — שדות ללא חובת מילוי. מקור, סכום, אחראי, סיבת סירוב: אם הם לא חובה בשלב, חלק מהכרטיסים מגיעים עם ערכים ריקים. צבירה לפי שדה ריק חותכת סגמנטים שלמים, וקיבוץ 'לפי מקור' מפסיק לענות מאין הגיע הכסף.
הרביעי — ייצוא ידני. כל עוד הדיווח חי בטבלאות שכל אחד מנהל בדרכו שלו, אין תמונה אחודה: שני ייצואים לאותו תקופה לא תואמים זה לזה, וההשוואה דורשת מעבר שורה-שורה.
אנחנו מפרטים איך זה נסגר.
מה משתנה לאחר ההטמעה: אפקטים בגדלים מדידים
מקור אמת אחיד מסיר את הסיבה העיקרית לפערים: עסקאות, חשבוניות, לידים ומשימות נמצאים במתחם אחד של Bitrix24, והדוח נבנה ישירות על השדות האלה — מקור, אחראי, שלב, סכום, תאריך הצעד הבא. ייצוא ידני לטבלאות, שמהן נאסף קודם הסיכום, מפסיק להשתתף בתהליך.
התאמת הנתונים הופכת לניתנת לבדיקה. המספר בסיכום והמספר בכרטיס הלקוח מחושבים מאותה קבוצת רשומות, ולכן סוג השגיאה 'בדוח 40 עסקאות, ב-CRM 37' נעלם — הפער נשאר רק במקום שבו השדה מולא לא נכון, וזה נראה מיד בדוח איכות המילוי.
זמן הכנת הסיכום יורד מכמה שעות לדקות: המנהל לא מאחד קבצים, אלא פותח פאנל עם מסננים לפי משפך, תחום ותקופה. דוחות קבועים נשלחים לפי לוח זמנים לצ'אט או לדואר, ולכן ישיבת הצוות מתחילה בדיון בסטיות ולא בהשוואת מספרים.
הסטייה מהתוכנית נראית ביום שבו המשפך צנח, ולא בסוף החודש. חתכים נפרדים מציגים עסקאות בלי אחראי, שלבים בלי צעד הבא ומשימות תקועות — סוג שגיאות כזה התגלה קודם רק בניתוח עסקאות שכבר הוחמצו.
אפשרויות בניית אנליטיקה: השוואת גישות
האפשרות נבחרת לא לפי נוחות הממשק, אלא לפי שלוש שאלות: האם האנליטיקה נדרשת ברגע הצפייה או שמספיק חתך קבוע, האם נדרשת היסטוריה מעבר למאגר הנוכחי וכמה אנשים עובדים עם הדוח בו-זמנית. מכאן נגזרים גם הדרישות לדיוק הנתונים וגם עלות התמיכה בפתרון.
בפועל לרוב משלבים בין הגישות: דשבורדים מובנים מכסים את העבודה היומיומית של המחלקה, ואנליטיקה מסכמת על פני שנים עוברת לויטרינה חיצונית, שאליה הלוגיקה של ה-CRM כבר לא מגיעה. להלן אפשרויות אמיתיות שצריך לבחור ביניהן, והגבולות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| דשבורדים מוכנים של CRM | עבודה שוטפת של המחלקה: משפך, פעילות, המרה לפי שלבים, עומס על העובדים | מציגים נתונים במסגרת הרשאות המשתמש; סט החתכים והתקופות המצטברות נקבע על ידי לוגיקת המערכת ואינו מתרחב |
| דוחות מותאמים אישית של הבונה | נדרשים שדות משלכם, קיבוצים ועמודות מחושבות, דוח לצוות או לתחום אחד | בקשרים מורכבים בין ישויות השאילתה מאטה, וחלק מההיסטוריה ומרשומות מחוקות לא נכנס לדוח |
| ויטרינת נתונים חיצונית | אנליטיקה לתקופה ארוכה, סיכום ממספר מקורות, כלים אנליטיים חיצוניים משלכם | דורשת ייצוא קבוע, סכמת עדכון וכללי השוואה — אחרת המספרים לא תואמים ל-CRM |
| סיכומים לפי נוהל | למנהל נדרש חתך קבוע לדואר או לצ'אט בלי להיכנס למערכת | זה צילום מצב בזמן השליחה: הפירוט מוגבל, ואי אפשר לעבור מהסיכום לרשומות המקור |
את נקודת ההסתעפות קובעים בסקר: סופרים את עומק ההיסטוריה, רשימת החתכים הנדרשים, מספר הצרכנים ותדירות עדכון הנתונים. אחרי זה רואים היכן מספיקות הגדרות בתוך המערכת, והיכן נדרשת ויטרינה נפרדת עם נוהל עדכון והשוואה.
שלבי העבודה: מביקורת נתונים ועד מסירת נהלים
סדר העבודה קבוע: כל עוד המקורות לא אוחדו וסכמת המדדים לא סוכמה, הדוחות נותנים מספרים יפים אך לא מהימנים. לכן הולכים מהנתונים לנהלים — כל שלב מסתיים בתוצר שאפשר לבדוק.
- ביקורת נתוני CRM. מפרקים אילו ישויות באמת נכתבות למערכת — עסקאות, לידים, שיחות, משימות — היכן יש כפילויות, שדות חובה ריקים ופערים בין הכרטיס להיסטוריה. בפלט — מפת מקורות עם רשימת השדות שממולאים.
- סכמת מדדים וספרי עזר. מסכמים מה נחשב המרה, מחזור עסקה והכנסה, איזה שלב נחשב מוצלח, איך נלקחות בחשבון החזרות. סיבות סירוב ומקורות מאחדים לספר עזר אחד — אחרת הקיבוץ מתפצל לעשרות וריאציות.
- הגדרת משפכים ושלבים. את השלבים בונים לפי לוגיקת המכירות, מגדירים שדות חובה במעבר ואוטומציות בשינוי שלב. רק אחרי זה המשפכים הופכים לברי השוואה בין מחלקות.
- הרשאות גישה. תפקידים ומחלקות קובעים את הנראות: מנהל רואה את המשפך שלו, מנהל מסחרי — את המסכם, מנהל מכירות — את העסקאות שלו. הגישה מוגדרת בכללים, לא בהסכמות.
- הרכבת דשבורדים. פאנלים מרכיבים בדוחות המובנים של Bitrix24 לשאלות קונקרטיות: דינמיקה לפי שבועות, מקורות, עסקאות תקועות, עומס על מנהל. כל דוח מקושר לתקופה ולמסננים, ולכן המספר משוחזר.
- בדיקת התאמה. משווים את הדוח לייצוא מלא ולדגימת עסקאות ידנית: פער גדול מהמותר — שגיאת מסנן או כפילות, ולא 'מאפיין של הדוח'.
- מסירת נהלים. מוסרים תיאור מדדים, כללי מילוי שדות, סדר עדכון ספרי עזר והוראות לדוחות חדשים — הצוות מנהל את המערכת בעצמו או מעביר לנו תמיכה.
מה נשאר אצלכם: דוחות, דשבורדים, תיעוד
דשבורד מוגדר בלי תיאור הוא קופסה שחורה: בתיקון הראשון של המשפך אף אחד לא זוכר מאין הגיע המספר ולמה הווידג'ט מחשב דווקא כך. לכן מוסרים לא דוחות בודדים, אלא ערכה שלפיה הצוות שלכם יוכל לשנות את האנליטיקה בעצמו, בלי לפנות אלינו.
- ערכת דשבורדים — משפך לפי שלבים, פעילות מנהלים, מקורות לידים, זמני סגירת עסקאות. כל אחד נבנה על שאילתות, ולא 'הכול יחד'.
- כרטיס מדדים — לכל ווידג'ט: מקור נתונים, נוסחת חישוב, מסננים וחריגים (עסקאות פנימיות, לידים לבדיקה), בעל המדד.
- תיאור ספרי העזר — אילו שדות חובה למילוי, אילו ערכים מותרים, איך מטפלים בריקים ובכפילויות.
- תפקידים ומדיניות גישה — מי רואה סכומים, מי רק את העסקאות שלו, מי מייצא נתונים. הרשאות ניתנות בקבוצות, לא ידנית לכל אחד.
- נוהל עדכון — לוח זמנים לחישוב מחדש, סדר פעולות בתקלת סנכרון, אחראי על השחזור.
- הוראות לעובדים — תרחישים קצרים: לראות את המדדים שלך, להחליף תקופה, להשוות את המספר לנתוני המקור.
הערכה סוגרת את הסיכון העיקרי באנליטיקה — תלות באדם אחד: אפשר להעביר את הדוחות לעובד חדש ולהרחיב אותם לתהליכים חדשים בלי לבנות הכול מחדש.
מקרה בוחן: התאמת הנתונים עלתה מ-60% ל-98%
הלקוח הגיע עם סימפטום שמוכר כמעט לכל חברה בצמיחה: את הסיכום להנהלה אספו ידנית מייצואים של שלוש מחלקות, והמספרים בו לא התיישבו בקביעות. כ-40% מהעסקאות נסגרו עם שדות מפתח ריקים — סכום, מקור פנייה, סיבת סירוב. התאמת הדוחות עמדה על 60%, והכנת סיכום אחד ארכה שני ימי עבודה.
מה שינו בקונפיגורציה
ב-Bitrix24 שדות מפתח הפכו לחובה בשלבי המשפך: בלי סכום ומקור עסקה לא עוברת לשלב הבא. ספרי העזר של סיבות סירוב ומקורות אוחדו לרשימה אחת, כדי שמחלקות לא ייצרו ניסוחים משלהן. המשפכים הופרדו לפי תחומים, וכללים אוטומטיים מציבים אחראי ותאריך מגע בעצמם.
מה קרה למדדים
שיעור העסקאות עם שדות לא מלאים ירד ל-2–3%, התאמת הדוחות עלתה מ-60% ל-98%, ופערים בין מחלקות הפסיקו להופיע. סוג השגיאה 'לכל מחלקה יש אמת משלה' נסגר. הסיכום נבנה בדוח מובנה לפי שלבים ומתעדכן לפי לוח זמנים — במקום יומיים מתקבלות כמה דקות.
המדדים לפני ואחרי מחזיקים מעמד כי השליטה מוטמעת בתהליך, ולא בדוח: בדיקת המילוי הפכה לחלק מהעסקה, ספר העזר האחיד — לחלק מהניהול, והפער נראה למנהל בפאנל ביום סגירת העסקה, ולא בסוף הרבעון.
במה שונה אנליטיקה מובנית מדשבורדים חיצוניים?
הדוחות המובנים של Bitrix24 מכסים את המעגל התפעולי: משפך לפי שלבים, המרה ביניהם, פיזור עסקאות לפי מנהלים ומקורות, דינמיקה בזמן אמת והרשאות גישה שעוברות בירושה מה-CRM. זה מספיק כל עוד השאלה היא 'כמה עסקאות נתקעו באישור'.
ברגע שהעסק שואל 'איזה ערוץ מביא לקוחות עם אורך החיים הגבוה ביותר', הכלים המובנים לא מספיקים: אין בהם חיבור לנתונים מחוץ ל-CRM ואין היסטוריית שינויים עמוקה.
ויטרינת נתונים נדרשת כשהאנליטיקה דורשת לאחד CRM עם חיוב, מחסן, טלפוניה וחשבונות פרסום, וכן לשמור היסטוריית תיקונים לפי שדות, ולא רק מצב סופי. הטריגר השני — עומס: שאילתות כבדות לתקופה ארוכה מתחילות להתחרות בעבודה של המנהלים, ומעבירים אותן לעותק נפרד של בסיס הנתונים.
מבחינה טכנית זה נראה כך: ישויות מיוצאות באופן אינקרמנטלי לפי תאריך שינוי, ספרי העזר מנורמלים, ומעליהם נבנית שכבת ויטרינות שאליה מתחבר דשבורד חיצוני. העדכון נע בין דקות בודדות ליממה — תלוי אם נדרשות החלטות על עסקאות חמות.
מה הויטרינה לא עושה: לא מחליפה דוחות תפעוליים שעובד אמור לקבל בלחיצה אחת, ולא מתקנת את איכות הנתונים. אם שלבים מוחלפים לא לפי נוהל, כל אנליטיקה חיצונית תציג את אותה אי-אמת, רק בגדול יותר. לכן בחירת הגישה מתחילה מרשימת השאלות שצריך לענות עליהן מדי יום, ולא מהיקף הנתונים שנצברו.
ספקות טכניים: הרשאות גישה, משפכים, אינטגרציות
ספקות בנוגע לדוחות רק לעיתים נדירות נוגעים למספרים עצמם — לרוב הם נתקלים בהרשאות, במבנה המשפכים ובנתונים שחיים מחוץ ל-CRM. להלן ארבע שאלות הנדסיות שאנחנו מסירים לפני תחילת ההגדרה, כדי לא לשנות אחר כך את לוגיקת השאילתות ולא לשבור טפסים שכבר נבנו.
איך מחלקים הרשאות גישה בדוחות?
ההרשאות עוברות בירושה מתפקידי המשתמשים ב-Bitrix24, ולא מוגדרות מחדש בדוח. מנהל מכירות רואה את העסקאות שלו, ראש תחום — את כל המשפך שלו, אנליטיקאי מקבל גישה לקריאה בלבד, בלי זכות לערוך כרטיסים. הדוח נבנה כחתך לפי תפקיד, ולכן עובד חדש נכנס אוטומטית לנראות הנכונה.
יש לנו כמה משפכים ותחומים — הם יתאחדו לתמונה אחת?
משפכים הם ישויות נפרדות עם סט שלבים משלהן, ודוח מסכם פשוט עליהם ייצור עיוות. לכן קודם בונים ספר עזר להתאמת שלבים: שלבים כמו 'אושר' ו'חוזה נחתם' מאחדים לפי משמעות, ולא לפי שם. אחרי זה אפשר לראות גם את התמונה הכללית של החברה וגם חתכים נפרדים לכל תחום.
חלק מהנתונים מנוהלים מחוץ למערכת — אפשר לקחת אותם בחשבון?
כן, דרך ממשק התוכנה המובנה של הפלטפורמה או ייצוא קבוע ממקור חיצוני. חשוב לקבוע מראש איזה מקור נחשב ראשי: אם שיחות והתכתבות מגיעות מטלפוניה ודואר, והסכומים — ממערכת הנהלת חשבונות, אז במקרה של פער הדוח צריך להישען על צד אחד. מזה תלויה תדירות העדכון וכמה מספרים טריים יראה המנהל.
האם הגדרת הדוחות לא תשבור אינטגרציות קיימות?
לא: שאילתת הנתונים היא לקריאה, החלפה בין מערכות לא משתנה, וההרשאות ניתנות למשתמש שירות נפרד. אם לפי תוצאות האנליטיקה צריך לכתוב נתונים בחזרה, למשל להחליף שלבים אוטומטית, שינויים כאלה נסכם בנפרד ונבדוק על עותק לפני הפעלה במתחם העבודה.
נדבר על המשימה שלכם: נחזור עם הערכה ותוכנית
כדי שהשיחה תהיה עניינית ולא סקירה כללית, אנחנו מחזיקים בסדר ניתוח כזה: קודם קובעים מאין מגיעים הנתונים ומה כבר קיים ב-CRM, ואחר כך — אילו מדדים באמת משפיעים על החלטות. להלן שאלות שננתח בפגישה הראשונה; התשובות עליהן הן הכניסה להערכה ולתוכנית העבודה.
- מקורות: אילו משפכים, ערוצים, טפסים, טלפוניה ודואר כבר כותבים ל-CRM, והיכן החשבונאות מנוהלת ידנית או בטבלאות חיצוניות.
- מדדים: מה צריך לראות כדי להחליט — המרה לפי שלבים, אורך עסקה, סיבות סירוב, עומס על מנהלים, מכירות חוזרות.
- חתכים: לפי מחלקות, סניפים, קבוצות מוצרים ומקורות — ובאילו מהם אין כרגע דוחות.
- תפקידים והרשאות: למי נראים המספרים המסכמים, למי רק העסקאות שלו, מי אחראי לנכונות הנתונים.
- פורמט הסיכומים: היכן הדוח צריך לחיות — בפאנל בתוך הכרטיס, במסך נפרד, בייצוא לפי לוח זמנים או במכתב למנהל.
- תדירות ועומק: עדכון תוך כדי תנועה או פעם ביממה, לאיזו תקופה נשמרת ההיסטוריה, האם נדרשים השוואות לקטע הקודם.
- מגבלות: מה לא מספק בדוחות הנוכחיים ולאיזה מועד נדרש תוצאה עובדת.
אחרי השיחה נשלח מפת מדדים עם קישור לשדות ה-CRM, רשימת התאמות (שדות, שלבים, הרשאות), הרכב הדוחות עם פריסות ותוכנית עבודה לפי שלבים. בהערכה ובתוכנית נציין אחראים וסדר בדיקה — אתם רואים איך מחושבים המספרים לפני שהסיכום יישלח למנהל. תארו את המשימה, ונחזור עם הערכה ותוכנית.