GIMNASIOS · ENTRENAMIENTO PERSONAL · BONOS · AUTOMATIZACIÓN CON IA
Cómo automatizar sesiones de entrenamiento personal, bonos y renovaciones en un gimnasio
Un socio compra diez sesiones de entrenamiento personal. Reserva una, la mueve dos veces y finalmente el entrenador cancela. La agenda muestra una cita anulada, recepción cree que quedan dos sesiones y el entrenador asegura que queda una. Automatizar la gestión de bonos de entrenamiento personal no consiste solo en reservar citas: consiste en conseguir que compra, agenda, sesiones realizadas y sesiones que aún quedan cuenten la misma historia.
La unidad real de control no es el bono ni la cita: es cada sesión y su efecto sobre lo que el socio todavía puede utilizar.
Un sistema fiable debe saber qué producto compró el socio, cuántas sesiones incluye, qué reservas existen, qué ocurrió finalmente con cada cita y si esa situación debe descontar una sesión según la política del centro. La IA puede interpretar mensajes, resumir contexto y detectar contradicciones; las sesiones disponibles, el pago y la consecuencia de una cancelación deben confirmarse mediante datos y reglas autorizadas.
El problema aparece cuando la agenda y las sesiones restantes cuentan historias distintas
El entrenamiento personal suele combinar dos lógicas que funcionan bien por separado y pueden fallar al conectarse. Por un lado está la agenda: entrenador, fecha, hora, cambios y resultado de la cita. Por otro está el servicio comprado: una sesión individual, un bono de varias sesiones, un plan mensual u otra modalidad que da derecho a recibir una cantidad o tipo de sesiones.
Con pocos clientes, recepción o el entrenador pueden recordar cuántas sesiones quedan. Al crecer el volumen, las cancelaciones, reprogramaciones, compras anticipadas y correcciones hacen que esa memoria deje de ser fiable.
Ejemplo práctico
Un socio compra un bono de diez sesiones. Ha realizado siete. La octava se reservó, luego se movió a otra fecha y finalmente se canceló porque el entrenador no podía asistir. Si la primera reserva descontó una sesión y la reprogramación creó otra cita sin corregir la anterior, el sistema puede mostrar ocho o nueve sesiones utilizadas aunque solo se hayan realizado siete.
La pregunta útil no es “¿cuántas citas aparecen en el calendario?”. Es “¿qué sesiones se han realizado, qué excepciones han ocurrido y cuántas sesiones puede seguir utilizando el socio según las reglas del servicio que compró?”
Esta pieza profundiza en un tramo concreto del recorrido operativo de un gimnasio. No trata rutinas, técnica, intensidad ni decisiones deportivas. El foco es la gestión administrativa y comercial alrededor de un servicio de entrenamiento personal.
De la compra del bono a la sesión realizada y registrada
Para automatizar este proceso conviene seguir una sesión concreta desde el momento en que nace el derecho a utilizarla hasta que queda correctamente reflejada en el historial.
Se vende o activa el servicio.
El socio adquiere una sesión, un bono, un paquete o un plan. El sistema debe conservar qué producto es, cuántas sesiones incluye, cuándo entra en vigor y qué reglas comerciales le afectan.
Quedan disponibles las sesiones correspondientes.
La compra debe traducirse a una cantidad que el sistema pueda consultar. Si el software del gimnasio ya controla esas sesiones, no tiene sentido crear un contador paralelo en una hoja o en la propia automatización.
Se reserva una cita.
Se vinculan socio, entrenador, fecha y hora. Puede comprobarse que exista derecho a reservar, pero crear la cita no debería confundirse automáticamente con haber utilizado la sesión.
La cita puede cambiar antes de celebrarse.
Puede reprogramarse, cancelarse, pasar a otro entrenador o quedar afectada por una incidencia. El sistema debe conservar la relación con la misma sesión o con el mismo derecho de uso cuando corresponda.
Se registra qué ocurrió.
La sesión puede quedar realizada, cancelada, reprogramada, con ausencia del socio, anulada por el centro o pendiente de aclaración.
Se aplica la regla del gimnasio.
El resultado de la cita determina si debe descontarse una sesión, conservarse, devolverse o enviarse a revisión. La consecuencia depende de una política explícita, no de una inferencia improvisada.
Se actualizan las sesiones restantes.
El historial debe permitir reconstruir por qué quedan tres, dos o ninguna. Una corrección posterior debe modificar el estado sin borrar lo que ocurrió.
Se trata la vigencia y la continuidad.
Si quedan pocas sesiones, se acerca una fecha límite o el socio quiere continuar, puede abrirse una acción informativa o comercial basada en el estado real.
Esta secuencia es deliberadamente distinta de la gestión de reservas de clases colectivas. En una clase importan capacidad, plazas y listas de espera. En entrenamiento personal la relación central es entre una cita concreta, un entrenador y el derecho individual del socio a utilizar una sesión.
Producto, compra, sesiones disponibles, reserva y sesión realizada son cosas relacionadas, pero no equivalentes
Automatizar el entrenamiento personal exige diferenciar producto, compra, sesiones disponibles, reserva y resultado de cada cita para evitar inconsistencias tras cancelaciones, reprogramaciones o correcciones.
Muchos errores aparecen al intentar representar compra, vigencia, sesiones disponibles y citas con un único campo como “bono activo”.
| Elemento | Qué representa | Qué no demuestra por sí solo |
|---|---|---|
| Producto o bono | Lo que el gimnasio ofrece: una sesión, 5 sesiones, 10 sesiones, un plan periódico u otra modalidad. | Que una persona concreta lo haya comprado o pagado. |
| Compra | La operación comercial que da al socio derecho a utilizar el servicio. | Que todas las sesiones estén ya reservadas o realizadas. |
| Sesiones disponibles | Cuántas sesiones puede seguir utilizando según el sistema que controla el producto. | Por qué quedan exactamente esas sesiones si no existe historial. |
| Reserva | Una cita con fecha, hora y entrenador. | Que la sesión se haya realizado. |
| Resultado de la cita | Qué ocurrió: realizada, reprogramada, cancelada, ausencia u otra situación definida. | La consecuencia económica si la política no está configurada. |
| Sesión descontada | Que el sistema ha reducido en una unidad las sesiones que el socio puede utilizar. | Que la decisión haya sido correcta si no sabemos qué regla se aplicó. |
| Caducidad o vigencia | Hasta cuándo puede utilizarse el servicio cuando exista una condición de este tipo. | Qué hacer ante una excepción o extensión autorizada. |
| Renovación o recompra | Una nueva operación comercial o un nuevo ciclo de servicio. | Que el pago esté confirmado si el modelo requiere cobro. |
Software como Mindbody documenta APIs separadas para citas, horarios de personal, compras y cuenta del cliente, historial de visitas, paquetes y tipos de sesión. Eso no significa que todos los softwares representen el entrenamiento personal de la misma manera. Sí demuestra algo importante: en un sistema real, estos elementos pueden existir como objetos distintos y conviene integrarlos respetando esa separación.
Reservar una sesión no significa que deba descontarse en ese momento
Una cita futura todavía puede cambiar. Por eso, el evento que crea la reserva y el evento que confirma su efecto sobre las sesiones disponibles no deberían confundirse por defecto.
Eso no obliga a descontar siempre después de la sesión. Algunos sistemas pueden reservar provisionalmente una unidad al crear la cita y devolverla si procede; otros descuentan cuando la sesión queda realizada. Lo importante es que la regla sea explícita y reversible cuando sea necesario.
Automatización frágil
Cada nueva cita resta una sesión. Si se reprograma, se crea otra cita y vuelve a restar. Después alguien corrige manualmente el número cuando el socio reclama.
Automatización controlada
La reserva conserva su relación con el servicio comprado. El resultado de la cita activa una regla definida y cualquier corrección deja historial.
La pregunta correcta es: ¿qué evento confirma que esta sesión debe contar como utilizada? La respuesta puede ser una sesión marcada como realizada por el entrenador, un cierre administrativo, una señal de asistencia suficientemente fiable o una regla automática que combine estado y ausencia de excepciones.
No hace falta imponer un único modelo. Hace falta que el gimnasio pueda explicar por qué una sesión se descontó y que esa explicación salga del sistema, no de la memoria de una persona.
Cancelación, reprogramación y ausencia necesitan rutas distintas
En entrenamiento personal, dos citas que terminan sin celebrarse pueden tener consecuencias comerciales muy diferentes. La automatización debe aplicar la política que el centro haya definido y evitar “resolver” por intuición.
Reprogramación
Cambia fecha u hora, pero normalmente sigue siendo la misma necesidad de servicio. No debería generar dos descuentos por crear una nueva cita.
Cancelación dentro del plazo
Puede permitir conservar la sesión si así lo establece la política del centro.
Cancelación tardía
Puede tener una consecuencia distinta. El sistema debe conocer el plazo y registrar por qué se aplicó esa regla.
Ausencia del socio
El llamado no-show —no presentarse a la cita— puede descontar o no una sesión según la política vigente.
Cancelación del entrenador o del centro
Necesita una ruta propia. No debería tratarse automáticamente como una ausencia del socio.
Situación dudosa
Si el estado de la cita, la nota del entrenador y el registro administrativo se contradicen, la automatización debe detener la consecuencia y pedir revisión.
La entrada 47 desarrolla en profundidad cancelaciones y no-shows en clases colectivas. Aquí solo nos interesa su efecto sobre una sesión individual de entrenamiento personal y sobre el número de sesiones que siguen disponibles.
La caducidad de un bono también necesita contexto
No existe una duración universal que pueda aplicarse a todos los bonos de entrenamiento personal. El producto puede no caducar, tener una fecha concreta, empezar a contar desde la compra o desde la activación, permitir pausas o contemplar extensiones en determinadas situaciones.
Por eso conviene separar varias fechas:
- Fecha de compra: cuándo se produjo la operación comercial.
- Fecha de activación: cuándo empieza realmente el derecho a utilizar las sesiones, si el modelo las diferencia.
- Fecha límite: hasta cuándo pueden utilizarse cuando el producto tiene vigencia.
- Fecha de cada reserva: algunas citas pueden haberse creado antes del vencimiento y celebrarse después, si la política lo permite.
- Fecha de una extensión autorizada: si existe una excepción, debe quedar quién la aprobó, por qué y qué cambió.
Una automatización puede avisar cuando se acerca el vencimiento, pero no debería ampliarlo porque “parece justo” ni inferir excepciones desde una conversación. Las condiciones dependen del producto vendido, del contrato, de la política del gimnasio y de la normativa aplicable.
También puede ocurrir que un socio compre un segundo bono antes de terminar el anterior. En ese caso el sistema debe saber si ambos pueden coexistir, cuál se utiliza primero y cómo afecta la vigencia de cada uno. No conviene imponer una regla FIFO —usar primero lo más antiguo— si el producto real no funciona así.
Renovar no es simplemente volver a poner el contador a diez
Una renovación puede ser una recompra manual, una nueva venta con condiciones diferentes, un nuevo bono antes de que termine el anterior o un plan recurrente que genera un nuevo periodo.
Tratar todas estas situaciones como “añadir diez sesiones” borra información comercial importante: qué se vendió, a qué precio, cuándo se pagó, qué condiciones tiene el nuevo producto y cómo convive con las sesiones anteriores.
Si el gimnasio utiliza un modelo de suscripción recurrente, el pago merece una comprobación adicional. Stripe documenta que una renovación de suscripción genera una factura y que el intento de cobro puede terminar pagado o fallar. Por tanto, que haya llegado la fecha de renovación no significa necesariamente que el nuevo derecho de uso deba darse por pagado y disponible.
Esto conecta con la gestión de cobros fallidos e impagos en gimnasios. Si el pago falla, ese circuito debe encargarse de la recuperación. La entrada 67 solo necesita comprobar el estado económico suficiente para saber si el nuevo bono o periodo puede activarse.
Ejemplo práctico
Queda una sesión del bono actual y el socio acepta comprar otro de diez. El pago está iniciado, pero no confirmado. El nuevo bono no debería aparecer como definitivamente disponible solo porque la venta se haya creado. Una vez confirmado el pago según la arquitectura del centro, el sistema puede activar el nuevo derecho y conservar por separado el historial del bono anterior.
Cuando quedan pocas sesiones, sí puede abrirse una acción comercial: avisar al socio, crear una oportunidad o pedir al entrenador que valore la continuidad comercial. Pero esa lógica no debe convertirse en una campaña de retención indiscriminada. Para inactividad y seguimiento comercial general ya existe la guía de retención de socios inactivos.
La IA puede entender lo que pide el socio; no debería decidir cuántas sesiones le quedan
En este proceso hay mucho lenguaje libre. El socio escribe “me quedan dos”, “quiero mover la sesión del jueves”, “el entrenador me canceló” o “quiero comprar otro bono”. El entrenador puede dejar una nota breve y recepción puede recibir la incidencia por teléfono.
La IA aporta precisamente en esa capa de interpretación. Puede convertir una petición poco estructurada en datos que la automatización pueda contrastar con los sistemas reales.
Interpretar solicitudes
Distinguir si el socio quiere reservar, mover, cancelar, consultar las sesiones restantes, preguntar por vigencia o renovar.
Extraer contexto
Identificar fecha mencionada, entrenador, bono o referencia de una sesión cuando el mensaje aporta suficiente información.
Resumir historial
Preparar para recepción o coordinación una síntesis de compras, reservas, cambios y discrepancias relevantes.
Detectar contradicciones
Señalar que el socio afirma que le quedan dos sesiones mientras el sistema muestra una, sin decidir automáticamente quién tiene razón.
Preparar comunicaciones
Redactar una confirmación de cambio, un aviso de próxima caducidad o una propuesta de renovación usando únicamente información confirmada.
Agrupar incidencias
Clasificar motivos de cancelación o problemas operativos para detectar patrones, sin convertirlos en diagnósticos de salud o abandono.
La IA no debería:
- Inventar cuántas sesiones quedan.
- Marcar una sesión como realizada porque una nota sea ambigua.
- Decidir que una cancelación debe descontar una sesión sin una política explícita.
- Extender una fecha de vigencia por criterio propio.
- Crear descuentos o condiciones comerciales no autorizadas.
- Dar por pagada una renovación sin confirmación del sistema económico.
- Inferir lesiones, enfermedad o motivos sensibles a partir de ausencias o cancelaciones.
- Decidir rutinas, técnica, intensidad o adecuación del entrenamiento.
En Yarvia planteamos este reparto de funciones de forma deliberada: la IA interpreta; las reglas aplican la política; el software de gestión y la agenda confirman estados; el sistema de pagos confirma cobros; y las personas resuelven excepciones que necesitan criterio.
Qué sistema debe confirmar cada dato
Un gimnasio puede tener un único software que gestione casi todo o varias herramientas conectadas. No hay que asumir una arquitectura concreta. Sí conviene responder una pregunta para cada dato importante: ¿dónde se comprueba antes de responder o actuar?
| Dato | Posible sistema que lo confirma | Error típico |
|---|---|---|
| Producto vendido | Software fitness, ERP/TPV o sistema comercial definido. | Crear manualmente un bono distinto del que figura en la compra. |
| Sesiones disponibles | Objeto de paquete, bono, créditos o derecho de uso del software que lo gestione. | Mantener otro contador en Excel o en el CRM. |
| Reserva y entrenador | Agenda o módulo de citas. | Copiar la cita a otro calendario y perder cambios. |
| Resultado de la cita | Agenda, interfaz del entrenador o flujo de cierre definido. | Asumir que una cita pasada se realizó solo porque nadie la canceló. |
| Pago | Sistema de cobros, facturación o pasarela. | Activar una renovación cuando solo existe una intención de compra. |
| Vigencia | Producto/contrato y software que gestiona las condiciones. | Calcular una fecha en la automatización distinta de la oficial. |
| Seguimiento comercial | CRM o módulo comercial. | Hacer que el CRM se convierta en el lugar donde se decide cuántas sesiones quedan. |
Mindbody expone por API elementos relacionados con citas, compras, paquetes, historial y tipos de sesión; EGYM documenta APIs para miembros, productos, tareas de entrenador y webhooks dentro de su ecosistema. Son ejemplos de que los sistemas fitness pueden ofrecer puntos de integración distintos, no una prueba de que todos los productos tengan el mismo modelo.
La atención automatizada al socio puede responder cuántas sesiones quedan o cuándo es la próxima cita, pero solo si consulta los sistemas que realmente confirman esos datos.
Cuando la agenda y las sesiones disponibles no coinciden, no conviene “arreglar el número” sin reconstruir el historial
Las discrepancias son inevitables en procesos con cambios manuales, integraciones y excepciones. Lo importante es que exista una forma de resolverlas sin borrar pistas.
- Comprobar la compra original. Qué producto se vendió y cuántas sesiones incluía.
- Revisar sesiones realizadas. No solo citas creadas, sino resultados efectivamente registrados.
- Revisar cancelaciones y reprogramaciones. Determinar si alguna cita generó un descuento y luego fue modificada.
- Buscar ajustes manuales. Quién cambió el número de sesiones, cuándo y por qué.
- Comprobar nuevas compras. Puede existir otro bono activo que explique la diferencia.
- Reconciliar el resultado. El sistema debe terminar con un número coherente y con historial suficiente para explicar cómo se obtuvo.
Una corrección manual puede ser válida para resolver una excepción. El problema aparece cuando alguien cambia “2” por “3” y no queda registrado qué sesión se devolvió ni por qué.
Si la automatización falla o el resultado de una escritura es incierto, entra en juego la disciplina de monitorización y reconciliación: comprobar antes de repetir y evitar duplicados. La teoría general de fiabilidad permanece en la guía de monitorización de automatizaciones, mientras aquí aplicamos el principio al caso concreto del entrenamiento personal.
Qué medir para saber si el proceso está realmente más controlado
Un piloto puede empezar con pocos indicadores que muestren si disminuyen las discrepancias y el trabajo administrativo.
Sesiones vendidas y realizadas
Permite observar el recorrido del servicio sin confundir venta con prestación.
Discrepancias detectadas
Casos en los que agenda, historial o sesiones disponibles no coinciden.
Ajustes manuales
Cuántos se hacen, por qué motivo y si se concentran en un tipo de incidencia.
Resultado correctamente registrado
Proporción de citas que terminan con un estado suficiente para aplicar la regla correspondiente.
Bonos próximos a terminar
Casos con pocas sesiones o con una fecha límite próxima y sin siguiente acción definida.
Renovaciones por estado
Propuesta, iniciada, pagada/confirmada o pendiente, sin convertir todas en “renovadas”.
También es útil medir tiempo administrativo dedicado a responder “¿cuántas sesiones me quedan?”, reconstruir cambios o corregir errores. Para convertir estas métricas en impacto económico hace falta una línea base y una atribución razonable; esa metodología se desarrolla en la guía de KPIs de automatización.
Más información no siempre mejora la automatización
El entrenamiento personal puede convivir con notas del entrenador, observaciones físicas o información sensible. Para gestionar agenda, bonos y renovaciones normalmente no hace falta copiar ese contenido al CRM comercial ni incluirlo en cada notificación.
La AEPD explica la protección de datos por defecto como la aplicación de minimización: tratar únicamente los datos necesarios, limitar la extensión del tratamiento, el periodo de conservación y la accesibilidad. En este caso se traduce en decisiones muy concretas:
- Recepción puede necesitar saber que una sesión está cancelada sin acceder a una nota sensible.
- El CRM puede necesitar saber que quedan pocas sesiones para abrir una acción comercial, sin copiar información sobre lesiones.
- La IA que clasifica una petición debería recibir solo el contexto necesario para esa tarea.
- Una ausencia no debe convertirse automáticamente en una inferencia sobre enfermedad, lesión o abandono.
El objetivo no es convertir la gestión de bonos en un proyecto jurídico, sino evitar que una automatización administrativa multiplique datos personales sin necesidad.
Cómo empezaría Yarvia un piloto de entrenamiento personal
No empezaría conectando todas las modalidades, todos los entrenadores y todos los canales. Un primer piloto puede concentrarse en un único tipo de bono que ya tenga suficiente volumen para detectar fricciones.
- Elegir un producto concreto. Por ejemplo, bono de 10 sesiones, sin mezclar inicialmente planes mensuales, sesiones sueltas y promociones especiales.
- Identificar dónde se controlan las sesiones disponibles. Confirmar si el software fitness ya dispone de ese dato y cómo se actualiza.
- Mapear los estados de la cita. Reserva, reprogramación, realizada, cancelada, ausencia y excepción.
- Documentar qué resultado descuenta una sesión. Incluir las políticas de cancelación y las rutas que necesitan revisión.
- Conectar compra, agenda y resultado. Evitar hojas o contadores adicionales salvo que exista una razón técnica clara.
- Introducir IA donde hay lenguaje libre. Mensajes de socios, notas operativas, clasificación de solicitudes y preparación de respuestas.
- Diseñar la reconciliación. Saber qué hacer cuando el sistema dice que quedan dos sesiones y alguien afirma que queda una.
- Definir renovación y pago. Separar propuesta, compra, confirmación económica y activación del nuevo servicio.
- Medir unas semanas. Discrepancias, correcciones, citas sin resultado y trabajo administrativo antes de ampliar el alcance.
Una vez estable, el mismo enfoque puede extenderse a otros bonos, más entrenadores, comunicaciones automáticas y seguimiento comercial. La prioridad no es automatizar el máximo número de pasos, sino conseguir que cada sesión pueda explicarse desde la compra hasta su resultado sin depender de memoria, mensajes sueltos o correcciones opacas.
Preguntas frecuentes sobre automatización de entrenamiento personal y bonos
¿Cómo se puede automatizar la gestión de bonos de entrenamiento personal?
Conectando la compra del servicio, las sesiones disponibles, la agenda, el resultado de cada cita y las reglas de cancelación o renovación. La automatización debe actualizar estados a partir de datos verificables y enviar a revisión los casos ambiguos.
¿Cuándo debe descontarse una sesión de un bono?
No existe una regla universal. Puede descontarse cuando la sesión se marca como realizada, cuando se confirma asistencia o mediante otra condición definida por el gimnasio. Lo importante es que la regla sea explícita y trazable.
¿Qué ocurre si el socio cancela o no se presenta?
Depende de la política del centro. Una cancelación dentro de plazo, una cancelación tardía, una ausencia y una cancelación por parte del entrenador pueden tener consecuencias distintas. La automatización debe aplicar la regla configurada, no decidirla con IA.
¿Cómo evitar que la agenda y las sesiones restantes no coincidan?
Relacionando cada cita con el servicio comprado, registrando el resultado real de la sesión, evitando contadores paralelos y dejando trazabilidad de reprogramaciones y correcciones. También conviene ejecutar comprobaciones periódicas de coherencia.
¿Se puede avisar automáticamente cuando quedan pocas sesiones?
Sí, siempre que el número proceda del sistema que realmente controla el bono o paquete. Ese evento puede generar un aviso, una tarea comercial o una propuesta de renovación adaptada al contexto.
¿Cómo automatizar la renovación de un bono?
Separando la propuesta comercial, la nueva compra, la confirmación del pago cuando sea necesaria y la activación de las nuevas sesiones. Renovar no debería consistir simplemente en modificar manualmente un contador.
¿Puede la IA gestionar reservas y bonos de entrenamiento personal?
Sí, pero no como autoridad sobre los datos. Puede interpretar solicitudes, clasificar mensajes, resumir historiales y preparar comunicaciones. Las sesiones disponibles, los cobros, el resultado de la cita y las reglas de cancelación deben confirmarse en los sistemas y reglas autorizadas.
DIAGNÓSTICO DE AUTOMATIZACIÓN
Revisar cómo se gestionan sesiones, bonos y renovaciones
Si agenda, bonos, sesiones realizadas y renovaciones dependen de hojas, mensajes o correcciones manuales, podemos revisar qué datos controla cada sistema, qué reglas conviene automatizar y dónde puede aportar IA sin perder trazabilidad.
Revisar la gestión del entrenamiento personalFuentes
- Mindbody Developer — API Endpoints.
Documentación oficial sobre elementos disponibles por API, entre ellos citas, horarios del personal, compras y cuenta del cliente, historial de visitas, paquetes y tipos de sesión.
Consultar fuente - EGYM Developer — MMS API V2.
Documentación oficial del ecosistema EGYM sobre gestión de miembros, productos, tareas de entrenador, visitas, webhooks e integraciones. Se utiliza como referencia de capacidades de integración, no como prueba de una función específica de bonos de entrenamiento personal.
Consultar fuente - Stripe — Subscription invoices.
Referencia para los casos en los que la renovación del servicio se implemente mediante suscripción recurrente y sea necesario separar renovación, factura y pago.
Consultar fuente - Stripe — How subscriptions work.
Documentación del ciclo de vida de una suscripción y de sus estados de pago. Solo aplica cuando el modelo comercial del gimnasio utiliza una suscripción recurrente.
Consultar fuente - AEPD — Protección de datos por defecto.
Referencia para minimización de datos, limitación del tratamiento y acceso únicamente a la información necesaria para cada finalidad.
Consultar fuente
Las capacidades concretas dependen del software de gestión, agenda, pasarela de pago, versión, permisos y configuración de cada gimnasio. La documentación real de los sistemas utilizados por el centro debe prevalecer en cualquier implementación.
