שישה מותגים, פלטפורמה אחת: המסע של ברוקראז' מדרום-מזרח אסיה להתאמת מוצר–שוק

אודות הלקוח

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

כאשר הלקוח הזה פנה לראשונה ל-Kenmore לפני שנים, הם כבר הפעילו עסק Forex וחיפשו פלטפורמה שתוכל לעמוד בקצב שבו רצו לבדוק מותגים חדשים הפונים לשוק. הם לא רצו פריסה חד-פעמית. הם רצו תשתית שתאפשר להם להקים, לשנות שם, לסגור ולהשיק מחדש מותגי מסחר ככל שתזה השוק-לשוק שלהם תתפתח — בלי להחליף פלטפורמה של ה-Backoffice בכל פעם.

ההשקה

הפריסה הראשונה של Traders Room ו-CRM עבור הלקוח הזה הושלמה בתוך כשלושה שבועות מחתימת החוזה ועד למערכת חיה. המסירה כללה Traders Room מחובר ל-MetaTrader, מודול IB רב-שכבתי, אינטגרציית NinjaCharge כמאגדת התשלומים, CRM עם תהליכי עבודה מותאמים לניתוב מכירות ותמיכה, תמיכה רב-לשונית, ושכבת צ'אט חי.

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

ארכיטקטורת ה-Regions — למה המהלך הזה היה שונה

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

• דומיין עצמאי הפונה ללקוחות וזהות מותגית ויזואלית משלו;
• חיבור משלו לפלטפורמת המסחר (שרת MT נפרד, קבוצות חשבונות נפרדות);
• כללי מטבע ושערי המרה משלו;
• ניתוב PSP משלו — ניתן להפעיל מעבדי תשלומים שונים לכל Region;
• עיצוב Front-end משלו, Header, Footer ותבניות אימייל;
• כללי Workflow משלו — ניתוב למכירות, תמיכה, הנהלת חשבונות ו-KYC ניתן להגדרה לכל Region;
• הרשאות אדמין משלו — ניתן להגדיר צוות עבור Region אחד או לעבוד באופן גלובלי.

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

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

המודולים שסופקו

הליבה של Traders Room ו-CRM

הלקוח פנה אלינו כשהוא זקוק ל-Traders Room שיטפל בפתיחת חשבונות live ו-demo, בהעלאת מסמכי KYC, בבקשות הפקדה ומשיכה, ובשירות עצמי של הסוחר עבור מידע אישי והיסטוריית חשבון — וכל זאת מחובר ל-CRM שינתח פעילות נכנסת ויוביל אותה לצוות הנכון. סיפקנו את New Edition Traders Room עם ה-CRM המובנה בתוך כשלושה שבועות. בשיא התפעולי, המערכת טיפלה ביותר מ-1,100 משימות פנימיות בחודש — אישורי הרשמה, בדיקות KYC, אישורי הפקדה, אישורי משיכה ופתיחות חשבון IB — בלי כלי טיקטים נפרד.

אינטגרציה עם MetaTrader

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

ניהול IB רב-שכבתי

תוכנית ה-IB היא ערוץ הגיוס העיקרי של הלקוח. כמעט שבעה מתוך עשרה מהסוחרים הפעילים שלהם מיוחסים ל-IB או לתת-IB. Kenmore היגר את היררכיית ה-IB הרב-שכבתית הקיימת שלהם לפלטפורמה החדשה ביום הראשון, עם מעקב אחר כתובות URL של הפניות, כללי עמלות מדורגים, אפשרויות חלוקת רווחים, ותצוגת אנליטיקה "My IBs / My Traders" בתוך Traders Room. המערכת הוגדרה כך ששושלת IB אחת משתרעת על פני שני ה-Regions — הלקוח לא רצה לפצל את מעקב העמלות בין מותגים.

פתרונות תשלום באמצעות NinjaCharge

NinjaCharge הוא מאגד התשלומים של הלקוח (שכבת ניתוב היושבת מעל PSPs, ולא PSP בפני עצמו). שילבנו יותר משלושים נקודות קצה של PSP מאחורי NinjaCharge על פני מסילות במטבע מקומי — בעיקר VND עבור שוק הבית, בתוספת תצורות עבור MYR, THB, IDR ו-BTC עבור לקוחות במקומות אחרים באזור. החשיפה של PSP נשלטת לפי Region: ה-Region השני עלה עם סט PSP משלו, שנבחר בקפידה, שונה מזה של ה-Region הראשון. מתוך יותר משלושים נקודות הקצה המשולבות, בערך שני שלישים מוצגים לציבור ב-Traders Room בכל רגע נתון, והיתר נשמרים כעתודה.

ניהול הפקדות ומשיכות

