این مشتری یک بروکر خُرد Forex جاافتاده در جنوبشرق آسیاست که به یک پایگاه معاملهگر منطقهای خدمت میکند که بهطرز چشمگیری در یک کشور متمرکز است — نزدیک به نود و هفت درصد از مشتریان ثبتنامشده از یک بازار داخلی میآیند — و در کنار آن، دنبالهای بلند از معاملهگران مهاجر در سایر نقاط منطقه دارد. مدل جذب مشتری آنها بهشدت مبتنی بر IB است: حدود هفت نفر از هر ده مشتری از طریق مشارکت با Introducing Broker ثبتنام میکنند و یک IB برترِ واحد، تقریباً یکسوم از کل تراکنشهای واریز تکمیلشده روی پلتفرم را هدایت کرده است.
وقتی این مشتری سالها قبل برای اولین بار با Kenmore همکاری کرد، از قبل در حال اداره یک کسبوکار Forex بود و به دنبال پلتفرمی میگشت که بتواند با سرعتی که آنها میخواستند برندهای جدیدِ رو به بازار را آزمایش کنند، همگام بماند. آنها یک استقرار یکباره نمیخواستند. آنها زیرساختی میخواستند که به آنها اجازه دهد برندهای معاملاتی را مطابق با تکامل فرضیه ورود به بازارشان، راهاندازی، تغییرنام، متوقف و دوباره عرضه کنند — بدون اینکه هر بار Backoffice را به پلتفرم دیگری منتقل کنند.
اولین استقرار Traders Room و CRM برای این مشتری از زمان امضای قرارداد تا سیستم زنده، تقریباً سه هفته طول کشید. این تحویل شامل یک Traders Room متصل به MetaTrader، یک ماژول IB چندسطحی، یکپارچهسازی NinjaCharge بهعنوان تجمیعکننده پرداخت، یک CRM با گردشکارهای سفارشی برای مسیردهی فروش و پشتیبانی، پشتیبانی چندزبانه، و یک لایه چت زنده بود.
اولین برند منطقهای که در دادههای این مطالعه موردی ثبت شده، در اوایل ماه ۱ بازه تحلیل، بهصورت زنده راهاندازی شد. تا ماه ۲، حجم ماهانه واریز از آستانهای که ما بهعنوان مبنای اندازهگیری رشد شاخصی استفاده میکنیم عبور کرده بود. تا ماه ۳، این حجم تقریباً به بیست برابر مبنا رسیده بود. تا ماه ۸، به شصت و هشت برابر رسید — اوج عملیاتی.
CRM Kenmore حول مفهومی ساخته شده که مشتری از آن بهعنوان اهرم مرکزی کل استراتژی رشد خود استفاده میکرد: Regions. Region یک برش کاملاً ایزوله و کاملاً برندشده از پلتفرم است که روی همان Backoffice قرار میگیرد. هر Region دارای موارد زیر است:
آنچه یکپارچه باقی میماند هسته عملیاتی است: یک تیم ادمین، یک لایه گزارشدهی، یک سیستم تیکتینگ، یک سلسلهمراتب IB، یک خط لوله KYC. مشتری هرگز مجبور نشد بین «ما یک برند جدید میخواهیم» و «میخواهیم تیم عملیاتمان از روز اول بهرهور بماند» یکی را انتخاب کند.
برای این بروکریج، این یعنی آنها میتوانستند هویتهای برند را همانطور آزمایش کنند که اکثر شرکتها لندینگپیجها را تست میکنند — و همین کار را هم کردند. در سراسر این رابطه گستردهتر، مشتری شش برند منطقهای متمایز را از طریق پلتفرم Kenmore اجرا کرده است. دو مورد از این برندها موضوع دادههای این مطالعه موردی هستند: یک برند اصلی که عرضه را پیش برد، و یک برند جانشین که مشتری حدود ده ماه بعد برای آزمایش جایگاهسازی متفاوت سفارش داد.
مشتری با این نیاز به سراغ ما آمد که یک Traders Room داشته باشد که بتواند افتتاح حسابهای واقعی و دمو، بارگذاری مدارک KYC، درخواستهای واریز و برداشت، و سلفسرویس معاملهگر برای اطلاعات شخصی و تاریخچه حساب را مدیریت کند — همگی متصل به CRMی که فعالیتهای ورودی را به کارکنان مناسب ارجاع دهد. ما New Edition Traders Room را بههمراه CRM تعبیهشده در حدود سه هفته تحویل دادیم. تا اوج عملیاتی، سیستم بیش از ۱,۱۰۰ وظیفه داخلی در ماه را پردازش میکرد — تأیید ثبتنام، بررسیهای KYC، تأیید واریز، تأیید برداشت، و افتتاح حساب IB — بدون نیاز به یک ابزار تیکت جداگانه.
معاملهگران این مشتری روی MT معامله میکنند. هر Region در این همکاری با سرور معاملاتی MT مخصوص خودش و بهصورت مستقل پیکربندی شده است. وقتی مشتری خواست Region دوم را اضافه کند، ما یک اتصال سرویس MT جداگانه فراهم کردیم تا دو برند، با وجود اشتراک Backoffice، زیرساخت معاملاتی مشترک نداشته باشند. انواع حساب، سطوح لوریج، و قواعد نامگذاری گروهها برای هر Region بهصورت جداگانه تعریف میشوند.
برنامه IB کانال اصلی جذب مشتری این مجموعه است. تقریباً هفت نفر از هر ده معاملهگر فعال آنها به یک IB یا sub-IB نسبت داده میشوند. Kenmore سلسلهمراتب IB چندسطحی موجود آنها را در روز اول به پلتفرم جدید منتقل کرد، با رهگیری URL ارجاع، قوانین کمیسیون پلکانی، گزینههای تقسیم سود، و یک نمای تحلیلی «My IBs / My Traders» در داخل Traders Room. سیستم طوری پیکربندی شد که یک زنجیره واحد IB هر دو Region را پوشش دهد — مشتری نمیخواست رهگیری کمیسیون را بین برندها تکهتکه کند.
NinjaCharge تجمیعکننده پرداخت مشتری است (یک لایه مسیریابی که بالای PSPها قرار میگیرد، نه خود PSP). ما بیش از سی نقطه پایانی PSP را پشت NinjaCharge روی ریلهای ارز محلی یکپارچه کردیم — عمدتاً VND برای بازار داخلی، بهعلاوه پیکربندیهایی برای MYR، THB، IDR، و BTC برای مشتریان دیگر در منطقه. نمایش PSPها بهصورت منطقهای کنترل میشود: Region دوم با مجموعه PSPهای منتخب خودش و متمایز از Region اول بهصورت زنده راهاندازی شد. از میان بیش از سی نقطه پایانی یکپارچهشده، حدود دو سوم در هر زمان مشخص بهصورت عمومی در Traders Room نمایش داده میشوند و باقی بهعنوان ذخیره نگه داشته میشوند.
واریزها از طریق NinjaCharge و با مدیریت خودکار callback انجام میشوند — معاملهگر وضعیت را بهصورت بلادرنگ در Traders Room میبیند. برداشتها از طریق یک گردشکار دستیِ مبتنی بر وظیفه در CRM انجام میشوند، با قوانین اعتبارسنجی سفارشی که مشتری درخواست کرده بود (بررسی موجودی، گاردهای تبدیل ارز، و تأیید نام ذینفع برای هر PSP). همه رویدادهای واریز و برداشت، وظایف CRM ایجاد میکنند، به تیم اپراتور مناسب ارجاع داده میشوند، و دوباره وارد تاریخچه حساب معاملهگر میشوند.
CRM با شش زبان پشتیبانیشده پیکربندی شده است، و متنها برای هر زبان هم در Traders Room و هم در قالبهای ایمیل نگهداری میشوند. تشخیص زبان مبتنی بر موقعیت جغرافیایی، در اولین بازدید سایتِ مخصوص معاملهگر را به زبان مناسب سوئیچ میکند.
مشتری از عملیات پاداش و اعتبار بهعنوان بخشی از جریان کمیسیون IB و برای کمپینهای تبلیغاتی استفاده میکند. پلتفرم، تعدیل موجودی را از طریق همان خط لوله وظیفه و تأیید که برای واریزها استفاده میشود، پشتیبانی میکند.
هر Region گرافیک برند مخصوص خودش را دارد — لوگو، پالت رنگی، هدر، فوتر، فونتها، و CSS سفارشی قالب. دو Region موجود در این دادهها هویتهای بصری کاملاً متفاوتی دارند؛ معاملهگری که وارد یکی از آنها شود، هیچ راهی برای فهمیدن این ندارد که در واقع روی همان CRM زیربنایی قرار دارد.
یک روند مستمر توسعه سفارشی در کنار تحویل ماژولهای استاندارد در تمام مدت همکاری جریان داشت. مشتری نیازهای مشخصی داشت که محصول استاندارد پوشش نمیداد، و Kenmore اصلاحات و بهبودها را در بازهای معمولاً چندروزه، نه چند هفتهای، تحویل میداد. نمونههایی از لاگ توسعه:
چرخه توسعه سفارشی بخشی از دلیل ماندگاری مشتری روی پلتفرم در طول چند سال و چندین نوبت تغییر برند بوده است: وقتی مسیر ورود به بازارشان تغییر میکند، پلتفرم در چند روز تطبیق پیدا میکند، نه در چند فصل.
حدود ماه 10 از بازه تحلیل — زمانی که Region اول هنوز حجم واریز نزدیک به اوج را ثبت میکرد — مشتری یک Region دوم سفارش داد. خلاصه نیازها ساده بود: برند جدا، دامنه جدا، سرور MT جدا، مجموعه PSP جدا، اما مدیریت توسط همان تیم در همان CRM. شش هفته میخواستند؛ شش هفته گرفتند. تقسیمبندی کار به این صورت بود:
تا ابتدای ماه 12، Region دوم اولین تریدرهای خود را ثبت میکرد. تا ماه 14، از نظر ثبتنامهای جدید ماهانه به برابری با Region اول رسید. تا ماه 18، Region دوم حجم واریز بیشتری از Region اول پردازش میکرد. تا ماه 20، Region اول جمعآوری شده بود و Region دوم 100% تمام کسبوکار جدید — ثبتنامها، واریزها و حسابها — را پوشش میداد. این انتقال بدون تغییر پلتفرم، بدون مهاجرت داده و بدون بازآموزی اپراتورها انجام شد: همان CRM، همان تیم ادمین، فقط Region متفاوتی فعال شده بود.
این نمونه کلاسیکِ چیزی است که معماری Regions برای آن وجود دارد. فرضیه برند مشتری تغییر کرد؛ عملیاتشان مجبور نبود تغییر کند.
با استفاده از ماه 2 از بازه تحلیل — اولین ماه با فعالیت واریز قابلتوجه — بهعنوان مبنای شاخص 1×:
| دوره | شاخص حجم واریز | یادداشت |
|---|---|---|
| ماه 1 | 0.04× | راهاندازی نرم |
| ماه 2 | 1.00× | مبنا |
| ماه 3 | 19.67× | اولین cohort IB فعال میشود |
| ماه 4 | 31.09× | |
| ماه 5 | 32.51× | |
| ماه 6 | 33.63× | |
| ماه 8 | 68.36× | اوج عملیاتی (Region اول) |
| ماه 10 | 33.39× | اوج بر اساس تعداد واریز (227 در یک ماه) |
| ماه 11 | 13.30× | Region اول سرد میشود؛ Region دوم سفارش داده میشود |
| ماه 14 | 6.86× | Region دوم فعال است |
| ماه 17 | 8.38× | Region دوم از Region اول پیشی میگیرد |
| ماه 18 | 24.33× | Region دوم بار را به دوش میکشد |
| ماه 20 | 42.90× | اوج خودِ Region دوم؛ Region اول جمعآوری شد |
پلتفرم دو موج رشد متمایز را روی دو برند متفاوت، بدون تغییر در زیرساخت، جذب کرد.
دو Region ویژگیهای قیفی بهطور محسوسی متفاوتی نشان میدهند:
| شاخص | Region اول | Region دوم |
|---|---|---|
| سهم نسبتدادهشده به IB | 70.5% | 61.0% |
| نرخ تبدیل واریز (ثبتنام → واریز) | 17.5% | 31.4% |
| میانگین واریز به ازای هر واریزکننده | 6.4 | 5.5 |
Region دوم تریدرهای ثبتنامشده را تقریباً با دو برابر نرخ Region اول به واریزکننده تبدیل میکند. همان CRM زیرین، همان تیم عملیات، همان لایه PSP — اما برند متفاوت، ترکیب جذب متفاوت، رفتار متفاوت تریدر. این یک سیگنال روشن است که فرضیه تکرار و تکامل برند مشتری کار میکرده است.
در سراسر پنجره کامل تحلیل، مجموع درخواستهای برداشت نسبت USD-معادل تقریباً 1.34:1 در برابر واریزهای تکمیلشده است. توجه داشته باشید که سمت واریز و برداشت به ارزهای متفاوتی نامگذاری شدهاند و از طریق گردشکارهای عملیاتی متفاوتی پردازش میشوند — واریزها بهصورت خودکار از طریق تجمیعکننده PSP جریان مییابند، برداشتها از صف تأیید دستی عبور میکنند — بنابراین این نسبت را بهتر است اینگونه بخوانیم: «پلتفرم یک جریان پول دوطرفه متعادل را حفظ کرده است، بهطوریکه پرداخت به تریدرها در هر پنجره مشخص کمی بیشتر از مبلغی بوده که واریز میکردهاند.» این تصویر خوبی از نگهداشت برای یک دفتر معاملات خُردهفروشی فارکس با محوریت IB است.
در اوج عملیاتی در اواخر سال اول، CRM بیش از 1,100 وظیفه داخلی در ماه را پردازش میکرد — تأیید ثبتنام، بررسیهای KYC، تأیید واریز، تأیید برداشت، افتتاح حسابهای IB، تیکتهای پشتیبانی — که همگی از طریق یک موتور گردشکار هدایت میشدند. همان موتور همچنان در Region پس از انتقال، حجم کمتر اما پایدارتری را مدیریت میکند.
این تعامل، شفافترین نمایش ما از این است که معماری Regions در Kenmore Design برای چه چیزی ساخته شده است. داستان این نیست که «ما یک CRM ارائه دادیم». اکثر فروشندگان CRM میتوانند یک CRM ارائه دهند. داستان این است که:
سرعت در راهاندازی. Region نخست مشتری حدود سه هفته پس از قرارداد بهصورت عملیاتی فعال شد. Region دوم آنها — یک برند کاملاً جداگانه روی یک سرور MT جداگانه با مجموعهای جداگانه از PSP — حدود شش هفته پس از شروع پروژه تا تکمیل QA بهصورت عملیاتی فعال شد.
تکامل برند بدون بازپلتفرمکردن. وقتی فرضیه go-to-market مشتری تغییر کرد، مهاجرت نکردند. آنها یک Region اضافه کردند، آن را مقیاس دادند و اجازه دادند Region قبلی بهطور طبیعی با جابهجایی IBها و تریدرها بهتدریج جمع شود. بدون مهاجرت داده، بدون آموزش مجدد اپراتورها، بدون downtime.
یک تیم عملیات برای چندین برند. همان CRM، همان کارکنان ادمین، همان گردشکارها، همان پایپلاین KYC همزمان به دو Region خدمت میدادند — و در رابطه گستردهتر، به شش مورد خدمت دادهاند.
ریتم پایدار توسعه سفارشی. محصول استاندارد پلتفرم لازم نیست از همان ابتدا کاملاً بینقص باشد. اعتبارسنجیهای سفارشی، گردشکارهای محدودهمحور، handlerهای نرخ ارز ثابت، منطق پرداختِ مخصوص PSP، و مجموعهای بلند از بهبودهای کوچک در بازهای از چند روز تحویل شدهاند. مشتری سالهاست که ارزش سفارشی را انباشته میکند.
مقیاسپذیری عملیاتی تحت فشار. پلتفرم یک جهش 68× در حجم ماهانه واریز در یک Region را جذب کرد و سپس در Region دیگری نیز بهطور جداگانه نزدیک به اوج را تجربه کرد — همزمان، روی زیرساخت مشترک، بدون هیچ بازطراحی معماری در این بین.
این همان چیزی است که وقتی یک کارگزاری فارکس دیگر CRM را یک استقرار ثابت نمیبیند و شروع میکند آن را بهعنوان یک پلتفرم تکامل برند نگاه کند، به نظر میرسد.
| شاخص | مقدار |
|---|---|
| زمان عملیاتی شدن (اولین Region) | حدود 3 هفته |
| زمان عملیاتی شدن Region دوم | حدود 6 هفته |
| حجم ماهانه اوج واریز نسبت به پایه | 68× |
| اوج Region دوم نسبت به پایه | 43× |
| برندهای منطقهای فعال که روی یک CRM اجرا میشوند | 6+ (در سراسر رابطه گستردهتر) |
| نقاط اتصال متمایز PSP یکپارچهشده از طریق NinjaCharge | 30+ |
| زبانهای پشتیبانیشده | 6 |
| اتصالات سرور معاملاتی MT | 2 (یکی برای هر Region) |
| سهم مشتریان منتسب به IB | حدود 70% |
| نرخ تأیید ایمیل | حدود 89% |
| نرخ تأیید KYC | حدود 33% |
| تبدیل ثبتنامشده → واریزکننده | حدود 19% در مجموع (حدود 31% در Region دوم) |
| میانگین تعداد واریزهای تکمیلشده بهازای هر واریزکننده | 6+ |
| نسبت برداشت به واریزِ معادل USD | حدود 1.34:1 |
| Regionهای همزمان روی یک CRM در طول انتقال | 2 |
| انتقال Region: تغییر برند بدون مهاجرت داده | ✓ |
معماری Regions در Kenmore به کارگزاریها امکان میدهد برندهای جدید را سریع راهاندازی کنند، جایگاهسازی را آزمایش کنند و مخاطبان را منتقل کنند — بدون دست زدن به Backoffice. درباره عملیاتتان با ما صحبت کنید.
چند برند. یک CRM. بدون هیچ مهاجرتی.
