שאלו שותף למה הוא עזב את הברוקר הקודם שלו, ולעיתים נדירות תשמעו שהעמלה הייתה נמוכה מדי. תשמעו שהכסף הגיע באיחור, או שהוא הגיע רק אחרי שרדף אחרי מישהו כדי לקבל אותו, או שבחודש אחד הסכום היה חסר ואף אחד לא הצליח להסביר למה.
עמלת שותפים היא הכנסה. IB שמנהל ערוץ או סוכנות צריך לשלם ממנה לאנשים שלו. ברוקר שמתייחס לריצת התשלום החודשית כאל מטלת Backoffice אומר בשקט לכל שותף ברשת שההכנסה שלו היא בעדיפות נמוכה, ושותפים מגיבים לכך בכך שהם מעבירים את הלקוחות שלהם למקום אחר.
זהו הצד התפעולי של תוכנית השותפים. איך לקבוע את התעריפים היא שאלה נפרדת, שמכוסה ב-מדריך מבנה העמלות. כאן מדובר בלהוציא את הכסף החוצה.
מה המשמעות של "שולם בזמן" עבור שותף
שני דברים קורים בתוכנית שותפים וברוקרים לעיתים קרובות מערבבים ביניהם. העמלה נצברת באופן רציף בזמן שהלקוחות סוחרים. העמלה משולמת לפי לוח זמנים. לשותפים אכפת משניהם, מסיבות שונות.
הצברה צריכה להיות גלויה בזמן אמת. שותף שיכול לפתוח את הדשבורד שלו באמצע החודש ולראות כמה הרוויח עד כה הוא שותף שסומך על המספר כשהוא מגיע. שותף שרואה נתון רק פעם בחודש לא יכול לדעת אם הוא נכון, מה שאומר שכל פער הופך לוויכוח במקום לשאלה. מודול ה-IB רב-רמות של Kenmore מחשב מול נתוני המסחר החיים של MT4 ו-MT5 ומציג את ההצברה בפורטל השותפים בזמן אמת, מה שמסיר את רוב המחלוקות עוד לפני שהן מתחילות.
אחר כך התשלום צריך להיות צפוי. לא בהכרח מהיר, אלא צפוי. שותף שיודע שהכסף נכנס בחמישה לחודש יכול לתכנן סביב זה. שותף שמקבל תשלום איפשהו בין השלישי לשניים עשר לא יכול, ויתחיל לשאול כבר ב-4.
בחירת לוח הזמנים
חודשי הוא ברירת המחדל הנפוצה וזה עובד עבור רוב התוכניות. זה גם יוצר המתנה ארוכה אחרי ההפניה הראשונה של שותף, ולכן התשלום הראשון הוא המקום שבו הרבה שותפים חדשים משתתקים.
תשלום שבועי או דו-שבועי עולה יותר בעיבוד, אבל מחזיר את עצמו עם שותפים חדשים יותר ובאזורים שבהם אנשים פועלים במחזורים קצרים יותר. פשרה סבירה היא מחזור מהיר יותר בחודשים הראשונים של השותפות, ואז חודשי ברגע שהקשר מתבסס. השותף רואה כסף מוקדם, וזה העניין.
מה שלא תבחרו, פרסמו את זה. לוח הזמנים צריך להופיע בהסכם השותף ובפורטל, עם תאריך התשלום הבא גלוי בדשבורד.
ספי מינימום וצבירה להמשך
סף תשלום מינימלי מגן עליכם מפני תשלום של 12 דולר בהעברה בינלאומית שעולה יותר מזה לשלוח. שותפים מקבלים ספים בלי תלונות כל עוד מתקיימים שני תנאים: הסף מצוין מראש, והיתרה נצברת להמשך ולא נמחקת.
קבעו את הסף לפי שיטת התשלום ולא באופן גורף. תשלום בקריפטו יכול להיות כלכלי כבר בסכום נמוך בהרבה מהעברה בנקאית, לכן סף אחיד לכל השיטות או חוסם תשלומים קטנים שיכלו לצאת בזול, או דוחף העברות לא כלכליות דרך המערכת.
הציגו את היתרה שנצברה בפורטל. שותף שרואה "מתחת לסף, נצבר למחזור הבא" מבין מה קרה. שותף שלא רואה כלום מניח שהעמלה נעלמה.
מטבע
העמלה נצברת במטבע החשבון שלכם. השותף רוצה לקבל אותה במטבע שהוא יכול להשתמש בו.
תשלום לסוכן בניגריה בדולרים נשמע נדיב עד שהם מאבדים חלק ממנו בהמרה בשער שלא בחרו. תשלום לשותף אירופי בדולרים כשהעלויות שלו הן באירו מעביר אליו את סיכון המטבע ללא סיבה.
החליטו אם אתם סופגים את ההמרה או מעבירים אותה הלאה, כתבו זאת, והחילו זאת בעקביות. שותפים יקבלו כל אחת מהמדיניות. מה שהם לא יקבלו הוא לגלות זאת מתשלום קצר.
מסלולי תשלום, לפי אזור
אין שיטה אחת שעובדת בכל מקום, וזו אותה בעיה שכבר פתרתם בצד הלקוח. התשתית ל-ניתוב בין כמה PSP-ים חלה כאן, עם הבדל אחד: תשלומי שותפים הם יוצאים, בנפח נמוך יותר, ובסכום גבוה יותר לכל עסקה.
העברה בנקאית עובדת עבור שותפים ותיקים בשווקים עם מערכת בנקאית מפותחת, במיוחד עבור סכומים גדולים יותר. היא איטית והיא כרוכה בעמלות, ובחלק מהמסלולים היא פשוט תיכשל.
מסלולי תשלום מקומיים הם מה שסוכנים אזוריים באמת רוצים. העברה בנקאית מקומית במדינה של השותף עצמו מתבצעת מהר יותר ובעלות נמוכה יותר מהעברה בינלאומית, ובכמה מהשווקים שבהם רשתות IB צומחות הכי מהר זו השיטה היחידה שעובדת בצורה אמינה.
ארנקים אלקטרוניים מכסים שותפים בשווקים שבהם תשתיות כרטיסים ובנקאות דלות, והם מסלקים במהירות.
תשלומים ב-Stablecoin ובקריפטו הפכו לברירת המחדל עבור חלק משמעותי מהשותפים, במיוחד בעלי קהילות וכל מי שפועל מעבר לגבולות. הסליקה מהירה, העמלות צפויות, והשותף לא מחכה לבנק מתווך. הדרישות התפעוליות סביב סליקת קריפטו מכוסות במדריך ל-gateway לתשלומי קריפטו, ורובו רלוונטי ישירות גם לתשלומי שותפים.
הצעה של שתי שיטות או שלוש ומתן אפשרות לשותף לבחור כמעט לא עולה כלום, ומסירה מקור חוזר לחיכוך. העבודה שלנו על פתרונות תשלום מכסה את צד הספק, ו-מודל האגרגציה שווה הבנה אם אתם מנתבים בין כמה ספקים.
מי משלם את עמלת ההעברה
קבלו החלטה על כך לפני התשלום הראשון, לא אחרי ששותף שואל על תשלום חלקי.
שתי המדיניות ניתנות להצדקה. ספיגת העמלה היא נקייה יותר ומקלה על ההתאמה החשבונאית של השותף. הטלתה על השותף היא סבירה עבור שיטות יקרות, במיוחד אם השותף בחר בשיטה הזו כאשר הייתה זמינה גם חלופה זולה יותר.
מה שלא עובד הוא עמלה שמופיעה ללא אזהרה. יש לציין זאת בהסכם, להציג אותה כשורה נפרדת ברישום התשלום, ולאפשר לשותף לראות את הסכום נטו לפני ביצוע התשלום.
מה השותף צריך לראות
שותף שמבצע התאמה של תשלום רוצה לענות על שלוש שאלות בלי לפנות לאף אחד: איזו תקופה זה מכסה, אילו לקוחות ואילו רמות יצרו את זה, ואיך הסכום הגולמי הפך לנטו.
המשמעות היא שרישום התשלום צריך לכלול את התקופה, נפח לפי לקוח או לפי הפניה, עמלה לפי רמה עבור שותפים עם רשת מתחתיהם, כל צבירה לסף, כל עמלה, ואת הסכום נטו יחד עם השיטה והתאריך. שותפים עם תתי-שותפים צריכים במיוחד את הפירוט לפי רמה, כי חשוב להם להבין איזה חלק מהרשת שלהם מייצר.
זו עבודת דיווח, והיא יושבת לצד שאר ה-דיווח ב-CRM שלכם. בנייה שלה פעם אחת מסירה עומס קבוע מצוות השותפים שלכם.
אישור, תאימות והמסמכים
תשלומי שותפים הם תשלומים לעסק, ולכן הם נכנסים לקטגוריה שונה ממשיכות של לקוחות.
יש לאמת שותפים לפני התשלום הראשון, לא לפני ההפניה הראשונה. ביצוע KYC לשותפים כבר בשלב ההצטרפות מעכב גיוס בלי תועלת, כי שותף שמעולם לא מייצר גם לעולם לא מקבל תשלום. ביצועו כשהתשלום הראשון מגיע בודק את כל מה שצריך בלי להוסיף חיכוך להרשמה. הטיפול במסמכים משתלב באותו תהליך KYC ו-AML שכבר אתם מפעילים.
החליטו אם השותפים מוציאים לכם חשבונית או שאתם מוציאים חשבונית בשמם, והקפידו על עקביות. שותפים גדולים שפועלים כחברות בדרך כלל ירצו להוציא חשבונית. לשותפים פרטיים בדרך כלל אין את היכולת לכך, והצהרה שמונפקת בשמם ושאותה הם יכולים להעביר לרואה החשבון שלהם תהיה שימושית יותר עבורם.
שמרו שער אישור על תשלומים מעל סף שאתם קובעים. אדם אחד שבודק את הריצה לפני ההפעלה מזהה את שגיאת התצורה שאחרת הייתה מגיעה בבת אחת לחמישים שותפים.
כשיש כשל בתשלום
זה יקרה. בנק דוחה את ההעברה, כתובת ארנק שגויה, פרטי שותף השתנו ואף אחד לא עדכן אותם.
מצב הכשל שפוגע בקשר הוא שתיקה. שותף שהתשלום שלו חזר והוא מגלה זאת רק כששם לב לחשבון ריק, מניח שהברוקר לא שילם. שותף שמקבל הודעה באותו היום יודע שהברוקר מטפל בזה.
בנו את ההתראה בצד הברוקר, לא רק בצד השותף. צוות השותפים שלכם צריך לראות את הכשל לפני שהשותף רואה אותו, והסכום שנכשל צריך לחזור ליתרת השותף באופן גלוי במקום להיעלם לתוך תור התאמות.
הריצו את זה לפי לוח זמנים, לא לפי בקשות
תוכנית שותפים שמשלמת כאשר השותפים מבקשים זאת תבזבז חלק הולך וגדל מזמנה על ניהול תשלומים ככל שהיא תגדל. המטרה היא ריצה מתוזמנת שמתבצעת בלי שאיש יפתח גיליון אלקטרוני: העמלה מחושבת מנתוני מסחר חיים, העץ מחלק בין רמות, חלות מגבלות ועמלות, הריצה עוברת לאישור אחד, והכסף יוצא.
זה אפשרי, וברובו מדובר בשאלה האם מנוע העמלות מחובר ישירות לשרת המסחר או שמישהו מייצא דוחות ומבצע התאמות ידניות. הגישה השנייה מחזיקה מעמד בעשרים שותפים ונשברת במאתיים.
Kenmore Design בונה את השכבה הזו עבור ברוקרים מאז 2006. המודול IB רב-רמות תומך ברמות ללא הגבלה, בעמלה לפי פיפס, באחוז מהספרד, מהרווח או מההפקדה, או במזומן ללוט, בחשבונות רגילים וחשבונות סנט, עם דוחות בצד השותף ואינטגרציה עם MT4 ו-MT5 בתשלום חודשי קבוע. אם אתם מגייסים שותפים עכשיו, מדריך הגיוס ו-מדריך ההפעלה מכסים את מה שקורה לפני התשלום הראשון.
בקשו ייעוץ לגבי בניית אסטרטגיית תשלומי IB
קבלו הכוונה מקצועית בבניית מסגרת אמינה לתשלום עמלות עבור רשת ה-Introducing Broker שלכם. נעזור לכם להעריך לוחות זמנים לתשלום, ספי מינימום, המרת מטבע, שיטות תשלום, תהליכי אישור ודיווח לשותפים, כדי לתמוך בתשלומי עמלות צפויים ושקופים.
יחד, נבחן את תהליכי תשלום השותפים הנוכחיים שלכם ונשרטט אסטרטגיית תשלומים שתהיה מותאמת לתהליכים הפיננסיים של הברוקראז' שלכם ולצמיחה ארוכת הטווח.