הפקדות עוברות דרך NinjaCharge עם טיפול אוטומטי ב-callback — הסוחר רואה סטטוס בזמן אמת ב-Traders Room. משיכות עוברות דרך תהליך אישור ידני המבוסס על משימות ב-CRM, עם כללי ולידציה מותאמים שהלקוח ביקש (בדיקות יתרה, מנגנוני הגנה להמרת מטבע, אימות שם המוטב לפי PSP). כל אירוע הפקדה ומשיכה יוצר משימות CRM, מנותב לצוות המפעיל הנכון, ומוזן בחזרה להיסטוריית החשבון של הסוחר.

תמיכה רב-לשונית

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

מערכת בונוס / קרדיט

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

עיצוב אתר

לכל Region יש גרפיקת מותג משלו — לוגו, פלטת צבעים, Header, Footer, פונטים ו-CSS מותאם אישית לעיצוב. שני ה-Regions במאגר הנתונים הזה נבדלים זה מזה בצורה ברורה; סוחר שנוחת על אחד מהם לא יוכל לדעת שהוא נמצא על אותו CRM בסיסי.

פיתוח מותאם אישית

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

• המרת מטבע בשער קבוע עבור VND. הלקוח רצה שהפקדות ומשיכות ייושבו לפי שער VND/USD קבוע שנשלט על ידו, במקום לפי שער שוק חי, והם חזרו לשער הזה כמה פעמים לאורך ההתקשרות. סיפקנו את מטפל השער הקבוע הראשוני בחודש הראשון, ולאחר מכן שחררנו שינויים לעדכון השער לפי דרישה.
• טיפול בשם מקבל התשלום הספציפי ל-PSP. PSP מקומי מסוים דרש ששדה מקבל התשלום יעמוד בפורמט ספציפי השונה משם התצוגה של הסוחר. בנינו עקיפות לשם מקבל התשלום לכל PSP בזרימת המשיכה.
• אימות יתרת המשיכה. הלקוח ביקש אימות מחמיר יותר לפני אישור במשיכות ידניות, כדי לתפוס בקשות מעבר ליתרה לפני שהן מגיעות לתור המפעיל. סופק כמאמת מותאם אישית בתהליך העבודה של משיכות ב-CRM.
• Webhooks להתראות Slack. אירועי הפקדה, משיכה והרשמה בזמן אמת מנותבים ל-Slack הפנימי של הלקוח — webhooks נפרדים לכל Region כך שלצוות התפעול של ה-Region השני יש ערוץ ייעודי משלו.
• כללי מספר טלפון. הלקוח ביצע כמה איטרציות על אימות מספרי טלפון — תחילה נעילה של ייחודיות המספר, לאחר מכן הסרת אילוץ הייחודיות כאשר תוכנית ה-IB דרשה הקלה בכך, והגדרת מינימום של שש ספרות באחד ה-Regions.
• ניהול סוחרים בארכיון. עמוד ניהול ייעודי לבחינה ולהחזרת פרופילי סוחרים מארכיון, כולל החשבונות והיסטוריית ה-KYC שלהם, בנפרד מרשימת הלקוחות הראשית.
• תוכן אימייל להפקדות ומשיכות ידניות. תבניות אימייל מותאמות אישית שהופעלו בהפקדות ידניות ובשינויים במצב משיכה, כאשר מספר החשבון, הסכום והמטבע מוזנים באופן דינמי.
• תהליכי משיכה בהיקף Region. כאשר ה-Region השני הושק, הוא נזקק לזרימת אישור שונה מזו של ה-Region הראשון — מפעילים שונים, כללי ניתוב שונים, ערוצי התראה שונים. בנינו זאת לתוך מנוע התהליכים המודע ל-Region.

קצב הפיתוח המותאם אישית הוא חלק מהסיבה שהלקוח נשאר בפלטפורמה לאורך כמה שנים וכמה איטרציות מותג: כאשר אסטרטגיית ה-go-to-market שלהם משתנה, הפלטפורמה מסתגלת בימים, לא ברבעונים.

ההשקה של ה-Region השני

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

• שבוע 1. גילוי, קליטת גרפיקת המותג, אישורי שרת MT, דרישות ניתוב PSP.
• שבועות 2–4. הקמת Region — הקצאת דומיין, הגדרת mailgun לאימיילים טרנזקציוניים בהיקף ה-Region, חיבור שירות MT, החלת כותרת/תחתית/ערכת עיצוב, הגדרת סוגי חשבון בשרת MT החדש, הפעלת מודול IB רב-שכבתי ל-Region החדש.
• שבוע 5. QA — בדיקות מקצה לקצה של הרשמה, KYC, הפקדה, משיכה וזרימות הפניית IB בוצעו בנפרד מול שני ה-Regions.
• שבוע 6. עלייה לאוויר והעברת ידע למדריך.

