צ'קליסט לחיבור WhatsApp ל-CRM

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

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

טבלה להעתקה

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

חיבור בלי אחראי מחזיר את הצוות לאותה שאלה: מי חוזר. לפני העלייה עונים על השאלות האלה:

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

הצעד הבא צריך להיות פעולה במערכת, לא «לזכור לחזור». אחרת החיבור רק מעביר את הבלגן לתוך ה־CRM.

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

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

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

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

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

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

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

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

סמנו לפני שמפעילים על פניות אמיתיות:

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

רק אחרי הסימון הזה מעבירים פניות אמיתיות לחיבור.

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

לתיאור השירות, כרטיס, אחראי וערוץ, ראו את עמוד חיבור WhatsApp ל־CRM.