از یک شریک بپرسید چرا آخرین بروکرش را ترک کرد، و بهندرت خواهید شنید که نرخ خیلی پایین بوده است. خواهید شنید که پول دیر رسید، یا بعد از آن رسید که مجبور شد کسی را برای گرفتنش دنبال کند، یا اینکه یک ماه مبلغ کم بود و هیچکس نمیتوانست توضیح دهد چرا.
کمیسیون شریک درآمد است. یک IB که یک کانال یا آژانس را اداره میکند، از همین درآمد باید به افرادش پرداخت کند. بروکری که اجرای پرداخت ماهانه را یک کار پشتصحنهای میداند، عملاً به هر شریک در شبکه میگوید درآمد او اولویت پایینی دارد، و شرکا در پاسخ، مشتریان خود را به جای دیگری میبرند.
این بخش، سمت عملیاتی برنامه شرکا را پوشش میدهد. اینکه نرخها را چگونه تعیین کنید، پرسش جداگانهای است که در راهنمای ساختار کمیسیون پوشش داده شده است. این یکی درباره رساندن پول به دست ذینفع است.
«بهموقع پرداخت شدن» برای یک شریک یعنی چه
دو اتفاق در یک برنامه شرکا میافتد و بروکرها اغلب این دو را با هم قاطی میکنند. کمیسیون بهصورت پیوسته با معاملهکردن مشتریان انباشته میشود. کمیسیون طبق یک زمانبندی پرداخت میشود. شرکا به هر دو اهمیت میدهند، اما به دلایل متفاوت.
انباشتهشدن باید بهصورت بلادرنگ قابل مشاهده باشد. شریکی که بتواند در میانه ماه داشبوردش را باز کند و ببیند تا این لحظه چه چیزی به دست آورده است، شریکی است که وقتی عدد نهایی میرسد به آن اعتماد میکند. شریکی که فقط ماهی یکبار یک عدد میبیند، هیچ راهی برای تشخیص درست بودن آن ندارد؛ یعنی هر اختلافی بهجای یک سؤال، به یک بحث تبدیل میشود. ماژول IB چندسطحی Kenmore با دادههای زنده معاملات MT4 و MT5 محاسبه میکند و انباشتهشدن را همانطور که رخ میدهد در پرتال شریک نشان میدهد، و این کار پیش از آغاز، بیشتر اختلافها را از بین میبرد.
سپس پرداخت باید قابل پیشبینی باشد. لزوماً سریع نه، قابل پیشبینی. شریکی که بداند پول در پنجم ماه میرسد، میتواند برنامهریزی کند. شریکی که بین سوم تا دوازدهم پرداخت میشود نمیتواند، و از روز چهارم شروع به پیگیری میکند.
انتخاب زمانبندی
پرداخت ماهانه انتخاب رایج پیشفرض است و برای بیشتر برنامهها جواب میدهد. اما در عین حال، بعد از اولین ارجاع، شریک باید مدت زیادی منتظر بماند؛ به همین دلیل اولین پرداخت جایی است که بسیاری از شرکای جدید ساکت میشوند.
پرداخت هفتگی یا هر دو هفته یکبار هزینه پردازشی بیشتری دارد، اما برای شرکای جدیدتر و در مناطقی که مردم با چرخههای کوتاهتر کار میکنند، هزینهاش را جبران میکند. یک مصالحه معقول این است که برای چند ماه اول همکاری، چرخه سریعتری داشته باشید و بعد از تثبیت رابطه، پرداختها را ماهانه کنید. شریک زودتر پول را میبیند، و همین نکته مهم است.
هرچه را انتخاب کنید، آن را منتشر کنید. این زمانبندی باید در قرارداد شریک و در پرتال درج شود، و تاریخ پرداخت بعدی روی داشبورد قابل مشاهده باشد.
آستانهها و انتقال مانده
حداقل آستانه پرداخت از این محافظت میکند که دوازده دلار را با یک حواله بینالمللی بپردازید که هزینه ارسالش از خود آن بیشتر است. شرکا تا زمانی با آستانهها مشکلی ندارند که دو شرط برقرار باشد: آستانه از ابتدا اعلام شده باشد، و مانده به دوره بعد منتقل شود، نه اینکه حذف شود.
آستانه را برای هر روش پرداخت جداگانه تعیین کنید، نه بهصورت سراسری. پرداخت رمزارزی میتواند از نظر اقتصادی در مبلغی بسیار کمتر تسویه شود تا حواله بانکی، بنابراین یک آستانه واحد برای همه روشها یا پرداختهای کوچک و ارزان را که میتوانستند انجام شوند متوقف میکند، یا حوالههای غیراقتصادی را به جریان میاندازد.
مانده منتقلشده را در پرتال نشان دهید. شریکی که ببیند «کمتر از آستانه، منتقلشده به چرخه بعدی» میفهمد چه اتفاقی افتاده است. شریکی که چیزی نبیند، فرض میکند کمیسیون ناپدید شده است.
ارز
کمیسیون در ارز حساب شما انباشته میشود. شریک میخواهد آن را به ارزی دریافت کند که بتواند از آن استفاده کند.
پرداخت دلاری به یک نماینده نیجریهای در نگاه اول سخاوتمندانه به نظر میرسد، تا وقتی که بخش زیادی از آن را هنگام تبدیل با نرخی که خودش انتخاب نکرده از دست بدهد. پرداخت دلاری به یک شریک اروپایی وقتی هزینههای او یورویی است، بدون دلیل ریسک ارزی را به او منتقل میکند.
تصمیم بگیرید که آیا هزینه تبدیل را خودتان میپذیرید یا آن را به طرف مقابل منتقل میکنید، آن را مکتوب کنید و بهصورت یکنواخت اجرا کنید. شرکا هر دو سیاست را میپذیرند. چیزی که تحمل نخواهند کرد این است که از طریق یک پرداخت ناقص به آن پی ببرند.
رِیلها، بر اساس منطقه
هیچ روش واحدی وجود ندارد که همهجا کار کند، و این همان مشکلی است که شما قبلاً در سمت مشتری حل کردهاید. زیرساختمسیریابی چند-PSP با یک تفاوت در اینجا هم کاربرد دارد: پرداخت به شرکا خروجی است، حجم کمتری دارد و مبلغ هر تراکنش بالاتر است.
انتقال بانکی برای شرکای باسابقه در بازارهای دارای زیرساخت بانکی مناسب کار میکند، بهویژه برای مبالغ بزرگتر. این روش کند است و کارمزد دارد، و در برخی مسیرها عملاً اصلاً انجام نمیشود.
رِیلهای پرداخت محلی همان چیزی هستند که ایجنتهای منطقهای واقعاً میخواهند. انتقال بانکی محلی در کشور خودِ شریک، نسبت به حواله بینالمللی سریعتر و ارزانتر تسویه میشود، و در چندین بازاری که شبکههای IB با سریعترین نرخ رشد میکنند، تنها روشی است که بهطور قابل اتکا کار میکند.
کیفپولهای الکترونیکی شرکا را در بازارهایی پوشش میدهند که زیرساخت کارت و بانک ضعیف است، و تسویه آنها سریع انجام میشود.
پرداخت با استیبلکوین و کریپتو به گزینه پیشفرض برای بخش قابلتوجهی از شرکا تبدیل شده است، بهویژه برای مالکان کامیونیتی و هر کسی که بهصورت فرامرزی فعالیت میکند. تسویه سریع است، کارمزدها قابل پیشبینیاند، و شریک منتظر بانک کارگزار نمیماند. الزامات عملیاتی مربوط به تسویه کریپتو درراهنمای درگاه پرداخت کریپتوپوشش داده شدهاند، و بیشتر آن مستقیماً به پرداخت به شرکا نیز قابلانتقال است.
ارائه دو یا سه روش و اجازه دادن به شریک برای انتخاب، هزینه زیادی ندارد و یکی از منابع تکراری اصطکاک را حذف میکند. کار ما در زمینه راهکارهای پرداخت سمت ارائهدهنده را پوشش میدهد، و مدل تجمیع اگر در حال مسیریابی میان چند ارائهدهنده هستید، ارزش درک کردن را دارد.

