כשה-CRM לא זמין: איך בונים תוכנית המשכיות מראש?

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

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

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

מתי ה-CRM לא זמין בפועל, ואיך מזהים את זה מוקדם?

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

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

לכן מתחילים באבחון, לפני שמישהו מכריז שהמערכת נפלה. קודם פותחים אותה מהטלפון בגלישה סלולרית, בלי ה-Wi-Fi של המשרד. אם היא נטענת, הבעיה כנראה אצלכם. אם לא, נכנסים לדף הסטטוס של הספק לפי מרכז הנתונים שהחשבון שלכם נמצא בו (יש כזה גם ל-Monday וגם ל-Zoho), וגם לדף הסטטוס של Make או Zapier, ומתקשרים לעובד שעובד היום מהבית. בתוך כמה דקות ברור בדרך כלל איפה התקלה.

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

תוכנית המשכיות ל-CRM: שמונה שלבים שמכינים מראש

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

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

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

תוכנית המשכיות ב-Monday וב-Zoho CRM: מה בודקים בחשבון שלכם?

ההתנהגות של Monday ושל Zoho ביום תקלה תלויה בחבילה ובהגדרות, ולכן ריכזנו כאן בדיקות. עדיף להריץ אותן עכשיו.

Monday

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

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

Zoho CRM

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

כללי זרימת העבודה (Workflow Rules) רצים גם ביצירה ידנית, וגם כשמשלימים ריצה שמורה ב-Make. לכל כלל שפונה ללקוח מוסיפים תנאי על שדה "הוזן בדיעבד", כך שרשומות מנוהל החירום לא יפעילו אותו. בדקו את זה בסביבת הבדיקה (Sandbox), אם המהדורה שלכם כוללת כזאת.

Make ו-Zapier: מה קורה לליד כשה-CRM לא עונה?

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

ב-Make, תרחיש שאין בו טיפול בשגיאות (Error handler) נעצר כשהוא נתקל בשגיאה. אם הפעלתם בהגדרות התרחיש שמירה של ריצות שלא הושלמו (Incomplete executions), הריצה נשמרת ואפשר להשלים אותה כשהמערכת חוזרת. אחרי שגיאות חוזרות Make עלול לכבות את התרחיש, ופניות שמגיעות דרך Webhook נשמרות בדרך כלל בתור עד גבול שתלוי בחבילה. ב-Zapier בדקו אם הרצה חוזרת אוטומטית (Autoreplay) קיימת בחבילה שלכם ובאיזה חלון זמן. אחריו, ריצות מופעלות ידנית.

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

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

שלוש גישות להמשכיות כשה-CRM לא זמין: איזו מתאימה לכם?

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

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

מקרה לדוגמה: בוקר בלי CRM בחברת מזגנים

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

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

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

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

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

טעויות נפוצות בתוכנית המשכיות ל-CRM ואיך נמנעים מהן?

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

מתי לא צריך תוכנית המשכיות מלאה ל-CRM?

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

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

רשימת בדיקה לתוכנית המשכיות ל-CRM

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

שאלות נפוצות על תוכנית המשכיות ל-CRM