חיבור SIP trunk ל-Bitrix24: הוראות והגדרה

טראנק SIP ב-Bitrix24: מדוע הולכות לאיבוד שיחות במחלקת המכירות

תקלה טיפוסית נראית כך: טראנק SIP ב-Bitrix24 מחובר, השיחות עוברות, אך בכרטיסי הלקוחות הן לא מופיעות. המנהל מקבל את השיחה לטלפון האישי, שיחות שלא נענו לא נרשמות לאף אחד כאחראי, והמשפך מתמלא רק במה שמוכר הזין ביד לאחר השיחה.

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

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

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

מה נותן חיבור הטלפוניה לכרטיסי הלקוחות

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

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

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

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

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

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

אפשרויות חיבור טראנק SIP ל-Bitrix24 ומגבלותיהן

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

מה לבדוק לפני החיבור

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

שלבי הטמעת הטלפוניה: מהאודיט ועד למסירה לתפעול

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

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

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

3. כללי חלוקת השיחות. תורים ועדיפויות, היגיון „מי שפנוי — אליו נכנסת השיחה", מגבלת זמן המתנה, העברה למנהל במקרה של אי-מענה. כאן גם הקלטת השיחות ותקופת האחסון שלהן.

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

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

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

תצורות ניתוב, מדיניות גישה ותיעוד תפעולי

לאחר запуск של טראנק SIP אצל הלקוח צריך להישאר לא רק מספר עובד, אלא גם מערך של מסמכים שלפיו אפשר להעביר את המערכת למנהל אחר, להרחיב בלי לבנות מאפס או לבטל שינוי. להלן מה שנכלל באספקה בסיום העבודות.

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

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

מקרה בוחן: איך מחלקת המכירות הפסיקה לאבד שיחות נכנסות

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

מה שינו

חיבור הטלפוניה ל-Bitrix24 צומצם לשלושה צעדים: טראנק SIP נרשם בפורטל, המספרים חולקו לפי מחלקות ושעות עבודה, וחלוקת השיחות נבנתה על תור עם הכלל „קודם הפנוי, ועדיפות — למנהל שכבר טיפל בלקוח הזה".

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

מדדים לפני ואחרי

• שיעור השיחות שלא נענו: 31% → 4%;
• זמן המענה לפנייה מהמסנג'ר: 2-3 שעות → 10-12 דקות;
• שיעור השיחות עם הקלטה ושיוך לעסקה: כ-20% → 96%;
• העומס על הנציגים התאזן: הפער בין המנהלים הצטמצם בחצי, וחלק מהשיחות עבר לתור ולבחירה אוטומטית של אחראי.

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

במה טלפוניה בענן שונה ממרכזייה פרטית?

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

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

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

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

ספקות טכניים לפני חיבור הטלפוניה

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

מה יקרה אם ערוץ הקשר הראשי ייפול?

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

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

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

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

מי אחראי לקשר אחרי ההשקה?

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

נדון בתצורת השיחות שלכם ונחזור עם הערכת עלות

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

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

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