Un club en un solo sistema
Un club deportivo con escuela de pádel, programa infantil, fútbol y quincho llevaba todo en registros informales. Escuchamos a su gente, escribimos las reglas del club y construimos un solo sistema donde cada persona ve su parte.
- Rubro
- Club deportivo y academia de pádel
- El problema
- Necesitaban un sistema online confiable para que la escuela y el programa infantil no se mezclen, que los datos no se crucen entre áreas y dejar de depender de registros informales.
El negocio y su problema
El club tiene dos áreas, pádel y fútbol, una escuela de pádel para adultos, un programa para chicos y un quincho con parrilla que se reserva. Cada parte se llevaba por su lado: cuadernos, mensajes y planillas.
Había un primer prototipo, pero cubría solo el pádel, guardaba los datos en una sola computadora y tenía dos tipos de usuario. No había fútbol, ni stock, ni pedidos de insumos, ni reservas del quincho, ni un historial confiable de quién hizo qué. El club necesitaba un sistema online, que se use desde el celular y desde la compu, donde cada persona entre con su rol y los datos de un área no se crucen con los de otra.
Lo que había y lo que hacía falta
| El prototipo anterior | Lo que el club necesitaba |
|---|---|
| Solo pádel | Pádel y fútbol |
| Datos guardados en una sola compu | Online, en el celular y en la compu |
| Dos tipos de usuario | Seis roles que se combinan |
| Sin stock, insumos ni quincho | Stock, pedidos de insumos y reservas |
| Sin historial | Un historial que no se borra |
Cómo lo analizamos
Primero, una encuesta a tres perfiles del club. Cada pregunta se respondía del 1 al 5, para ver dónde dolía más.
Con las respuestas armé el modelo del club: qué cosas existen (alumnos, clases, áreas, turnos), cómo se relacionan y qué reglas no se pueden romper. Las reglas quedaron escritas en palabras del club, y un glosario fija qué quiere decir cada palabra y cuáles evitar.
Después, cada cosa que el sistema tenía que hacer quedó escrita como un pedido concreto, con sus pruebas.
La encuesta
- Dirección y administración
- Profesores
- Familias del programa infantil
Reglas del club
- Cada chico del programa infantil tiene al menos un tutor responsable.
- Una cuota está al día o pendiente: no hay pagos a medias.
- Cualquiera de los profesores de una clase puede tomar asistencia.
- Pasar del programa infantil a adultos lo decide solo la administración.
Glosario
- Área operativa
- Pádel o fútbol: cada una con sus comunicados, incidencias, limpieza, stock y pedidos.
- Evitar: sección, sector, módulo
- Turno
- La franja del día en que se completa la lista de limpieza de un área.
- Evitar: horario, franja
- Registro de completado
- La constancia de que una tarea se hizo, en qué turno, por quién y a qué hora.
- Evitar: tilde, check
Lo que construimos
Un solo sistema con seis roles, y una persona puede tener más de uno, como un profesor que además es encargado de pádel. Para entrar, cada uno recibe una invitación que vence a las 24 horas.
El stock se calcula con cada entrada y salida, y avisa cuando algo está por agotarse. Los pedidos de insumos siguen siempre los mismos pasos, y el quincho no acepta reservas que se pisen.
Plano del sistema, por partes
Seis roles que se combinan
Administrador, profesor, encargado de pádel, encargado de fútbol, encargado del programa infantil y personal de limpieza.
Clases
Con uno o más profesores, cupo y asistencia, una evaluación técnica del 1 al 10 y una nota mensual.
Áreas de pádel y fútbol
Comunicados, incidencias y la lista de limpieza de cada turno.
Stock y pedidos
Un saldo que sale de cada entrada y salida, con aviso de stock bajo, y pedidos de insumos.
Quincho
Un calendario que no acepta reservas que se pisen.
Programa infantil
Cada chico con sus tutores, y su cuota del mes al día o pendiente.
Un pedido de insumos
- Pendiente
- Recibido
- En proceso
- Cumplido
O termina antes:RechazadoCancelado
El quincho, en una semana
- Reservado
- Tercera reserva: rechazada
Hasta dos reservas por día. La tercera se rechaza, para cualquier rol.
Cómo se controla
Las partes del sistema se construyeron con sus propias pruebas automáticas, y corren solas antes de publicar: si una falla, el cambio no sale.
Los permisos de cada rol los controla el sistema por dentro, no solo la pantalla: lo que un rol no puede ver, no le llega.
Y lo importante queda en un historial que no se borra ni se edita: quién cambió qué, y cuándo.
Antes de publicar
- Las pruebas corren solas antes de publicar
- Si una prueba falla, no se publica
- Los permisos de cada rol, controlados por dentro
- Cada cambio queda en el historial
Cómo terminó
El 17/09/2026 le mostramos el sistema al club y la demo quedó aprobada. En la misma reunión pidieron dos cambios: que la lista de limpieza se reinicie por turno, para saber qué se hizo en cada uno, y que el quincho acepte como máximo dos reservas por día.
Ese mismo día los dos cambios quedaron escritos en la especificación, en el glosario y en una decisión de diseño. Las reservas de las canchas siguen en el sistema que el club ya usaba: quedaron afuera a propósito.
El resultado
- La demo con el club del 17/09/2026 fue aprobada.
- Los dos cambios pedidos en la demo quedaron incorporados el mismo día.
La decisión de ese día
La limpieza se registra por turno.
Cada tarea hecha deja una constancia: en qué turno, por quién y a qué hora. Así el historial de cada turno sale solo, y nada depende de que alguien abra el sistema a la hora justa.
Opciones descartadas
- Una tilde que se borra al cambiar de turno: pierde el historial.
- Copiar la lista entera en cada turno: duplica las tareas.
Un turno cerrado ya no se corrige: lo que se hizo, queda.
Aceptada el 17/09/2026
¿Tu negocio tiene algo parecido?
Contame cómo trabajás hoy. Te respondo con preguntas para entenderlo y, si encaja, con una propuesta por escrito.
Escribime por email