אוטומציה לניהול לידים ב-CRM: מפנייה חדשה עד טיפול

מגדירים מה נחשב ליד מטופל

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

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

איש קשר, פנייה ועסקה: שלוש רשומות שלא כדאי לערבב

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

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

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

מילון שדות שאפשר להעביר למיישם

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

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

כפילויות: מתי לעדכן ומתי לעצור לבדיקה

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

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

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

חלוקת לידים: הכלל הרגיל ותור ברירת המחדל

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

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

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

זמן תגובה שנמדד לפי שעות העבודה

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

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

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

סנכרון דו-כיווני: מי רשאי לשנות איזה שדה

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

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

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

תרגיל קבלה עם מספרים שאפשר לספור

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

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

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

הדוח השבועי שהמנהל באמת צריך

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

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

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

מפת התהליך הראשונה

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

לקוח חוזר אינו בהכרח פנייה כפולה

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

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

הקצאה ותזכורות עם אחריות ברורה

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

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

מה מודדים אחרי הפעלה

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

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

בריף לספק לפני תחילת העבודה

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

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