CRM לרשת סניפים וזכיינים: מה משותף ומה נפרד?

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

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

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

למה רשת סניפים לא יכולה להסתפק במערכת נפרדת לכל סניף?

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

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

מה שייך לרשת ומה שייך לזכיין?

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

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

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

ניתוב לידים בין סניפים ברשת: לפי מה מחליטים?

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

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

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

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

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

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

מתי רשת סניפים לא באמת צריכה מערכת CRM אחת?

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

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