חיבור תוכנית שותפים ל־CRM: תהליך עבודה ללידים

מגדירים שפה משותפת למערכות

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

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

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

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

מהקליק לטופס: לשמור הקשר בלי לסמוך על הדפדפן

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

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

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

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

קליטת ליד: קודם אימות, אחר כך שיוך לאיש מכירות

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

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

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

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

לא כל סטטוס מכירה צריך להפוך לסטטוס עמלה

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

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

מי מקבל קרדיט כשהלקוח חוזר?

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

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

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

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

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

לצורך המחשה בלבד, אם ההסכם מעניק עמלה של 10% מהסכום שנגבה לפני מע״מ, ונגבו 5,000 שקלים לפני מע״מ, העמלה היא 500 שקלים. אם מתקבל בהמשך החזר חלקי, ההתאמה צריכה להתבצע לפי תנאי ההסכם — לא לפי החלטה ידנית לא מתועדת.

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

מה קורה כשהחיבור נכשל — או שולח פעמיים?

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

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

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

סיכום העבודה: מה צריך להיות מוגדר לפני ההשקה

מדריכים משלימים לפי הצעד הבא

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

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