Begin bij een gewone dinsdagavond
Beschrijf eerst wat er gebeurt tussen het moment dat een lid een les zoekt en weer naar huis gaat. Waar wordt de planning bekeken? Wie verwerkt een annulering? Hoe controleer je toegang? Waar ziet een trainer de bezetting?
Als een leverancier dit alleen per losse module kan beantwoorden, koop je waarschijnlijk koppelingen in plaats van een doorlopende ledenreis.
Vraag om de echte mobiele flow
Een desktopdashboard zegt weinig over de ervaring van een lid onderweg. Laat de leverancier op een gewone telefoon een les zoeken, boeken, annuleren en een check-in starten. Zonder slides en zonder beheerrechten.
- Hoeveel stappen kost een boeking?
- Blijft de club herkenbaar?
- Is de actuele capaciteit zichtbaar?
- Wat gebeurt er bij een volle les?
Controleer wat ‘white-label’ werkelijk betekent
Sommige systemen tonen je logo op een generieke leveranciersapp. Dat kan prima zijn, maar het is iets anders dan een eigen clubomgeving. Controleer naam, URL, kleuren, e-mails, navigatie en supportverwijzingen afzonderlijk.
Bij ClubTrellis hebben we geleerd dat een tenantinstelling pas telt wanneer de zichtbare shell hem overal toepast. Daarom noemen we beheerde inrichting nu wél, maar automatische self-service theming nog niet als afgerond product.
Behandel migratie als een schoonmaakmoment
Een oud ledenbestand bevat vaak verlopen producten, dubbele contacten en uitzonderingen die niemand meer begrijpt. Een volledige kopie voelt veilig, maar sleept oude rommel mee.
Bepaal per gegeven waarom het nodig blijft. Test daarna een kleine import en controleer samen de uitkomst voordat alle leden overgaan.
De beste demo eindigt met open punten
Geen systeem past zonder vragen. Een betrouwbare leverancier benoemt wat direct werkt, wat inrichting vraagt en wat nog niet bestaat. Die open punten geven meer informatie dan een perfecte demonstratie.