עד תחילת חודש 12, ה-Region השני כבר רשם את הסוחרים הראשונים שלו. עד חודש 14, הוא הגיע לשוויון עם ה-Region הראשון במספר ההרשמות החדשות החודשיות. עד חודש 18, ה-Region השני עיבד נפח הפקדות גדול יותר מהראשון. עד חודש 20, ה-Region הראשון נסגר בהדרגה וה-Region השני נשא 100% מכל העסקים החדשים — הרשמות, הפקדות וחשבונות. המעבר התרחש בלי החלפת פלטפורמה, בלי מיגרציית נתונים, בלי הכשרה מחדש של מפעילים: אותו CRM, אותו צוות אדמיניסטרציה, רק Region אחר שהופעל.

זהו מקרה לימוד קלאסי למה ארכיטקטורת ה-Regions נועדה לאפשר. תפיסת המותג של הלקוח התפתחה; התפעול שלו לא נאלץ לעשות זאת.

מה הנתונים אומרים

צמיחת הפקדות, באינדוקס לחודש הבסיס

בהתבסס על חודש 2 של חלון הניתוח — החודש הראשון עם פעילות הפקדה שאינה שולית — כבסיס אינדקס של 1×:

תקופה	אינדקס נפח הפקדות	הערות
חודש 1	0.04×	השקה רכה
חודש 2	1.00×	בסיס
חודש 3	19.67×	סבב ה-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 שני עוקף את הראשון
חודש 18	24.33×	ה-Region השני נושא את זה
חודש 20	42.90×	השיא של ה-Region השני עצמו; ה-Region הראשון נסגר בהדרגה

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

תמהיל רכישה

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

התנהגות סוחרים לפי Region

שני ה-Regions מציגים מאפייני משפך שונים באופן מדיד:

מדד	Region ראשון	Region שני
חלק המיוחס ל-IB	70.5%	61.0%
המרת הפקדה (נרשם → הפקיד)	17.5%	31.4%
ממוצע הפקדות למפקיד	6.4	5.5

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

יחס משיכות להפקדות

לאורך חלון הניתוח המלא, סך בקשות המשיכה מסתכם ביחס שווה-ערך ל-USD של כ-1.34:1 מול הפקדות שהושלמו. שימו לב שצד ההפקדות והמשיכות נקובים במטבעות שונים ומעובדים באמצעות תהליכי עבודה תפעוליים שונים — ההפקדות זורמות אוטומטית דרך אגרגטור ה-PSP, והמשיכות עוברות דרך תור אישור ידני — ולכן את היחס הזה נכון יותר לקרוא כך: "הפלטפורמה שמרה על זרימת כספים דו-כיוונית מאוזנת, כאשר משקיעים מקבלים תשלומים בקצב מעט גבוה יותר ממה שהם מפקידים בכל חלון נתון." זו תמונת שימור בריאה עבור ספר קמעונאי של Forex בהובלת IB.

תפוקה תפעולית בשיא

בנקודת השיא התפעולית בסוף שנה 1, ה-CRM עיבד יותר מ-1,100 משימות פנימיות בחודש — אישורי הרשמה, סקירות KYC, אישורי הפקדה, אישורי משיכה, פתיחת חשבונות IB, קריאות תמיכה — כולן נותבו דרך מנוע תהליכי עבודה אחד. אותו מנוע ממשיך לטפל בהיקף קטן ויציב יותר באזור שלאחר המעבר.

מה זה מוכיח

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

מהירות ההשקה. אזור הראשון של הלקוח עלה לאוויר בתוך כשלושה שבועות מהחתימה על החוזה. אזורו השני — מותג נפרד לחלוטין על שרת MT נפרד, עם סט PSP נפרד — עלה לאוויר בתוך כשישה שבועות מיום ה-kickoff ועד לסיום ה-QA.

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

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

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

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

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

מדדים מרכזיים במבט חטוף

מדד	ערך
זמן עלייה לאוויר תפעולי (אזור ראשון)	~3 שבועות
זמן עלייה לאוויר לאזור שני	~6 שבועות
נפח הפקדות חודשי בשיא לעומת קו בסיס	68×
שיא האזור השני לעומת קו בסיס	43×
מותגים אזוריים פעילים שרצים על CRM יחיד	6+ (לאורך הקשר הרחב יותר)
נקודות קצה נפרדות של PSP שמשולבות דרך NinjaCharge	30+
שפות נתמכות	6
חיבורי שרת מסחר MT	2 (אחד לכל אזור)
חלק הלקוחות המיוחס ל-IB	~70%
שיעור אישור אימייל	~89%
שיעור אישור KYC	~33%
המרה נרשמו → הפקידו	~19% בסך הכול (~31% באזור השני)
ממוצע הפקדות שהושלמו לכל מפקיד	6+
יחס משיכות להפקדות בשווה-ערך ל-USD	~1.34:1
אזורי עבודה במקביל על אותו CRM במהלך המעבר	2
מעבר אזור: החלפת מותג ללא מיגרציית נתונים	✓

---