כרטיס שיחה ב-Bitrix24: היכן אובדים נתוני הלקוח
כרטיס שיחה ב-Bitrix24 הוא נקודת החיבור בין הטלפוניה לעסקה: לכאן מגיעים המספר, הקלטת השיחה, האחראי והתוצאה. כאשר החיבור מוגדר לפי העיקרון של «העיקר שהשיחה תוצג», אובדן נתוני השיחות מתחיל כבר בשלב הראשון — ושם מבחין בו לא המהנדס, אלא המנהל: המשפך אינו מתיישב עם מספר הפניות בפועל.
המקום הראשון של הפער — התאמת המספר. הלקוח רשום בפורמט אחד, המרכזייה מעבירה את המספר בפורמט אחר, על מספר אחד תלויים כמה אנשי קשר, מתווספות קידומות של טלפון קווי — והשיחה נשארת ללא שיוך. במערכת לא נוצרים לא ליד ולא משימה לחזרה טלפונית: פניות שהוחמצו פשוט אינן קיימות בדיווח.
השני — שדות עסקה שלא מולאו. המנהל לאחר השיחה מציין ידנית את השלב, המקור, ההערה והסכום, ובזרימה עושה זאת באופן חלקי: חלק מהשדות ריק, חלק הוזנו מאוחר יותר ולא במדויק. הקלטת השיחה במקרה כזה נמצאת בנפרד מהכרטיס, ולכן כאשר מעבירים את הלקוח למנהל אחר, ההקשר אינו נקרא.
השלישי — העברה ידנית וכפילויות. הנתונים מועתקים לטבלאות חיצוניות, שיחה חוזרת פותחת כרטיס שני, והאחראי בליד ובעסקה אינו תואם. כך הפער בין הטלפוניה לעסקה הופך לתמונה מעוותת של הפניות: חלקן אינו נספר, המקור מיוחס באופן שגוי, וההמרה לפי ערוצים מנופחת. נבחן כיצד סוגרים זאת באמצעות הגדרה.
אפקט מדיד: מהירות הטיפול ומלאות השדות
אין טעם להשוות את המדדים בסעיף זה ללא קו בסיס, ולכן לפני ההגדרה אנחנו מבצעים מדידות של המשפך הנוכחי: חציון הזמן מרגע קבלת השיחה ועד להופעת העסקה, שיעור הכרטיסים עם שדות חובה ריקים, ומספר הפעולות שהמפעיל מבצע ידנית לאחר השיחה.
המדידות נלקחות מדוחות מובנים ומייצוא יומן השיחות של Bitrix24, וחוזרות לאחר שניים עד ארבעה שבועות מההטמעה — אחרת הצמיחה נראית כמו תחושה, ולא כמו עובדה.
מהירות הטיפול בפנייה משתנה בזכות הניתוב בצד הטלפוניה: העסקה נוצרת ברגע המענה, והאחראי והמקור מוצבים על ידי כלל, ולא על ידי המפעיל. ההמתנה ליצירה ידנית של כרטיס נעלמת, והזמן עד למגע הראשון במערכת יורד מעשרות דקות ליחידות בודדות.
מלאות הנתונים בעסקה נשענת על שדות חובה הקשורים לתוצאת השיחה: הסיכום, סיבת הסירוב ותגית המקור מועברים אוטומטית מכרטיס השיחה אל העסקה. שיעור העסקאות עם מערך שדות מלא עולה ל-90–100% במקומות שבהם קודם לכן מחצית מהכרטיסים נותרו עם מקור ריק וסיכום שלא מולא.
הסרת הפעולות הידניות ניכרת במספר המגעים: העתקת מספר, חיפוש הלקוח במאגר ושיוך ידני של ההקלטה לעסקה מוחלפים בכללים. בקרת האיכות של עבודת המחלקה עוברת מהאזנה גורפת לבדיקה מדגמית לפי מסננים — בודקים שיחות עם הפסקות ארוכות או ללא סיכום, וכיסוי הבדיקה גדל באותו כוח אדם.
תרחיש מובנה, פיתוח מודול או אינטגרציה חיצונית
כרטיס השיחה ב-Bitrix24 הוא הנקודה שבה נפגשים הקלטת השיחה, השיוך לעסקה, האחראי והתזכורות. השדות המובנים והניתוב לא תמיד מספיקים, אך לפני שכותבים מודול משלנו, אנחנו בודקים מה בדיוק חסר: שדות נוספים, לוגיקה לאחר השיחה או חילופי נתונים עם מערכת חיצונית.
שלוש הגישות נבדלות זו מזו במידת העומק שבה השינוי חודר לפלטפורמה, ובמה שיקרה לו בעת עדכון.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| הגדרה מובנית של הכרטיס | שדות טיפוסיים, הרשאות גישה וניתוב סוגרים את המשימה | לא ניתן לשנות את סדר הבלוקים ואת לוגיקת השמירה, ולא להוסיף בדיקות וחישובים משלנו |
| פיתוח מודול | נדרשים שדות משלנו עם חישובים, פעולות לאחר השיחה, נראות לפי מחלקות | את השינוי יש לתחזק: לאחר עדכון הפלטפורמה חובה לבדוק את התרחישים |
| אינטגרציה חיצונית של הטלפוניה | ההקלטה, התמלול וההערכה חיים במערכת חיצונית, ואל הכרטיס חוזרים התוצאה והקישור | עיכוב בהופעת הנתונים, תלות בזמינות השירות החיצוני, וחלק מהפעולות זמינות רק בצד שלו |
כיצד בוחרים גישה
הסדר הוא בדרך כלל כזה: קודם מנסים לסגור את המשימה בהגדרות מובנות, אחר כך מוסיפים שדות ותרחישים בתוך הפלטפורמה, ורק את חילופי הנתונים עם מערכת חיצונית מוציאים החוצה. כלל שמשתנה כל חודש זול יותר להחזיק מחוץ למודול — השינויים אינם מחייבים עדכון קוד.
במקומות שבהם חשובה מהירות התגובה בתוך הממשק עצמו, את הלוגיקה משאירים בפנים. בפועל עובדת לרוב שילוב: את הכרטיס מפתחים, ואת אחסון ההקלטות וניתוח השיחות מוסרים לשירות חיצוני, כדי שעדכוני הפלטפורמה יעברו בלי לכתוב מחדש.
כיצד מגדירים תרחיש שיחה: שלבי ההטמעה
שלבי ההטמעה נבנים מהתהליך, ולא מההגדרות: כל עוד לא נקבע אילו שיחות קיימות ומה צריך לראות בכל אחת מהן, כרטיס השיחה ב-Bitrix24 הופך למערך שדות בלי לוגיקה. להלן רצף העבודות שלאחריו ניתן למסור את התרחיש לתפעול.
-
פירוק התהליך. מבררים אילו פניות עוברות דרך הטלפוניה, מי מטפל בהן והיכן אובד המידע: שיחה שהוחמצה, העברה לשלוחה, פנייה חוזרת. התוצאה — מפת תרחישים עם תפקידי המשתתפים.
-
תכנון התרחיש. קובעים את הרכב הכרטיס: ערוץ, אחראי, מקור, הקלטת השיחה, סיכום. חלק מהשדות נמשכים מהטלפוניה, וחלק ממולאים ידנית לפי נוהל — ומתעדים מה בדיוק ועל ידי מי.
-
הגדרת שדות והרשאות. פותחים שדות ומחלקים את הגישה לפי תפקידים ומחלקות: העובד רואה את השיחות שלו, המנהל — את כל המחלקה, ויחידות סמוכות — בלי ההקלטות. בנפרד בודקים את הדוחות והייצוא, כדי שלא לעקוף את ההרשאות שלא דרך הכרטיס.
-
אוטומציה. מקשרים כללים ורובוטים: יצירת משימה לאחר השיחה, תזכורת במקרה של שיחה שהוחמצה, השלמת נתונים לעסקה או לאיש קשר, והתראה למנהל לפי סימנים מוגדרים.
-
בדיקת התרחיש. מריצים מצבים טיפוסיים ומצבי גבול על קו בדיקה: שיחה נכנסת, שיחה שהוחמצה, העברה, מספר לא מוכר, ניתוק הקשר. בודקים שהשדות מתמלאים, שהכללים פועלים ושאין התנגשות בין ההרשאות.
-
מסירה לתפעול. מוסרים את תרשים התרחיש, את רשימת השדות וההרשאות, הנחיות למנהל המערכת ולעובדים, ואת נוהל השינויים. בשבועות הראשונים מלווים ומתקנים את מה שהמציאות חשפה.
ערכת מסירה: תרשים, הרשאות גישה, נהלים
תרחיש כרטיס השיחה חי יותר מהפרויקט: מתווספים קווים ומשפכים חדשים, משתנה הרכב המחלקה, ומתחברים ערוצים. כדי שכל שינוי כזה לא יהפוך לפנייה אלינו, ערכת המסירה נבנית כך שהתשובה לשאלה «מדוע השיחה לא שויכה לעסקה» תימצא במסמך. הנה מה שנשאר אצל המזמין לאחר מסירת העבודות ב-Bitrix24.
- תרשים האינטגרציות — אילו שירותים משתתפים בעיבוד השיחה, היכן מקור האמת לגבי הלקוח, באיזה סדר הנתונים מגיעים לכרטיס ומה מקשר בינו לבין העסקה והאחראי.
- כללי גישה — מטריצת תפקידים: המפעיל רואה את השיחות שלו, מנהל המחלקה — את המחלקה שלו, מנהל המערכת — הגדרות והיסטוריה. בנפרד מצוין אילו שדות מותר לערוך ואילו סגורים, כדי שהלוגיקה לא תתפרק.
- נוהל עבודת המפעיל — מה עושים עם שיחה שהוחמצה, באיזה רגע מתעדים את סיכום השיחה, אילו שדות הם חובה עד סגירת הכרטיס ולאן להסלים אי-התאמה.
- תיעוד ההגדרה — מפת השדות של הכרטיס, תנאי האוטומציות וסדר הפעולות בעת הוספת קו או משפך חדש, כדי שאפשר יהיה לבצע שינוי בלי לפרק את כל התצורה.
- מדריך לעובדים — עמוד אחד עד שניים, עם צילומי מסך ומצבים טיפוסיים: כיצד לקבל שיחה, כיצד למלא את הכרטיס, ומה אין צורך לעשות.
- יומן שינויים ונקודות שחזור — מה ומתי השתנה בהגדרות וכיצד להשיב את הלוגיקה הקודמת, אם לאחר השינוי השיחות הפסיקו להיות מנותבות.
- רשימת בדיקות — מערך תרחישים (שיחה נכנסת, שיחה שהוחמצה, העברה, שיחה חוזרת), שלפיו מריצים את התרחיש לאחר כל שינוי, ולא רק ביום המסירה.
מקרה בוחן: צמצמנו את הפעולות הידניות ואת אובדן הפניות בחצי
מחלקת מכירות של כמה עשרות עובדים עבדה עם טלפוניה ב-Bitrix24, אבל כרטיס השיחה נשאר פורמליות: את סיכום השיחה רשמו מהזיכרון, חלק מההקלטות לא שויכו לעסקה, ואת הצעד הבא המנהל קבע ידנית, ולא תמיד.
לפי מדגם של כמה אלפי שיחות בחודש, כמעט מחצית מהפניות נותרו בלי תוצאה מתועדת — לא היה במה להעביר לקוח לעמית או לבחון עסקה שנויה במחלוקת.
שינינו את המכניקה של הכרטיס, ולא את המשמעת באמצעות הוראות. סיכום השיחה הפך לחובה בעת הסגירה, סוג הפנייה מציב מערך שדות משלו, המספר והאחראי נקבעים אוטומטית לפי הקו, וההקלטה נשמרת בעסקה יחד עם התמלול. שמירת הכרטיס יוצרת משימה לצעד הבא עם תאריך, ולכן ההזנה החוזרת בין הטלפוניה לעסקה נעלמה.
| מדד | לפני | אחרי |
|---|---|---|
| שיחות עם סיכום שיחה מלא | 46% | 97% |
| פניות ללא עסקה וללא אחראי | 11% | 5% |
| פעולות של המנהל לשיחה אחת | 6 | 2 |
| הפער בין השיחה למשימת הצעד הבא | שעות | דקות |
מה זה נתן במספרים
משמעת המילוי הפסיקה להיות תלויה במשמרת ובעומס: אי אפשר לסגור כרטיס בלי סיכום, ולכן אין יותר רשומות ריקות בדוח של המנהל. אובדן הפניות ירד בחצי — כל שיחה או שהופכת לעסקה, או שנשארת בהיסטוריה עם סיבת הסירוב.
במה שונה תרחיש מובנה מפיתוח המותאם לתהליך?
התרחיש המובנה של כרטיס השיחה סוגר את המערך הבסיסי: המספר נמשך מהטלפוניה, אליו משויכת ההקלטה, נוצר ליד או עסקה, והאחראי מקבל התראה. שדות, בלוקים וסדר הצגתם מוגדרים ישירות בכרטיס, והלוגיקה שלאחר השיחה נבנית מרובוטים וטריגרים מובנים. זה מספיק כשתהליך המכירות טיפוסי: משפך אחד, מחלקה אחת, ומערך נתונים קבוע למיון ראשוני.
פיתוח המותאם לתהליך נדרש כשהלוגיקה נתקלת במגבלות של ההגדרות: שדות משלנו עם חישוב לפי כללים פנימיים, מערכי נתונים שונים לכיוונים שונים, הרשאות נפרדות להאזנה להקלטה, ויצירה אוטומטית של בקשה במערכת חיצונית לפי תוצאות השיחה. הסימן פשוט — התהליך מתואר בתנאים של «אם ..., אז ...», ותנאים אלה אינם ניתנים לביטוי בכלים המובנים.
לוחות הזמנים של הפיתוח תלויים במספר התנאים הללו ובמידת העומק של הקישורים עם מערכות הרישום. הגדרת שדות והרשאות — ימים; לוגיקה משלנו וחילופי נתונים — שבועות, יחד עם סקר, הרכבה בפורטל בדיקה, העברה ובדיקה על שיחות אמיתיות.
הסיכונים של הפיתוח צפויים: עדכוני הפלטפורמה עלולים לפגוע בקוד לא תקני, ובלי תיעוד התמיכה הופכת לארכיאולוגיה.
אנחנו מסירים זאת בכך שאיננו נוגעים בליבה — מרחיבים דרך נקודות החיבור המובנות, מחזיקים את השינויים בשכבה נפרדת, מריצים בדיקת רגרסיה לאחר כל עדכון, ומוסרים את תרשים הלוגיקה יחד עם ההרשאות. אז התרחיש שורד את העדכונים ונשאר בר-ניהול.
שאלות נפוצות על אינטגרציות, הרשאות ועדכונים
לפני תחילת העבודות החששות של המזמין הם בדרך כלל מאותו סוג: האם הפיתוח לא ישבור את הטלפוניה שכבר הוגדרה, כיצד לחלק את ההרשאות בין המחלקות, ומה יקרה לאחר עדכון מערכת נוסף. להלן השאלות שנשאלות בתדירות הגבוהה ביותר, עם תשובות לגופן.
כרטיס השיחה הוא תוספת מעל המנגנון המובנה של השיחות: שיוך לישויות, שדות משלנו, הרשאות ותגובות לאירועים. אנחנו משתלבים באותן נקודות הרחבה מובנות, ולא כותבים מחדש את הליבה, ולכן התנהגות השיחות נשארת כשהייתה, והפיתוח שורד את העדכונים.
האם הפיתוח יתאים לטלפוניה שלנו?
קודם כל מתעדים את התרשים: כיצד מגיעים אירועי השיחות, היכן נשמרות ההקלטות, ואילו שדות כבר מתמלאים. הפיתוח מתחבר לאותם אירועים, ולכן הניתוב וההתראות אינם משתנים. אם הטלפוניה אינה תקנית, מתארים את המגבלות לפני תחילת העבודות, ולא אחריהן.
כיצד לתוחם הרשאות כך שהמנהל לא יראה דברים מיותרים?
ההרשאות יורשות מהתפקידים ומשויכות לישויות. בונים מטריצת גישה: מי פותח את הכרטיס במלואו, מי רואה רק את השיחות שלו, ומי בעל גישה להקלטות השיחות. כל תפקיד נבדק על משתמשים אמיתיים, ולא רק בהגדרות.
מה יקרה לאחר עדכון המערכת?
הפיתוח אינו נוגע בליבה, ולכן העדכון אינו מוחק את השינויים. לפני העדכון מריצים בדיקה על עותק: בודקים שהשדות, ההרשאות והשיוכים של השיחות פועלים כמו קודם. אם העדכון משנה מודול סמוך, מתאימים את הפיתוח לפני העלאה לסביבת העבודה.
האם היסטוריית השיחות וההקלטות יישמרו?
הנתונים נשארים במאגר המובנה, והפיתוח רק מציג ומקשר אותם. מגדירים את תקופות השמירה ואת סדר המחיקה, כדי שההיסטוריה תהיה זמינה בדיוק כל עוד נדרש לפי הנוהל. לפני ההעברה מבצעים גיבוי ובודקים את השחזור, כדי שהחזרה לאחור תהיה צפויה.
מה כלול בליווי לאחר המסירה?
עוקבים אחר עיבוד אירועי השיחות, מגיבים לשינויים בצד הטלפוניה ובודקים את הפעילות לאחר עדכוני המערכת. בנוסף, ייעוץ להרחבת הלוגיקה — כשמתווספות מחלקות או תרחישים חדשים.
נדון במשימה שלכם: נחזור עם הערכה ותוכנית
כדי שהבחינה תהיה עניינית, די לשלוח את תרחיש עיבוד השיחה: אילו שדות בכרטיס מתמלאים אוטומטית, אילו המפעיל מזין ידנית, ומה צריך לעבור למערכת הרישום לאחר השיחה. הוסיפו צילום מסך של הכרטיס הנוכחי, דוגמת ייצוא ותיאור התפקידים — מי רואה את ההקלטה, מי משנה שדות, ומי סוגר את העסקה.
הדיון במשימה מתנהל בשיחה עניינית אחת: מנתחים את זרימת השיחות, בודקים את הרשאות הגישה ואת הקשרים בין הישויות, ורואים באיזה שלב אובדים הנתונים. לאחר מכן חוזרים עם הערכה ותוכנית הטמעה — מה עושים בשלב הראשון ומה עובר לשני.
בסיכום תקבלו:
- פירוט העבודות לפי סעיפים: אילו בלוקים ושדות בכרטיס מגדירים, אילו תרחישים מאוטומטים, ואילו קישורים למערכת הרישום מרימים;
- סדר השלבים: הכנת סביבת בדיקה, הגדרה, בדיקה על שיחות אמיתיות, והעלאה לפורטל העבודה;
- תרשים מסירת התוצאה — תצורות, נוהל מילוי, הנחיות למפעילים ולמנהלי מערכת;
- דרישות להרשאות ולתפקידים הנדרשים מכם כדי להתחיל;
- קריטריוני קבלה: כיצד משתכנעים שהכרטיס מתמלא כראוי והנתונים מגיעים לרישום;
- רשימת פיתוחים שנכון לדחות לשלב הבא.
תארו את המשימה בצורה חופשית — נחזור עם הערכה, לוחות זמנים וסדר העבודות.