Клиент — уже работающий розничный форекс-брокер в Юго-Восточной Азии, обслуживающий региональную базу трейдеров, которая в основном сосредоточена в одной стране: почти девяносто семь процентов зарегистрированных клиентов приходится на один внутренний рынок, а в остальных странах региона — длинный хвост экспатов-трейдеров. Их модель привлечения сильно завязана на IB: примерно семь из десяти клиентов подключаются через партнерство с Introducing Broker, а один топ-IB обеспечил примерно треть всех завершенных транзакций пополнения на платформе.
Когда клиент впервые подключился к Kenmore несколько лет назад, он уже вёл форекс-бизнес и искал платформу, которая справится с тем, как быстро он хотел тестировать новые бренды, ориентированные на рынок. Ему не нужна была разовая постановка. Ему требовалась инфраструктура, чтобы он мог запускать, переименовывать, выводить из оборота и повторно запускать торговые бренды по мере развития своей go-to-market гипотезы — без необходимости каждый раз перевыстраивать back office на новую платформу.
Первое развертывание Trader’s Room и CRM для этого клиента заняло примерно три недели — от контракта до работающей системы. Поставка включала Trader’s Room, подключенную к MetaTrader, модуль IB с несколькими уровнями, интеграцию NinjaCharge как платежного агрегатора, CRM с настраиваемыми рабочими процессами для маршрутизации продаж и поддержки, поддержку нескольких языков и слой live chat.
Первый региональный бренд, который проходит через датасет этого кейса, вышел в эфир в начале первого месяца окна анализа. К концу второго месяца объем ежемесячных пополнений прошел порог, который мы используем как базу для измерения индексированного роста. К третьему месяцу этот объем увеличился почти в двадцать раз относительно базы. К восьмому месяцу он достиг шестидесяти восьми раз — операционного пика.
CRM Kenmore построена вокруг концепции, которую клиент использовал как главный рычаг всей своей стратегии роста: Regions (регионы). Region — это полностью изолированный, полностью брендированный сегмент платформы, который работает поверх того же back office. Каждый Region имеет:
Единым остается операционное ядро: одна админ-команда, один слой отчетности, одна система тикетов, одна иерархия IB, один KYC-процесс. Клиенту не пришлось выбирать между «мы хотим новый бренд» и «мы хотим, чтобы наша операционная команда была продуктивной уже в первый день».
Для этого брокера это означало, что он мог тестировать идентичности брендов так же, как большинство компаний тестируют посадочные страницы — и он это сделал. В рамках более широких отношений клиент провел через платформу Kenmore шесть отдельных региональных брендов. Два из них — предмет данных в этом кейсе: основной бренд, который обеспечил запуск, и бренд-последователь, который клиент заказал примерно через десять месяцев, чтобы протестировать другую позиционирование.
Клиент обратился к нам с запросом на Trader’s Room, который будет обрабатывать открытие реальных и демо-счетов, загрузку документов KYC, запросы на пополнение и вывод средств, а также самообслуживание трейдера для личной информации и истории аккаунта — всё это должно быть связано с CRM, которая маршрутизирует входящую активность нужным сотрудникам. Мы поставили New Edition Trader’s Room со встроенной CRM примерно за три недели. К операционному пику система обрабатывала более 1,100 внутренних задач в месяц — одобрения регистрации, проверки KYC, подтверждения пополнений, одобрения выводов и открытие IB-аккаунтов — без отдельного инструмента для тикетов.
Трейдеры клиента исполняют сделки в MT. Каждый Region в этом взаимодействии работает со своим собственным MT-сервером, настроенным независимо. Когда клиент захотел добавить второй Region, мы выделили отдельное подключение MT-сервиса, чтобы два бренда не делили торговую инфраструктуру, даже при том что они используют один и тот же back office. Типы аккаунтов, уровни плеча и соглашения об именовании групп определяются для каждого Region.
Программа IB — основной канал привлечения клиента. Почти семь из десяти активных трейдеров относятся к IB или sub-IB. В первый же день Kenmore перенесла их существующую иерархию IB с несколькими уровнями на новую платформу, с отслеживанием referral-URL, правилами комиссий по уровням, опциями распределения прибыли и аналитическим представлением «My IBs / My Traders» внутри Trader’s Room. Система была настроена так, что одна и та же цепочка IB охватывает оба Region — клиент не хотел фрагментировать отслеживание комиссий между брендами.
NinjaCharge — платежный агрегатор клиента (слой маршрутизации, который находится над PSP, но сам по себе не является PSP). Мы интегрировали более тридцати PSP-эндпоинтов за NinjaCharge для платежных потоков в локальных валютах — прежде всего VND для домашнего рынка, а также конфигурации для MYR, THB, IDR и BTC для клиентов в других странах региона. Видимость PSP контролируется по Region: второй Region вышел в эфир со своим собственным подбором PSP, отличным от набора первого Region. Из более чем тридцати интегрированных эндпоинтов примерно две трети в любой момент публично доступны в Trader’s Room, а остальные зарезервированы.
Пополнения проходят через NinjaCharge с автоматической обработкой callback — трейдер видит статус в реальном времени в Trader’s Room. Выводы выполняются через задаче-ориентированный ручной workflow одобрения в CRM с настраиваемыми правилами валидации, которые запросил клиент (проверки баланса, ограничения на конвертацию валют, подтверждение имени получателя через PSP). Все события пополнения и вывода создают задачи в CRM, маршрутизируются в нужную группу операторов и затем возвращаются в историю аккаунта трейдера.
CRM настроена на шесть поддерживаемых языков, при этом формулировки сохраняются по каждому языку как для Trader’s Room, так и для шаблонов писем. Гео-определение языка переключает сайт для трейдера на правильный язык при первом посещении.
Клиент использует операции с бонусами и кредитами как часть потока комиссий IB и для промо-кампаний. Платформа поддерживает корректировки баланса, которые маршрутизируются через тот же конвейер задач и одобрений, что и пополнения.
Каждый Region содержит собственную бренд-графику — логотип, палитру цветов, шапку, подвал, шрифты и CSS кастомной темы. У двух Region из этого датасета визуально разные идентичности: трейдер, попадающий на один из них, не сможет понять, что они опираются на один и тот же базовый CRM.
Непрерывная разработка по индивидуальному заказу велась параллельно стандартной поставке модуля на протяжении всего проекта. У клиента были конкретные требования, которые стандартный продукт не покрывал, и Kenmore в типичном для нас цикле выполнял исправления и доработки в течение дней, а не недель. Примеры из журнала разработки:
Цикл разработки по индивидуальному заказу — одна из причин, почему клиент оставался на платформе на протяжении нескольких лет и нескольких итераций бренда: когда их go-to-market менялся, платформа адаптировалась за дни, а не за кварталы.
Примерно на 10-м месяце в окне анализа — когда первый Region все еще размещал депозиты почти на пике — клиент заказал второй Region. Техническое задание было простым: отдельный бренд, отдельный домен, отдельный MT-сервер, отдельный набор PSP, но управление тем же набором команд в той же CRM. Хотели шесть недель — получили шесть недель. Разбивка:
К началу 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 свернут |
Платформа поглотила две отдельные волны роста на двух разных брендах, не меняя ничего внизу.
Оба 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, а выводы — через очередь ручного одобрения — поэтому это соотношение лучше читать так: «платформа поддерживала сбалансированный двухсторонний денежный поток, при котором трейдеры получали выплаты с темпом чуть выше того, что они вносят в рамках любого заданного окна». Это здоровая картина удержания для розничного forex-бизнеса, возглавляемого IB.
На операционном пике в конце 1-го года CRM обрабатывала более 1 100 внутренних задач в месяц — одобрения регистрации, проверки KYC, подтверждения пополнений, одобрения выводов, открытия IB-аккаунтов, тикеты поддержки — всё направлялось через один движок рабочих процессов. Тот же движок продолжает обслуживать меньший, более стабильный объем в регионе после перехода.
Это самое чистое доказательство того, для чего архитектура Regions от Kenmore. Сюжет не в том, что «мы выпустили CRM». Большинство вендоров CRM могут поставлять CRM. Сюжет в том, что:
Скорость запуска. Первая Region клиента заработала примерно через три недели после подписания контракта. Вторая Region — полностью отдельный бренд на отдельном MT-сервере с отдельным набором PSP — заработала примерно за шесть недель от старта до завершения QA.
Итерации бренда без перенастройки платформы. Когда тезис go-to-market клиента изменился, они не мигрировали. Они добавили Region, нарастили его и естественным образом дали предыдущей Region затихнуть по мере того, как IB и трейдеры перешли. Никакой миграции данных, никакого переобучения операторов, никакого простоя.
Одна команда по операциям для нескольких брендов. Та же CRM, те же администраторы, те же сценарии, тот же конвейер KYC обслуживали две Regions одновременно — и в рамках более широких отношений обслужили шесть.
Постоянный цикл кастомной разработки. Стандартный продукт платформы не обязан идеально подходить «из коробки». Кастомные валидаторы, сценарии, привязанные к региону, обработчики фиксированных курсов, логика выплат для конкретных PSP и длинный хвост небольших улучшений поставлялись в темпе дней. Клиент на протяжении лет наращивает ценность за счет кастомных доработок.
Операционное масштабирование под нагрузкой. Платформа выдержала увеличение ежемесячного объема пополнений в одном Region в 68×, а затем — отдельный почти-пиковый рост в другом Region — параллельно, на общей инфраструктуре, без какой-либо переработки архитектуры между этим.
Вот как выглядит момент, когда форекс-брокер перестает воспринимать CRM как фиксированное развертывание и начинает считать ее платформой для итераций бренда.
| Метрика | Значение |
|---|---|
| Операционный time-to-live (первая Region) | ~3 недели |
| Time-to-live для второй Region | ~6 недель |
| Пиковый ежемесячный объем пополнений относительно базового | 68× |
| Пиковые значения второго региона vs. базовый уровень | 43× |
| Активные региональные бренды работают в рамках одного CRM | 6+ (в рамках более широкой взаимосвязи) |
| Отдельные конечные точки PSP, интегрированные через NinjaCharge | 30+ |
| Поддерживаемые языки | 6 |
| Подключения торговых серверов MT | 2 (по одному на каждый Регион) |
| Доля клиентов, приписанных IB | ~70% |
| Доля подтверждения по email | ~89% |
| Доля одобрения KYC | ~33% |
| Конверсия «зарегистрирован → пополнил» | ~19% в целом (~31% во втором регионе) |
| Среднее число завершённых депозитов на одного депозитора | 6+ |
| Соотношение снятия средств к депозитам (эквивалент в USD) | ~1.34:1 |
| Одновременная работа регионов в рамках одного CRM в период перехода | 2 |
| Переход региона: смена бренда без миграции данных | ✓ |
Архитектура регионов Kenmore позволяет брокерским компаниям запускать новые бренды, тестировать позиционирование и переносить аудитории — не затрагивая бэк-офис. Расскажите нам о вашей операционной модели.
Несколько брендов. Один CRM. Никаких миграций.
