La meta comercial de las cinco sedes salió de la planilla y ahora viene directo de NextFit
Fitness Academia tiene más de dos décadas de trayectoria y cinco sedes entre Chapecó y Cunha Porã, en Brasil. Los datos de venta ya vivían en NextFit, pero la meta comercial se rehacía a mano en una planilla paralela — con un criterio distinto en cada sede. Epicora construyó la plataforma que lee NextFit cada cinco minutos y lo convierte en una sola lectura: la de la red, la de la sede y la contribución de cada asesora.
- Cliente
- Fitness Academia (Chapecó y Cunha Porã, Brasil)
- Lo que hicimos
- Plataforma de metas comerciales integrada al ERP NextFit — panel de la red, panel por sede y ventas sincronizadas
- Plataforma
- Web responsivo (React · NestJS · MongoDB · AWS + Vercel)
El punto de partida
Fitness Academia es una red de gimnasios con más de dos décadas de actividad y cinco sedes entre Chapecó y Cunha Porã. La operación comercial — prospección, matrículas y renovaciones — la llevan asesoras de venta, y la red ya usaba NextFit como ERP: cada venta, cada plan y cada cancelación ya estaban registrados allí.
El problema no era la falta de datos. Era que el dato no llegaba a quien lo necesitaba. La meta se seguía en una planilla paralela, completada a mano a partir de NextFit — el mismo número, escrito dos veces. Lo que una sede consideraba "venta que cuenta para la meta" no era lo que consideraba otra, así que los números no eran comparables. Y la asesora, que es quien más necesita saber cuánto falta, no tenía ninguna pantalla: dependía de preguntarle al gestor o de abrir una planilla compartida que además exponía el desempeño de todas.
- Meta rehecha a mano en una planilla, a partir de un dato que ya existía en NextFit — puro retrabajo, con errores de tipeo y un número siempre desactualizado.
- Un criterio distinto por sede: lo que contaba para la meta variaba, y los números no cuadraban entre sí.
- Asesora sin autonomía: para saber cuánto faltaba dependía del gestor o de su planilla.
- Una planilla compartida no aísla a nadie — el desempeño de todas quedaba a la vista de todas.
- Sin visión de red: el gestor comparaba cinco planillas en lugar de mirar un número.
El giro
Epicora no construyó un segundo lugar para cargar ventas. La decisión de arquitectura fue la opuesta: NextFit sigue siendo la única fuente de verdad y la plataforma nunca acepta carga manual. Un job lee la API de cada sede cada cinco minutos y espeja las ventas en la base de la aplicación, y es sobre ese espejo que trabaja cada pantalla — ninguna consulta el ERP en vivo. Eso dio dos cosas a la vez: lectura instantánea para el usuario y una integración que no sobrecarga el ERP del cliente.
Antes de escribir la integración, Epicora hizo un spike técnico contra la API real para descubrir lo que la documentación no decía: el límite de requests que NextFit tolera de hecho y cómo llega cada tipo de venta en el payload. Ese spike definió la frecuencia de sincronización y la regla de clasificación — y por eso la integración no se rompió al escalar a las cinco sedes.
La segunda decisión estructural vino de una revisión de alcance con el cliente: la meta es de la sede, no de la asesora. Cada sede tiene una meta mensual y cada asesora ve su contribución al número colectivo — no una cuota individual. Eso cambió el producto entero, y la red pasó a tener un número que significa lo mismo en las cinco sedes.
La decisión que lo desbloqueó
Definir que solo la venta de plan cuenta para la meta — y que el resto ni aparece. Los convenios tipo gym-pass, el producto suelto y la clase suelta se siguen importando para historial, pero no suman ni ensucian ninguna pantalla. Así terminó la divergencia: toda venta que aparece en la plataforma es, por definición, una venta que cuenta. Ya no existe el "depende de cómo lo cuentes".
Lo que entregamos
El panel de la red — cinco sedes en una pantalla
Meta de la red, realizado, porcentaje de cumplimiento y cuántas sedes alcanzaron la meta en el mes, con la lista ordenada por cumplimiento — la peor primero, porque el gestor no necesita la confirmación de quien va bien, necesita saber dónde entrar. Al lado, la curva del mes contra la línea de la meta, para ver si el ritmo del día 10 sostiene el cierre del día 31.
El panel de la sede — la pantalla que la asesora no tenía
Anillo de progreso de la meta de la sede, cuánto falta, días restantes y un bloque "tu contribución" con lo que esa asesora sumó al total. Ve el conjunto de su propia sede — meta, realizado y la contribución de sus compañeras — y nunca ve otra sede.
Ventas sincronizadas, con la corrección en manos del gestor
Todas las ventas de plan que llegan de NextFit, con búsqueda, filtros por período, sede y asesora, detalle de la venta y exportación en CSV y PDF. Una venta cancelada en el ERP aparece como cancelada por sí sola. Y porque la vida real pasa, el administrador tiene un toggle por venta para forzar si cuenta o no para la meta — el caso del socio transferido entre sedes o de la carga en la sede equivocada.
Metas, sedes y un log de sincronización auditable
Alta de meta por sede y mes, con bloqueo estructural contra dos metas en el mismo período. Cada sede tiene su propia clave de API, con prueba de conexión y sincronización manual a demanda. Y cada ejecución del job queda registrada con duración y resultado — cuántos registros leídos, nuevos y actualizados — de modo que "¿por qué cambió este número?" es una pregunta con respuesta.
Cómo lo garantizamos
Aislamiento entre sedes, no solo entre pantallas
Dos perfiles — administrador y colaborador — y el aislamiento del colaborador vale en todas partes: ni por URL manipulada, ni por filtro, ni por exportación un colaborador alcanza datos de otra sede. El alcance se aplica en el backend, no se esconde en el frontend. Autenticación con JWT y refresh token, invitación por e-mail y política de contraseña fuerte validada en ambas puntas.
Una integración que respeta el ERP del cliente
La clave de API de cada sede se guarda cifrada. La sincronización es incremental y paginada, con backoff y throttle adaptados al límite real de NextFit — descubierto en el spike, no supuesto. Como todas las pantallas leen la base local, un pico de uso de la plataforma no se convierte en un pico de requests al ERP. Y el log muestra la red entera sincronizada en la misma ventana de cinco minutos: cinco de cinco sedes.
QA independiente con autoridad para rechazar
La entrega pasó por el QA propio de Epicora, a cargo de alguien que no escribió el código — y que la rechazó tres veces antes de aprobarla. La tercera ronda encontró el tipo de bug que solo aparece en uso real: el filtro por período armaba la ventana del día en UTC y, como la operación corre en horario de Brasilia, la venta de la última hora de la noche caía al día siguiente. Corregido calculando los extremos del día en horario local. Solo después se presentó el sistema al cliente.
El resultado
En el primer mes completo con la plataforma en el aire, la red cerró en 104% de la meta, con cuatro de las cinco sedes alcanzando su número. La plataforma no vende por el equipo — quienes vendieron fueron las asesoras. Lo que cambió es que, por primera vez, ese porcentaje salió del sistema y no de una planilla: vino de ventas leídas directo de NextFit, con un criterio único y cada sincronización registrada y auditable.
Y la adopción se ve en la propia base: el cliente creó solo los quince accesos de la operación en las semanas siguientes a la entrega, y ya tiene meta cargada hasta diciembre — planificación de semestre hecha dentro de la herramienta, no en una pestaña nueva de planilla.
Soluciones relacionadas
Casos relacionados
¿El dato que necesitás ya está en tu sistema, pero no es legible?
Epicora conecta lo que tu operación ya usa y lo convierte en la lectura que exige la decisión: un solo número, actualizado solo, igual para todos.