הגדרת IMAP/SMTP ל-Bitrix24: מסירת דואר וסנכרון

למה IMAP ב-Bitrix24 מאבד הודעות ומתפצל מהשרת

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

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

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

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

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

מה נותן חילופי הודעות מסודרים עם הפורטל

כאשר תיבה מחוברת ל-Bitrix24 ב-IMAP, והיוצאות עוברות דרך SMTP מאומת, כל הודעה משאירה עקבה ביומן המסירות: קוד תגובה של שרת הדואר של הנמען, סימון קריאה, סימן מענה ודוח שירות על אי-מסירה.

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

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

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

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

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

מצבי חיבור IMAP ב-Bitrix24 והמגבלות שלהם

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

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

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

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

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

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

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

סכימות ניתוב, הרשאות גישה ותקנונים

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

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

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

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

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

מערך כזה יצר רקע קבוע של אובדן: שיעור ההודעות שלא הגיעו לכרטיס החזיק סביב 6%, ופניות מסוג 'הלקוח כתב, אבל ההודעה לא נמצאת' תפסו לתמיכה 35–45 משימות בחודש. חיפוש התכתבות לפי ספק מסוים ארך 5–8 דקות — היה צריך להשוות ידנית כמה תיבות.

מה שינו

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

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

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

במה תיבה משותפת שונה מתיבה אישית ומה לבחור למחלקה

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

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

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

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

תקלות נפוצות במערך הדואר ודרכי הטיפול בהן

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

האחסון מפסיק את הסנכרון בגלל מגבלת חיבורים. איך לעקוף?

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

בתיבות הופיעו כפילויות של הודעות. מאיפה הן מגיעות?

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

האם היסטוריית ההתכתבות תישמר במעבר לסכימה חדשה?

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

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

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

כדאי לשלוח בערך את הדברים הבאים:

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

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