תוסף AI ל-Bitrix24: אוטומציה של CRM באמצעות רשתות נוירונים

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

תוסף AI ל-Bitrix24: היכן נשברת אוטומציית CRM

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

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

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

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

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

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

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

מה נותנת אוטומציית CRM עם רשתות נוירונים: אפקט מדיד

מהירות תגובה: דקות במקום שעות

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

שיעור הפעולות הידניות יורד

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

איכות הנתונים ב-CRM

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

סוג תקלות שהוסר

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

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

אפשרויות חיבור: מודול מובנה, שירות חיצוני, היברידי

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

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

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

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

שלבי הטמעה: מביקורת המשפך ועד מסירה לתמיכה

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

  1. ביקורת המשפך. אנו בוחנים כיצד ב-Bitrix24 שלבים באמת בנויים, אילו שדות מתמלאים, היכן פניות תלויות ללא תשובה ומה יש בהיסטוריה. בפלט — מפת התהליך ורשימת מקומות שבהם האוטומציה נותנת אפקט, והיכן היא רק תוסיף רעש.
  2. סכמת עיבוד פניות. אנו מחלקים את הלוגיקה: מה פותרת רשת הנוירונים (סיווג, טיוטת תשובה, חילוץ שדות), מה — כללים נוקשים, ומה נשאר לאדם. בנפרד מתעדים את ההתנהגות כאשר השירות החיצוני אינו זמין — הפנייה אינה הולכת לאיבוד בכל מקרה.
  3. הגדרת תרחישים. אנו מחברים את המודל לשדות ולשלבים, מגדירים רובוטים וטריגרים, מפרידים הרשאות ומגבלות בקשות. מתעדים אילו נתונים יוצאים למודל ואילו אינם יוצאים מהמתחם.
  4. בדיקה על נתונים היסטוריים. אנו מריצים תרחישים על עסקאות סגורות ומשווים את התוצאה למה שהמנהלים עשו בפועל. מחשבים שיעור התאמות, התראות שווא וזמן עיבוד — לפני הפעלה על זרימה חיה.
  5. פיילוט בקטע מוגבל. מפעילים במחלקה אחת או בחלק מהמשפך, ולפי פניות אמיתיות מתקנים ספים, עדיפויות וניסוחים.
  6. קבלה. בודקים מול קריטריונים מוסכמים: איזה שיעור פניות עובר ללא אדם, בכמה התקצר זמן התשובה הראשונה, איזה שיעור שגיאות סיווג מותר.
  7. מסירה לתמיכה. מוסרים תיעוד של תרחישים ושדות, נוהל שינויים, ניטור וסדר נסיגה — ניתן לתקן את הלוגיקה ללא מעורבותנו.

מה מוסרים לידיים: קונפיגורציות, סכמות, נהלים

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

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

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

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

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

נקודת התחלה

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

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

מה שינינו

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

מה קרה

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

במה שונה מודול חיצוני מכללי אוטומציה ב-Bitrix24?

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

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

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

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

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

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

ספקות טכניים: עומס, נתונים, אימון נוסף

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

האם העיבוד יעמוד בעומס שיא?

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

מה קורה כאשר השירות החיצוני נכשל?

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

היכן נשמרת ההתכתבות ולמי יש גישה אליה?

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

איזה נפח נתונים נדרש לאימון נוסף של המודל?

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

כיצד לבצע נסיגה אם הכללים החדשים הרעו את העבודה?

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

נדון במשימה: משפך, נתונים, תרחישי עיבוד

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

אם אתם מוכנים לדון ענייני, שלחו:

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

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