Classes left
Members see how many rides remain on each pack, with the expiry date beside it, and nothing else to decode.
A customer portal website for dance fitness studios gives members one login for class passes, pause requests, card updates and class history. SIZ Group builds that portal around the questions a front desk hears on a busy weeknight, starting with a free scoping call.
A member on a ten-class pack wants to know how many classes are left and whether the pack expires before the summer. A member on a monthly unlimited plan wants to pause it while a knee recovers, and a parent wants to know whether a birthday party credit can be used on a weekday. Those are small questions, but they reach the desk in the middle of a class, while the instructor is cueing the next track.
A portal answers them on the phone the member already has in their gym bag. It works best as a short list of what the member can do, backed by clear pass rules, and it leaves judgment calls with the studio team. The aim is fewer interruptions during the hour, not a locked account page that feels like a bank statement.
Pausing a membership, moving a class pack to a friend's account and updating an expired card top the list of requests. Each takes a few minutes of staff time, and each invites a typo when it is done between check-ins. Those three are the clearest candidates for self-service, with every request logged.
Refunds, exceptions to the pass rules and credits for missed classes should stay with the owner or the manager. The portal can show the policy and the member's history, then pass the request along with the details already filled in. Nobody at the desk should have to ask the same member for their name twice.
Most dance fitness studios keep passes and class rosters in a studio platform such as Mindbody or something similar. The portal reads that system and writes back through its supported connection, so a pause requested at home shows on the desk screen before the next class starts. Two copies of one pass balance is how a studio ends up charging for classes a member never attended.
Money moves through the processor the studio already holds an account with. The portal shows a receipt and the last four digits of a card, while the full number stays on the processor's side. We check during the scoping call which fields the current platform will expose.
Members see how many rides remain on each pack, with the expiry date beside it, and nothing else to decode.
A member picks dates and a reason, and the request reaches the front desk with the studio's policy shown alongside.
The processor handles new card details, so the studio's own system never holds the full number.
Past classes, late cancellations and credits sit together, matching the record the front desk keeps.
Coaches, the desk and the owner work from separate screens, and no one sees more than their job requires.
A member account holds a name, a phone number, payment history and sometimes an injury note, so the portal needs firm limits. An instructor needs the class roster and nothing else, while the owner sees billing. Roles are set before launch, and removing a former instructor from the portal takes one step instead of a search through shared passwords.
Card data should stay with the processor, which keeps the studio's obligations under PCI DSS manageable. Sessions end after a stretch of inactivity on the shared studio tablet, and reset links go only to the verified address. Injury notes live in the intake record, so an old knee strain is never shown next to the sound desk.
The costliest error is switching accounts on before the desk has settled how exceptions work. A member asks for money back, the screen says no, the desk says yes, and the member stops trusting both. Settle the pause, transfer and refund rules first, then let the screens follow them word for word.
A second slip is a password screen on a first visit that had no reason for one. Someone checking a balance will close the tab. A one-time link sent to the number on the booking gets them in faster, and a password can be offered later as an optional extra.
New passes spike in January, and pause requests follow once the resolution energy fades, usually by early spring. Publish the summer pause dates on the portal as soon as the summer timetable is set, so members can plan around them.
Gift packs also cluster in December, when a parent buys a block of classes for a friend. The recipient needs a simple way to claim the pack from the portal, and it should carry an expiry date that will not lapse in the middle of the holidays.
Often, yes. Whether a balance can be read depends on what the platform shares. We test that before design, and if the figure is locked away, the portal can take a balance request and send the answer back by text.
The owner decides what counts as a valid pause. Members can ask for one from the portal, and the request is checked against the written terms before anyone is charged or credited. Refunds stay with the manager, and every decision is logged.
Card numbers never reach the studio's own systems, and passwords are never displayed to staff. Each role sees only its own screens, and those roles are set and written down before launch. Ask for the access list during the scoping call.
Yes, and that order suits a lot of studios. The schedule and account records already exist, so the portal is added as one more layer rather than a rebuild. The sequence is agreed in writing up front.
Send us the pass types, the pause rules and the platform you run today. The free scoping call sets out the work, and the cost comes in writing before design begins.