חיבור חנות אונליין ל-CRM: מה עובר ומה נשאר בחנות?

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

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

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

מה עובר מחנות אונליין ל-CRM ומה לא?

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

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

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

מה עדיף להשאיר בחנות האונליין ולא להעתיק?

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

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

איפה נשבר החיבור בין החנות ל-CRM?

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

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

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

כיוון הסנכרון בין CRM לחנות אונליין: מי מעדכן את מי?

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

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

מתי לא צריך לחבר חנות אונליין ל-CRM?

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

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