התראות משלוח ב-1C-Bitrix: היכן נשברת השרשרת
התראות משלוח ב-1C-Bitrix נשברות לא ברגע שליחת המייל, אלא קודם לכן — במעבר סטטוס ההזמנה. הלקוח מבצע רכישה, התשלום עובר, אך הסטטוס נשאר כשהיה: מטפל האירוע לא הופעל, תור ההודעות נעצר, ותבנית המייל לא קיבלה נתונים להצבה. מבחוץ זה שקט בתיבה, מבפנים — שרשרת משלוח קרועה, שבה השלב הבא פשוט לא מופעל.
בהמשך התקלה מצטברת. המייל נשלח, אך נופל לספאם: הדומיין אינו חתום, כתובת החזרה אינה תואמת לשולח, התבנית מורכבת מתמונות אינ�ליין ומקשרים לאחסון חיצוני. הלקוח אינו רואה לא מספר מעקב ולא תאריך העברה — ומתקשר לתמיכה, אף שההזמנה כבר בדרך.
סיפור נפרד — שינוי סטטוס ידני: המנהל מעביר את המשלוח בפאנל, אך ההתראה אינה יוצאת, כי הטריגר קשור למעבר אוטומטי ולא לעובדת השינוי עצמה.
כשל שקט נוסף — אי-סנכרון בין המחסן לאתר. שירות השליחים החזיר סטטוס חדש, אך החלפת הנתונים לא עברה, ובאזור האישי תלוי "ממתין לשליחה", בעוד החבילה כבר בנקודת האיסוף. הלקוח לומד את האמת מהשליח, ולא מהחנות.
אנו מפרקים את השרשרת חוליה אחר חוליה: היכן אובד האירוע, מדוע התבנית אינה נבנית, מה מונע מהמייל להגיע. להלן — כיצד זה נסגר ברמת הסטטוסים, התבניות והערוצים.
מה נותנת אוטומציה מקצה לקצה של התראות
כאשר סטטוס ההזמנה משתנה, הלקוח לומד על כך בעצמו — מ-SMS, ממייל או מהודעה במסנג'ר, ולא משיחה לתמיכה. כל אירוע ב-1C-Bitrix — מסירה למשלוח, הגעה לנקודת איסוף, שליח בדרך, מסירה — מייצר אוטומטית הודעה לפי תבנית שנקבעה מראש. זה מסיר מהמנהלים את השגרה של «התקשרו ותבררו», ומעניק ללקוח שקיפות של סטטוסים בלי להמתין על הקו.
יומן שליחות אחיד מתעד כל הודעה: ערוץ, תבנית, זמן, תוצאת מסירה ותגובת הספק. אם הלקוח טוען שההתראה לא הגיעה, השאלה נסגרת תוך דקה — רואים אם ההודעה נשלחה, אם הגיעה ובאיזה סטטוס הופעלה. כך התמיכה מפסיקה להיות «טלפון שבור» בין הלקוח, המחסן ושירות המשלוחים.
פניות חוזרות לגבי אותה הזמנה מצטמצמות: הלקוח רואה את תנועת החבילה ולא מתקשר בפעם השלישית לברר היכן היא. העומס על הקו הראשון יורד — שאלות טיפוסיות כמו «איפה ההזמנה שלי» ו«מתי ימסרו» נסגרות אוטומטית, והמפעילים עוסקים במצבים לא שגרתיים.
השקיפות של הסטטוסים פועלת גם מבפנים: הלוגיסטיקה, המחסן והתמיכה מסתכלים על אותם נתונים, ולא משווים אותם ידנית.
נאמנות כאן היא תוצאה של צפיות. לקוח שמקבל בזמן התראה ברורה מבטל הזמנה לעתים רחוקות יותר וחוזר לעתים קרובות יותר, והמותג נתפס כמאורגן. היומן האחיד מספק גם בסיס לניתוח: רואים באיזה סטטוס הלקוחות הולכים לאיבוד לרוב ואיזה ערוץ התראות באמת נקרא.
כדי להעריך את האפקט עבור התהליך שלכם, צריך להסתכל על הסטטוסים הנוכחיים של ההזמנות ועל הנקודות שבהן הלקוחות מתקשרים לרוב. תארו את המשימה — נחזור עם הערכה ותוכנית אוטומציה.
ערוצי התראות על משלוח ב-1C-Bitrix: SMS, Email, Telegram
כל ערוץ ממלא תפקיד משלו: SMS משיג את המטרה היכן שאין אינטרנט, Email משאיר עקבות בתיבה, Telegram מספק תגובה מיידית וכפתורים. בפועל, השילוב העובד אינו "או-או", אלא ניתוב לפי אירוע: סטטוס הזמנה נשלח ל-Telegram, אבני דרך קריטיות משוכפלות ב-SMS, ומסמכי סגירה וקבלה — ב-Email.
| ערוץ | מתי מתאים | מגבלות |
|---|---|---|
| שער SMS | לקוח ללא אפליקציות מסרים, סטטוס דחוף "השליח בדלת", אימות קוד | תעבורה בתשלום, מגבלת אורך, אין כפתורים וקבצים מצורפים, נדרש ספק ומודרציה של חתימה |
| תפוצת Email | קבלה, תעודת משלוח, מספר מעקב, היסטוריית הזמנות | המייל בקלות נכנס לספאם, תגובה איטית, נדרשים דומיין, DKIM/SPF וחימום |
| בוט Telegram | סטטוסים מיידיים, כפתורי "מעקב", "חזור על הזמנה", צ'אט עם תמיכה | הלקוח חייב להפעיל את הבוט, נדרשים webhook וטיפול בחסימות |
עלות הבעלות אינה מורכבת מהתעריף, אלא מהתמיכה: שער SMS דורש חוזה ויתרה, Email — מוניטין דומיין וטיפול בהסרות מרשימת תפוצה, Telegram — webhook יציב ותור שליחה חוזרת.
לכן ב-1C-Bitrix הערוצים מחוברים דרך שכבת אירועים אחודה: שינוי סטטוס הזמנה מפעיל מטפל, והוא מחליט לאן ובאיזה השהיה לשלוח את ההתראה.
שכבה כזו מסירה את הכאב העיקרי — כפילויות ומיילים "נעלמים". אם Telegram אינו זמין, המשימה עוברת לתור ומבוצעת שוב, ולא הולכת לאיבוד; אם הלקוח הסיר את עצמו מ-Email, הסטטוס בכל זאת מגיע דרך ערוץ אחר. את בחירת השילוב מקבעים בשלב התכנון: מסתכלים על הקהל, הגיאוגרפיה ואילו אירועים קריטיים לעסק.
שלבי יישום: מביקורת אירועים ועד מסירת נהלים
יישום התראות משלוח אינו מתחיל מתבניות הודעות, אלא ממלאי אירועים: אילו סטטוסים של הזמנה משתנים ב-1С, אילו מהם משמעותיים ללקוח, ואילו הם שירותיים. בשלב זה מתעדים מהיכן מגיע כל אירוע — סנכרון עם 1С, שינוי סטטוס ב-Bitrix24, תגובת שירות המשלוחים — ואילו ערוצי התראות כבר פעילים. כך מתגלה היכן הלקוח מקבל כפילויות והיכן אינו מקבל דבר.
- ביקורת אירועים. אוספים רשימה מלאה של סטטוסי הזמנה ונקודות השינוי שלהם, מסמנים אילו אירועים כבר מייצרים התראות ואילו הולכים לאיבוד בסנכרון בין המערכות.
- תרשים טריגרים. בונים מפה "אירוע → נמען → ערוץ": אישור הזמנה, העברה למשלוח, הגעה לנקודת איסוף, מסירה. מסירים חפיפות כדי שהלקוח לא יקבל שתי הודעות על אותו שלב.
- הגדרת תבניות. מכינים טקסטים לכל ערוץ בנפרד: SMS קצר, הודעה עם מספר מעקב, הודעה במסנג'ר. מכניסים משתני הזמנה ובודקים את תקינות ההצבה בשדות ריקים.
- תרחישי בדיקה. מריצים את מסלול ההזמנה המלא על נתוני בדיקה: מהזמנה ועד מסירה, כולל ביטול והחזרה. בודקים משלוח כאשר אחד הערוצים אינו זמין — ההתראה צריכה להישלח בערוץ גיבוי.
- טיפול בשגיאות. מגדירים תיעוד רישום של שליחות וניסיונות חוזרים בעת כשל של שירות חיצוני, כדי שכשל בערוץ לא ישאיר את הלקוח ללא מידע על ההזמנה.
- נוהל תפעול. מוסרים מסמך: אילו אירועים מנוטרים, מי אחראי על הטקסטים, כיצד להוסיף סטטוס חדש והיכן לצפות בהיסטוריית השליחות.
- מסירה והדרכה. מראים לעובדים כיצד לבצע עריכות בתבניות ללא מפתח וכיצד לקרוא את יומן הכשלים.
לאחר מסירת הנוהל, צוות הלקוח מנהל באופן עצמאי את הטקסטים ומוסיף סטטוסים חדשים — ללא פנייה לפיתוח עבור כל שינוי.
ארטיפקטים של הפרויקט: תבניות, כללי ניתוב, יומן שליחות
לאחר ההטמעה נשאר אצל הלקוח סט מלא של ארטיפקטים — לא "אתר מוגדר", אלא מערכת עבירה של קונפיגורציות, כללים ותיעוד. כל מהנדס או מנהל מערכת יוכל לפרוס את לוגיקת ההתראות בסביבה אחרת, מבלי לשחזר אותה מהזיכרון. להלן — מה בדיוק אנו מוסרים.
- תבניות מכתבים והודעות — טקסטים עבור email, SMS ו-Telegram לפי כל סטטוס הזמנה, עם הצבת משתנים (מספר הזמנה, הרכב, מועד, מספר מעקב). נשמרות כתבניות נפרדות, ולא מוטבעות בקוד.
- כללי ניתוב — טבלת "אירוע → ערוץ → נמען → השהיה". מראה לאן נשלחת ההתראה בעת שינוי סטטוס, מי מקבל העתק ומה קורה במקרה של אי-מסירה.
- קונפיגורציית חיבורים — פרמטרים של שרת הדואר, שער ה-SMS והבוט, עם ציון אילו ערכים הועברו להגדרות וכיצד לשנותם ללא עריכת קוד.
- יומן שליחות — טבלה עם היסטוריה: תאריך, נמען, ערוץ, סטטוס מסירה, טקסט שגיאה. לפיה מנתחים תקלות ומאשרים את עצם ההתראה ללקוח.
- תרשים התהליך — מפה חזותית: משינוי סטטוס ההזמנה ועד למסירה בפועל של ההודעה, עם נקודות כשל וחזרות.
- הוראות למנהלים — כיצד להוסיף תבנית חדשה, להחליף ערוץ, לבדוק אם ההתראה נשלחה ללקוח מסוים.
- תקנון תפעול — מה לבדוק בעת תקלה, כיצד להפעיל מחדש את התור, לאן להסתכל ראשית.
כל ארטיפקט אנו מוסרים במצב עובד ועם הסבר לשם מה הוא נחוץ. בנפרד מתעדים אילו הגדרות הן קריטיות ומה אסור לשנות ללא תיאום — כדי שעריכות לא ישברו את הניתוב.
מקרה בוחן: כיצד התראות משלוח הפסיקו ללכת לאיבוד
הלקוח — חנות מקוונת עם משלוחים לאזורים שונים, ההזמנות עברו דרך 1C-Bitrix, והסטטוסים של המשלוח הוזנו ידנית על ידי המפעיל. ההתראות נשלחו בערוץ אחד ורק לכתובת דוא"ל: חלק מהמכתבים נפלו לספאם, וחלק — לכתובות לא מעודכנות.
שיעור ההתראות שנמסרו עמד על כ-60%, והתמיכה קיבלה מדי חודש למעלה מ-400 פניות בסגנון "איפה ההזמנה שלי".
מה שינו
קישרנו את אירועי שינוי הסטטוס של ההזמנה לתהליך עסקי ב-1С ובנינו מפל ערוצים: SMS כערוץ ראשי, דוא"ל כערוץ משלים, ומסנג'ר — עבור לקוחות שבחרו בו בעצמם בעת ביצוע ההזמנה.
כל משלוח קיבל יומן עם סטטוס המסירה וניסיון חוזר במקרה של כשל בשער, ותבניות ההודעות הועברו להגדרות ניתנות לעריכה, כדי שהשיווק יוכל לשנות את הנוסח בלי לגעת בקוד.
מה השתנה
שיעור ההתראות שנמסרו עלה מ-60% ל-96% — השפיעו מפל הערוצים והניסיון החוזר האוטומטי במקרה של תקלה. הפניות לתמיכה בנוגע לסטטוס ההזמנה ירדו ביותר מחצית, והעומס על המפעילים ירד עד כדי כך שהזמן שהתפנה הופנה להחזרות ולמכירות חוזרות.
נציין בנפרד את השקיפות: עבור כל הזמנה ניתן לראות איזו התראה נשלחה, מתי ובמה היא אושרה. אם הלקוח אומר "לא הגיע אליי כלום", המפעיל פותח את היומן ועונה על פי העובדות, ולא בניחוש.
1C-Bitrix שימש כאן כחוליה המקשרת בין הקטלוג, ההזמנות ושירות המשלוחים — לוגיקת ההתראות חיה בתוך אותה מערכת שבה מתנהלת החשבונאות, ולכן הסטטוסים אינם מתפצלים בין חלון הראווה לבין ה-back-office.
במה שונה מודל אירועים מסקר סטטוסים?
מודל אירועים מבוסס על כך שמקור שינוי הסטטוס עצמו מודיע עליו: מחסן, שירות משלוחים או מערכת חיצונית שולחים אירוע, והמטפל ב-1C-Bitrix מקבל אותו ומפעיל שרשרת התראות.
הלקוח מקבל הודעה ברגע המעבר בפועל של ההזמנה לסטטוס חדש — "הועבר למשלוח", "השליח יצא לדרך", "נמסר". מעקב השינויים כאן מתבצע לפי факт, ולא לפי לוח זמנים, ולכן ההשהיה בין האירוע האמיתי להתראה נמדדת בשניות.
סקר סטטוסים עובד אחרת: מתזמן אחת ל-N דקות עובר על כל ההזמנות הפעילות, פונה ל-API של המוביל עבור כל אחת ומשווה את הסטטוס שהתקבל לזה השמור במסד הנתונים. השינוי נרשם רק במחזור הבא, ולכן הלקוח לומד על המשלוח בהשהיה השווה למרווח הסקר.
ככל שהסקר תכוף יותר, כך העומס על ה-API ועל מסד הנתונים גבוה יותר; ככל שהוא נדיר יותר — כך חלון ההשהיה ארוך יותר. זהו פשרה фундаментальний, שלא ניתן לעקוף בהגדרה.
בפועל ההבדל מתבטא בהיקף. במודל אירועים מספר הפניות למערכת החיצונית פרופורציונלי למספר השינויים האמיתיים — מאה הזמנות נותנות מאה אירועים. בסקר, אותה כמות הזמנות נותנת זרם בקשות קבוע ללא תלות בשאלה אם הסטטוס השתנה או לא: הזמנות שתלויות במצב אחד במשך יממות עדיין נסקרות בכל מחזור. בשיאי מבצעים דווקא הסקר הופך לצוואר בקבוק, שנעצר במגבלות ה-API ובעומס על מסד הנתונים.
סכימה היברידית סוגרת מקרים שבהם אירוע טהור אינו זמין. אם המוביל אינו יודע לספק אירועים, מציבים סקר, אך עם כללים ממוקדים: סוקרים רק הזמנות בסטטוסים "חיים", מגדילים את המרווח עבור אלו שלא זזו זמן רב, ומחברים ערוץ אירועים היכן שהוא קיים. ארכיטקטורת ההתראות נשארת אחידה — המטפל אחד, משתנה רק המקור שמפעיל אותו.
עבור הלקוח הבחירה מצטמצמת לשאלה אחת: עד כמה קריטית ההשהיה ואיזה היקף הזמנות עובר דרך המערכת. במקום שבו הלקוח מצפה לאישור משלוח בזמן אמת, מודל אירועים הוא חסר חלופות.
במקום שבו הסטטוסים משתנים לעיתים רחוקות והשהיה של מספר דקות מקובלת, סקר פשוט יותר לתחזוקה ואינו דורש התאמות בצד המוביל.
ספקות טכניים נפוצים לפני ההתחלה
לפני ההתחלה כמעט תמיד עולים אותם שאלות: האם נצטרך לכתוב מחדש את מה שכבר עובד, כיצד המערכת תתנהג עם מספר מחסנים והאם נצטרך להקים שירות נפרד לשליחת הודעות. להלן כיצד אנו עונים עליהן על סמך ניסיון.
יש לנו כבר תבניות מייל ו-SMS מוגדרות — האם נצטרך לשנות אותן?
לא. התבניות הקיימות נשארות נקודת המוצא: אנו בוחנים אילו אירועים מפעילים אותן ומחברים לאותם אירועים ערוצים חדשים — Telegram, התראות חוזרות, שרשראות סטטוס.
אם התבנית בנויה בצורה לא נוחה (הטקסט מוטבע בקוד, אין החלפה של מספר הזמנה), אנו מוציאים אותה למצב שניתן לעריכה, אך שומרים על הלוגיקה והנמענים. חלק מהתרחישים פשוט מתרחבים: המייל נשאר, ולצידו מופיעה הודעה במסנג'ר עם מספר מעקב.
יש לנו מספר מחסנים ונקודות משלוח — האם ההתראות לא יתבלבלו?
כל מחסן הוא מקור אירוע נפרד עם סט הסטטוסים והתבניות שלו. ההתראה נבנית לפי הכלל "מחסן + סוג משלוח + סטטוס הזמנה", ולכן הלקוח רואה את הטקסט הנכון ואת פרטי הקשר של נקודת האיסוף שלו בלבד.
אם המחסנים פועלים במערכות שונות, אנו מאחדים את האירועים לפורמט אחיד — ומשם השליחה מתבצעת לפי לוגיקה משותפת.
האם נדרש שירות שליחה נפרד או שמספיקים האמצעים המובנים?
תלוי בהיקף ובדרישות למשלוח. האמצעים המובנים מספיקים כל עוד יש ערוץ אחד או שניים ואין כפילויות בעת תקלות. כאשר מתווספים מסנג'רים, ניסיונות חוזרים ויומן משלוחים, שירות נפרד מספק צפיות: הוא מחזיק תור, ניסיונות חוזרים ודוח "הגיע / לא הגיע". אנו לא כופים אותו — מחשבים את העומס ומראים היכן המעגל המובנה יתחיל לאבד הודעות.
אילו מגבלות כדאי לקחת בחשבון מראש?
העיקר — מגבלות הערוצים: מסנג'רים ושערי SMS מגבילים את הקצב ודורשים הסכמת הלקוח לקבלת הודעות. נקודה נוספת — אינטגרציה עם שירותי משלוחים: הסטטוסים מגיעים באיחור, ולכן אנו בונים את השרשרת כך שהלקוח לא יקבל הודעות סותרות. את המגבלות הללו אנו מתעדים בשלב התכנון, ולא לאחר ההשקה.
נדון במשימה שלכם ונחזור עם תוכנית
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים להבין את הסכימה הנוכחית של תנועת ההזמנה: היכן נוצר סטטוס המשלוח, מי משנה אותו ואיך הלקוח נודע על כך כיום. תארו את המשימה בצורה חופשית — בהמשך נשאל שאלות ממוקדות ונציע פתרון המתאים לקונטור שלכם.
מה נבהיר בשיחה הראשונה:
- מאיפה מגיע האירוע: הסטטוס מגיע מ-1С, מחברת המשלוחים או מוזן ידנית באדמין — מכך תלוי נקודת החיבור של ההתראות.
- אילו ערוצים כבר בשימוש ואילו צריך להוסיף: SMS, Email, Telegram או שילוב שלהם לפי סוג הלקוח.
- לפי אילו סטטוסים נשלחות התראות: "הועבר למשלוח", "השליח בדרך", "מוכן לאיסוף", "נמסר" — והאם יש סטטוסים ביניים שהלקוח לא צריך.
- תבניות הודעות: טקסטים מוכנים או שצריך להרכיב אותם, האם יש משתנים כמו מספר הזמנה, מספר מעקב וזמן משלוח.
- כמויות: כמה הזמנות ביממה ובתקופות שיא — כדי שהערוצים והתור יעמדו בעומס בלי עיכובים.
- הרשאות ומגבלות: מי מצד הלקוח מאשר את הטקסטים, האם יש דרישות לאחסון היסטוריית שליחות.
- אינטגרציות קיימות: ספקי SMS מחוברים, שירותי דואר, בוטים — כדי לא לשכפל את מה שכבר עובד.
בסיום השיחה אנחנו מקבעים את היקף העבודה, מחלקים אותו לשלבים ומציינים לוחות זמנים לכל אחד. אתם מקבלים תוכנית שבה רואים מה עושים ראשון, היכן נדרשים נתונים מכם ובאיזה שלב אפשר לבדוק את התוצאה על הזמנות בדיקה.
השלב הבא — שלחו תיאור של תהליך המשלוח ורשימת סטטוסים. נחזור עם הערכה, תוכנית עבודה ולוחות זמנים, ואתם תחליטו מאיזה שלב להתחיל.