El cliente es un bróker minorista de forex de Sudeste Asiático ya consolidado que atiende a una base de traders regional cuyo origen se concentra abrumadoramente en un solo país: cerca del 97% de los clientes registrados provienen de un único mercado de origen, con un rastro (cola) de traders expatriados en el resto de la región. Su modelo de adquisición depende en gran medida de los IB: aproximadamente siete de cada diez clientes se incorporan a través de una asociación con un Introducing Broker, y un único IB principal ha impulsado cerca de un tercio de todas las transacciones de depósito completadas en la plataforma.
Cuando este cliente se involucró con Kenmore por primera vez años atrás, ya operaba un negocio de forex y buscaba una plataforma capaz de seguir el ritmo de cómo de rápido querían probar nuevas marcas orientadas al mercado. No querían una implementación única. Necesitaban una infraestructura que les permitiera crear, renombrar, descontinuar y relanzar marcas de trading a medida que evolucionaba su tesis de go-to-market, sin replantear la plataforma del back office cada vez.
La primera implementación de Trader’s Room y CRM para este cliente llegó en aproximadamente tres semanas desde el contrato hasta el sistema en producción. La entrega incluyó una Trader’s Room conectada a MetaTrader, un módulo de IB multinivel, integración de NinjaCharge como agregador de pagos, un CRM con flujos de trabajo personalizados para ruteo de ventas y soporte, soporte multilenguaje y una capa de chat en vivo.
La primera marca regional que aparece en el conjunto de datos de este caso práctico se puso en marcha a inicios del Mes 1 del periodo de análisis. Para el Mes 2, el volumen mensual de depósitos había superado el umbral que usamos como línea base para medir el crecimiento indexado. Para el Mes 3, ese volumen se había multiplicado casi por veinte respecto a la línea base. Para el Mes 8, había alcanzado sesenta y ocho veces: el pico operativo.
El CRM de Kenmore se construye en torno a un concepto que el cliente utilizó como palanca central de toda su estrategia de crecimiento: Regions. Una Region es un segmento totalmente aislado y totalmente con marca de la plataforma que se sitúa sobre el mismo back office. Cada Region tiene:
Lo que permanece unificado es el núcleo operativo: un equipo de administración, una capa de reporting, un sistema de tickets, una jerarquía de IB y un pipeline de KYC. El cliente nunca tuvo que elegir entre «queremos una marca nueva» y «queremos mantener productivo a nuestro equipo de operaciones el primer día».
Para este bróker, eso significó que podían probar identidades de marca del mismo modo que la mayoría de las firmas prueban landing pages, y lo hicieron. A lo largo de la relación más amplia, el cliente ha ejecutado seis marcas regionales distintas en la plataforma de Kenmore. Dos de esas marcas son objeto de los datos de este caso práctico: una marca principal que impulsó el lanzamiento y una marca sucesora que el cliente encargó aproximadamente diez meses después para probar un posicionamiento diferente.
El cliente se acercó a nosotros necesitando una Trader’s Room que gestionara la apertura de cuentas en vivo y demo, la carga de documentos de KYC, solicitudes de depósitos y retiros, y autoservicio del trader para información personal e historial de cuenta; todo conectado a un CRM que rutea la actividad entrante al personal adecuado. Entregamos la New Edition Trader’s Room con el CRM embebido en aproximadamente tres semanas. En el pico operativo, el sistema procesaba más de 1.100 tareas internas por mes (aprobaciones de registro, revisiones de KYC, confirmaciones de depósitos, aprobaciones de retiros y aperturas de cuentas de IB) sin una herramienta de tickets independiente.
Los traders del cliente ejecutan en MT. Cada Region en esta colaboración funciona contra su propio servidor de trading MT, configurado de forma independiente. Cuando el cliente quiso añadir la segunda Region, provisionamos una conexión de servicio MT separada para que las dos marcas no compartieran infraestructura de trading aunque compartieran el back office. Los tipos de cuenta, los niveles de apalancamiento y las convenciones de nombres de grupos se definen por Region.
El programa de IB es el canal principal de adquisición del cliente. Casi siete de cada diez traders activos se atribuyen a un IB o sub-IB. Kenmore migró su jerarquía existente de IB multinivel a la nueva plataforma desde el primer día, con seguimiento de URL de referido, reglas de comisiones por niveles, opciones de reparto de beneficios y una vista analítica de «My IBs / My Traders» dentro de la Trader’s Room. El sistema se configuró de modo que una sola línea de IB abarque ambas Regions: el cliente no quería fragmentar el seguimiento de comisiones entre marcas.
NinjaCharge es el agregador de pagos del cliente (una capa de enrutamiento que se sitúa por encima de PSP, no es un PSP en sí). Integramos más de treinta endpoints de PSP detrás de NinjaCharge para canales en moneda local: principalmente VND para el mercado de origen, además de configuraciones para MYR, THB, IDR y BTC para clientes en el resto de la región. La visibilidad de PSP se controla por Region: la segunda Region se puso en marcha con su propio conjunto de PSP seleccionado, distinto del de la primera Region. De los más de treinta endpoints integrados, aproximadamente dos tercios se exponen públicamente en la Trader’s Room en cualquier momento, mientras que el resto se mantiene en reserva.
Los depósitos fluyen a través de NinjaCharge con gestión de devolución (callback) automatizada: el trader ve el estado en tiempo real en la Trader’s Room. Los retiros se ejecutan mediante un flujo de aprobación manual impulsado por tareas en el CRM, con reglas de validación personalizadas que el cliente solicitó (comprobaciones de saldo, salvaguardas de conversión de divisas, verificación del nombre del beneficiario por PSP). Todos los eventos de depósito y retiro generan tareas en el CRM, se rutean al equipo operador adecuado y se retroalimentan en el historial de la cuenta del trader.
El CRM se configura con seis idiomas compatibles, manteniendo la redacción por idioma tanto para la Trader’s Room como para las plantillas de email. La detección del idioma basada en geolocalización cambia el sitio orientado al trader al idioma correcto en la primera visita.
El cliente utiliza operaciones de bono y crédito como parte de su flujo de comisiones de IB y en campañas promocionales. La plataforma permite ajustes de saldo ruteados a través del mismo pipeline de tareas y aprobaciones que los depósitos.
Cada Region incluye sus propios gráficos de marca: logo, paleta de colores, encabezado, pie de página, tipografías y CSS de tema personalizado. Las dos Regions de este conjunto de datos tienen identidades visiblemente distintas; un trader que aterrice en una de ellas no tendría forma de saber que están en el mismo CRM subyacente.
Un hilo de desarrollo a medida continuo se ejecutó en paralelo a la entrega del módulo estándar durante todo el compromiso. El cliente tenía requisitos específicos que el producto estándar no cubría, y Kenmore aplicó correcciones y mejoras con una cadencia típica de días, no de semanas. Ejemplos del registro de desarrollo:
La cadencia de desarrollo a medida es parte de por qué el cliente se ha mantenido en la plataforma durante varios años y múltiples iteraciones de marca: cuando su estrategia de go-to-market evoluciona, la plataforma se adapta en días, no en trimestres.
Aproximadamente en el Mes 10 de la ventana de análisis — cuando la primera Región aún publicaba volúmenes de depósito cerca del máximo — el cliente encargó una segunda Región. El briefing era sencillo: marca separada, dominio separado, servidor MT separado, conjunto de PSP separado, pero gestionado por el mismo equipo en el mismo CRM. Querían seis semanas y obtuvieron seis semanas. El desglose:
Al inicio del Mes 12, la segunda Región estaba registrando a sus primeros traders. Para el Mes 14, había alcanzado la paridad con la primera Región en registros nuevos mensuales. Para el Mes 18, la segunda Región estaba procesando más volumen de depósitos que la primera. Para el Mes 20, la primera Región se había desactivado y la segunda Región estaba gestionando el 100% de todo el negocio nuevo: registros, depósitos y cuentas. La transición ocurrió sin cambios en la plataforma, sin migración de datos y sin reentrenamiento de operadores: el mismo CRM, el mismo equipo de administración, solo se activó una Región diferente.
Este es el caso típico para el que existe la arquitectura de Regiones. La tesis de marca del cliente evolucionó; sus operaciones no tuvieron que hacerlo.
Usando el Mes 2 de la ventana de análisis — el primer mes con actividad de depósitos no trivial — como línea base de índice de 1×:
| Periodo | Índice de volumen de depósitos | Notas |
|---|---|---|
| Mes 1 | 0.04× | Lanzamiento suave |
| Mes 2 | 1.00× | Línea base |
| Mes 3 | 19.67× | Entra la primera cohorte IB |
| Mes 4 | 31.09× | |
| Mes 5 | 32.51× | |
| Mes 6 | 33.63× | |
| Mes 8 | 68.36× | Pico operativo (primera Región) |
| Mes 10 | 33.39× | Pico por número de depósitos (227 en un mes) |
| Mes 11 | 13.30× | Se enfría la primera Región; se encarga la segunda Región |
| Mes 14 | 6.86× | Segunda Región en vivo |
| Mes 17 | 8.38× | La segunda Región supera a la primera |
| Mes 18 | 24.33× | La segunda Región lo lleva |
| Mes 20 | 42.90× | Pico propio de la segunda Región; primera Región desactivada |
La plataforma absorbió dos olas de crecimiento distintas en dos marcas distintas sin cambiar nada por debajo.
Las dos Regiones muestran características de embudo medibles y diferentes:
| Métrica | Primera Región | Segunda Región |
|---|---|---|
| Proporción atribuida a IB | 70.5% | 61.0% |
| Conversión de depósitos (registrado → con depósito) | 17.5% | 31.4% |
| Depósitos promedio por depositante | 6.4 | 5.5 |
La segunda Región convierte a traders registrados en depositantes a una tasa casi el doble que la de la primera Región. Mismo CRM subyacente, mismo equipo de operaciones, misma capa de PSP: marca distinta, mezcla de adquisición distinta, comportamiento de traders distinto. Esa es una señal clara y legible de que la tesis de iteración de marca del cliente estaba funcionando.
En toda la ventana de análisis, las solicitudes de retiro totales equivalen a una proporción aproximada de 1.34:1 en USD frente a los depósitos completados. Tenga en cuenta que los lados de depósito y retiro están denominados en monedas diferentes y se procesan mediante flujos operativos distintos: los depósitos fluyen automáticamente a través del agregador PSP, mientras que los retiros pasan por una cola de aprobación manual; por lo tanto, esta proporción se interpreta mejor como «la plataforma mantuvo un flujo equilibrado de dinero en dos direcciones, con los traders recibiendo pagos a un ritmo ligeramente superior al de lo que depositan en cualquier ventana dada». Esto es una imagen saludable de retención para un libro de forex minorista liderado por un IB.
En el pico operativo de fines del Año 1, el CRM estaba procesando más de 1.100 tareas internas por mes: aprobaciones de registro, revisiones KYC, confirmaciones de depósitos, aprobaciones de retiros, aperturas de cuentas de IB y tickets de soporte, todo canalizado a través de un solo motor de flujo de trabajo. El mismo motor sigue gestionando un volumen más pequeño y estable en la región posterior a la transición.
Esta participación es la demostración más clara que tenemos de para qué está diseñada la arquitectura de Regions de Kenmore. La historia no es «entregamos un CRM». La mayoría de los proveedores de CRM pueden entregar un CRM. La historia es:
Velocidad de salida.La primera Region del cliente estuvo en funcionamiento en aproximadamente tres semanas desde la firma del contrato. Su segunda Region, una marca totalmente separada en un servidor MT distinto con un set de PSP separado, estuvo en funcionamiento en aproximadamente seis semanas desde el inicio hasta que la QA estuvo completa.
Iteración de marca sin necesidad de re-plataformar. Cuando evolucionó la tesis de go-to-market del cliente, no migraron. Agregaron una Region, la escalaron y dejaron que la Region anterior se apagara de forma natural a medida que los IB y los traders se movieron. Sin migración de datos, sin reentrenamiento del personal, sin tiempo de inactividad.
Un solo equipo de operaciones para múltiples marcas.El mismo CRM, el mismo personal de administración, los mismos flujos de trabajo y el mismo pipeline KYC sirvieron simultáneamente a dos Regions; y, en el conjunto más amplio de la relación, han servido a seis.
Cadencia sostenida de desarrollo a medida.El producto estándar de la plataforma no tiene que encajar perfectamente de inmediato. Se han entregado validadores personalizados, flujos de trabajo acotados por región, manejadores de tipo de cambio fijo, lógica de pago específica para PSP y una cola larga de mejoras pequeñas con una cadencia de días. El cliente ha estado acumulando valor personalizado durante años.
Escalado operativo bajo carga.La plataforma absorbió un aumento de 68× en el volumen mensual de depósitos en una Region y luego un pico cercano separado en otra Region: de forma concurrente, en infraestructura compartida, sin rework arquitectónico entre medio.
Así es cuando una corredora de forex deja de pensar en el CRM como una implementación fija y empieza a verlo como una plataforma de iteración de marca.
| Métrica | Valor |
|---|---|
| Tiempo operativo hasta disponibilidad (primera Region) | ~3 semanas |
| Tiempo hasta disponibilidad para la segunda Region | ~6 semanas |
| Volumen pico mensual de depósitos vs. línea base | 68× |
| El pico de la segunda región vs. el nivel base | 43× |
| Las marcas regionales activas funcionan con un único CRM | 6+ (en la relación más amplia) |
| Puntos finales de PSP distintos integrados mediante NinjaCharge | 30+ |
| Idiomas admitidos | 6 |
| Conexiones de servidor de trading de MT | 2 (una por Región) |
| Participación de clientes atribuida a IB | ~70% |
| Tasa de confirmación por correo electrónico | ~89% |
| Tasa de aprobación de KYC | ~33% |
| Conversión de registrado → depositado | ~19% general (~31% en la segunda Región) |
| Depósitos completados promedio por depositante | 6+ |
| Ratio equivalente en USD de retiros respecto a depósitos | ~1.34:1 |
| Regiones simultáneas en el mismo CRM durante la transición | 2 |
| Transición de Región: cambio de marca con migración de datos cero | ✓ |
La arquitectura de Regions de Kenmore permite a las corredurías crear nuevas marcas, probar la propuesta de posicionamiento y migrar audiencias, sin tocar el back office. Hablemos sobre su operación.
Varias marcas. Un CRM. Cero migraciones.