چه کسی کارمزد انتقال را پرداخت میکند
این را قبل از اولین پرداخت تعیین کنید، نه بعد از اینکه شریک درباره یک پرداخت کمشده سؤال کرد.
هر دو سیاست قابل دفاع هستند. بهعهده گرفتن کارمزد، تمیزتر است و تسویهحساب شریک را ساده میکند. منتقل کردن کارمزد به شریک برای روشهای گرانتر منطقی است، بهخصوص اگر شریک همان روش را زمانی انتخاب کرده که گزینه ارزانتری هم در دسترس بوده است.
آنچه کار نمیکند، کارمزدی است که بدون هشدار ظاهر میشود. آن را در توافقنامه بیاورید، در رکورد پرداخت بهصورت یک ردیف جداگانه نمایش دهید، و اجازه دهید شریک قبل از انجام پرداخت مبلغ خالص را ببیند.
شریک چه چیزی باید ببیند
شریکی که در حال تطبیق یک پرداخت است میخواهد بدون تماس با کسی به سه سؤال پاسخ دهد: این پرداخت مربوط به چه بازهای است، کدام مشتریان و کدام سطوح آن را ایجاد کردهاند، و چگونه مبلغ ناخالص به خالص تبدیل شده است.
یعنی رکورد پرداخت باید بازه، حجم بر اساس مشتری یا ارجاع، کمیسیون بر اساس سطح برای شرکایی که زیرمجموعه دارند، هرگونه انتقال مانده آستانه، هرگونه کارمزد، و مبلغ خالص بههمراه روش و تاریخ را شامل شود. شرکایی که زیرشریک دارند، مشخصاً به تفکیک سطح نیاز دارند، چون برایشان مهم است که کدام بخش شبکهشان عملکرد ایجاد کرده است.
این کار، کاری از جنس گزارشگیری است و در کنار سایر گزارشدهی CRM شما قرار میگیرد. یکبار ساختن آن، یک بارِ دائمی را از دوش تیم شریک شما برمیدارد.
تأیید، انطباق و مدارک
پرداختهای شرکا به یک کسبوکار انجام میشود، بنابراین در دستهای متفاوت از برداشتهای مشتری قرار میگیرد.
شرکا باید پیش از اولین پرداخت تأیید شوند، نه پیش از اولین معرفی. اجرای KYC شریک در مرحله جذب، بدون هیچ منفعتی فرایند استخدام را کند میکند، چون شریکی که هیچوقت عملکردی ندارد، هیچوقت هم دستمزدی دریافت نمیکند. انجام آن هنگام سررسید اولین پرداخت، همه چیزهای لازم را پوشش میدهد، بدون اینکه به ثبتنام اصطکاک اضافه کند. مدیریت اسناد با همان KYC and AML workflowی که از قبل اجرا میکنید سازگار است.
تعیین کنید که شرکا برای شما فاکتور صادر میکنند یا شما بهصورت خودصورتحساب عمل میکنید، و در این زمینه ثابتقدم باشید. شرکای بزرگتر که بهصورت شرکت فعالیت میکنند معمولاً میخواهند فاکتور صادر کنند. شرکای حقیقی معمولاً چنین ظرفیتی ندارند، و یک صورتحسابِ خودپرداختشده که بتوانند به حسابدار خودشان بدهند برایشان مفیدتر است.
برای پرداختهایی که از آستانهای که تعیین کردهاید بالاتر هستند، یک مرحله تأیید نگه دارید. اینکه یک نفر قبل از اجرای فرایند، آن را بازبینی کند، خطای پیکربندیای را که در غیر این صورت میتوانست همزمان به پنجاه شریک برسد، شناسایی میکند.
وقتی پرداخت ناموفق میشود
خواهد شد. بانک انتقال را رد میکند، آدرس کیف پول اشتباه است، اطلاعات یک شریک تغییر کرده و هیچکس آن را بهروزرسانی نکرده است.
حالتی که به رابطه آسیب میزند سکوت است. شریکی که پرداختش برگشت بخورد و خودش با دیدن موجودی خالی متوجه شود، فرض میکند کارگزار پرداخت نکرده است. شریکی که همان روز پیام میگیرد، میداند که کارگزار در حال پیگیری است.
هشدار را در سمت کارگزار بسازید، نه فقط در سمت شریک. تیم شرکای شما باید قبل از خودِ شریک از خطا مطلع شود، و مبلغ ناموفق باید بهصورت قابلمشاهده به موجودی شریک بازگردد، نه اینکه در یک صف تطبیق ناپدید شود.
آن را طبق برنامه اجرا کنید، نه بر اساس درخواستها
برنامه شراکتی که فقط وقتی شرکا درخواست میدهند پرداخت انجام میدهد، با رشد خود بخش فزایندهای از زمانش را صرف مدیریت پرداختها خواهد کرد. هدف این است که یک اجرای زمانبندیشده داشته باشید که بدون اینکه کسی فایل صفحهگستردهای را باز کند انجام شود: کمیسیون از دادههای زنده معاملات محاسبه شود، درخت سهمها را بین سطوح تخصیص دهد، آستانهها و کارمزدها اعمال شوند، فرایند برای یک مرحله تأیید برود، و پول پرداخت شود.
این کار شدنی است، و بیشتر به این بستگی دارد که موتور کمیسیون بهطور مستقیم به سرور معاملاتی متصل باشد یا اینکه کسی گزارشها را خروجی بگیرد و بهصورت دستی تطبیق دهد. رویکرد دوم در مقیاس بیست شریک دوام میآورد و در دویست شریک از هم میپاشد.
Kenmore Design از سال 2006 این لایه را برای کارگزاران ساخته است. ماژول multi-level IB module سطوح نامحدود را مدیریت میکند، کمیسیون را بهصورت پیپ، درصدی از اسپرد، سود یا واریز، یا وجه نقد بهازای هر لات، برای حسابهای عادی و سنت، بههمراه گزارشدهی در سمت شریک و یکپارچهسازی با MT4 و MT5، با یک هزینه ثابت ماهانه پوشش میدهد. اگر اکنون در حال جذب شریک هستید، recruitment guide و enablement guide توضیح میدهند که پیش از اولین پرداخت چه اتفاقی میافتد.
درخواست مشاوره درباره ساخت یک استراتژی پرداخت IB
برای طراحی یک چارچوب قابلاعتماد برای پرداخت کمیسیون در شبکه Introducing Broker خود، از راهنمایی تخصصی بهرهمند شوید. ما به شما کمک میکنیم زمانبندیهای پرداخت، حداقل آستانهها، تبدیل ارز، روشهای پرداخت، فرآیندهای تأیید و گزارشدهی شرکا را ارزیابی کنید تا پرداختهای کمیسیون بهصورت قابلپیشبینی و شفاف انجام شود.
با هم، عملیات فعلی پرداخت به شرکای شما را بررسی میکنیم و یک استراتژی پرداخت ترسیم میکنیم که با فرایندهای مالی و رشد بلندمدت کارگزاری شما همسو باشد.