Boutiques par tenant
Boutique publique, domaine propre, catalogue d’activités, tunnel de commande, confirmations et données séparées pour chaque parc.
Cap Loisirs e-commerce : construire un SaaS de réservation pour les parcs de loisirs
Cap Loisirs e-commerce relie la vente en ligne au fonctionnement réel d’un parc : créneau, capacité, participants, paiement et informations utiles pour l’accueil.
Comment transformer une vente en ligne en réservation exploitable par l’équipe sur place ?
Le projet en bref
- SaaS e-commerce
- Parcs de loisirs
- 2023 - 2026
- Laravel, Filament, Stripe Connect
Relier vente en ligne, réservation et exploitation terrain
SaaS e-commerce Laravel et Filament pour parcs de loisirs, où boutique, planning, stocks, paiement et accueil sont reliés dans un même parcours de réservation.
La réservation ne pouvait pas être ajoutée après coup au tunnel d’achat. Elle devait structurer le produit : ce qui est vendu, ce qui reste disponible, ce qui est payé et ce que l’équipe retrouve le jour de l’activité.
Le point critique : vendre sans perdre le contrôle des créneaux
Dans un parc de loisirs, une commande engage une capacité réelle à une date donnée. Si le stock, le paiement, les documents ou les informations participants ne suivent pas, le problème apparaît au moment le plus sensible : l’accueil.
- Placer le planning avant la fiche produit.
- Garder chaque parc dans son propre contexte de données et de réglages.
- Relier paiement, réservation, emails et documents sans état ambigu.
- Rendre le back-office utile au moment de préparer l’accueil.
Les décisions qui ont cadré le SaaS
Les choix structurants du projet, présentés à partir de leur impact sur le produit et son exploitation.
- 01
Placer le planning au centre
Le stock dépend d’un horaire, d’une prestation et des réservations déjà engagées. Le planning devient donc la base du produit, pas un simple filtre de boutique.
- 02
Assumer le multi-tenant
Chaque parc garde sa boutique, ses réglages, ses rôles et ses données d’exploitation. Cette séparation évite de mélanger les contextes au moment de vendre ou d’administrer.
- 03
Traiter les règles commerciales comme du métier
Bons cadeaux et remises modifient le paiement, le solde, l’éligibilité et la lecture de la commande. Ils demandent donc une logique métier lisible.
- 04
Reprendre l’interface comme un outil quotidien
La boutique devait rester claire pour le visiteur. L’administration devait surtout aider l’équipe à consulter, comprendre et préparer les réservations.
Les parties livrées
Les livrables suivent le même fil : vendre une activité, réserver une capacité réelle, puis rendre l’information exploitable par l’équipe du parc.
Planning et stocks
Créneaux datés, capacités associées aux horaires, participants, formulaires personnalisés et protection des états sensibles.
Paiement et règles commerciales
Stripe Connect, bons cadeaux avec solde, suivi d’utilisation et remises ciblées par catégorie, activité ou prestation.
Back-office d’exploitation
Panneaux Filament, rôles tenant, statuts, emails, contrats joints et indicateurs utiles pour préparer l’accueil.
De l’achat à l’accueil
Partir du jour de l’activité
Le projet ne consistait pas à ajouter un calendrier à une boutique. Chaque vente devait produire une réservation directement exploitable par l’équipe du parc : créneau confirmé, capacité mise à jour, participants identifiés et informations prêtes pour l’accueil.
La réservation devient un état exploitable
Après le paiement, l’équipe retrouve une information claire : qui vient, pour quelle activité, à quel horaire, avec combien de participants, quelles réponses de formulaire et quel statut de réservation.
Le développement a consisté à relier ces éléments dans un même flux, de la boutique jusqu’au tableau de bord.
Identifier le bon parc à chaque étape
Le multi-tenant n’était pas seulement un choix d’architecture. Il conditionnait chaque action sensible : identifier le bon parc, afficher la bonne boutique, envoyer les bons emails et rattacher le paiement au bon environnement.
Les domaines propres renforcent cette logique
Un tenant peut utiliser son propre domaine pour sa boutique. Ce choix rend le SaaS plus naturel pour les visiteurs du parc, mais il impose une vraie discipline technique : résolution du tenant, configuration, assets, emails, liens et paiements restent attachés au bon environnement.
Le socle est commun, mais l’expérience reste propre à chaque parc, côté visiteur comme côté administration.
Collecter les informations avant l’arrivée
Certaines activités demandent des informations spécifiques avant la venue : niveau, choix, autorisations, données pratiques ou réponses nécessaires à l’organisation. Le SaaS permet de créer des formulaires personnalisés, y compris des formulaires par participant.
Cette approche évite de demander les informations après coup par email. Les données sont rattachées à la réservation et consultables dans le contexte de la commande.
Une activité peut aussi avoir ses propres documents
Les emails ne sont pas tous identiques. Selon l’activité ou le tenant, des contenus spécifiques et des contrats peuvent être joints aux messages envoyés après commande.
Le rôle du produit est de garder cette personnalisation compréhensible : elle aide l’exploitation tout en évitant de transformer chaque activité en exception difficile à maintenir.
Donner un cycle de vie aux bons cadeaux
Un bon cadeau possède son propre cycle de vie. Il peut être acheté, envoyé, conservé, utilisé en une ou plusieurs fois, puis suivi dans le temps.
Nous avons donc introduit les bons cadeaux avec une logique de solde et d’historique d’usage. Le checkout affiche clairement ce qui est appliqué, ce qui reste à payer et ce qui reste disponible.
La lisibilité compte autant que le calcul
Une règle juste mais mal présentée crée de la confusion. Le visiteur comprend mieux pourquoi le total change. L’équipe du parc retrouve comment le bon a été consommé.
Cette partie du projet a donc mêlé calcul, traçabilité et interface.
Les remises ont été rendues plus précises
Les remises ont été ajoutées avec deux modes principaux : pourcentage ou montant fixe. Leur application peut être ciblée plutôt que globale.
Le besoin portait sur des filtres fins : catégories, activités et jusqu’aux prestations. Cette précision permet d’adapter une offre commerciale sans modifier toute la boutique.
Une remise explicable
Lorsqu’une réduction s’applique, une règle lisible explique son périmètre, son type, son montant, son éligibilité et son impact sur le panier.
Ce travail limite les situations où une réduction semble acceptée côté visiteur, mais devient difficile à comprendre dans l’administration.
Faire de l’administration un outil quotidien
Une évolution importante a porté sur les interfaces : tableaux de bord et storefront ont été retravaillés pour rendre les parcours plus lisibles, côté parc comme côté visiteur.
La boutique reste simple malgré les règles de planning, de stocks, de remises et de bons cadeaux. L’administration soutient les tâches répétées : consulter les réservations, préparer l’accueil, comprendre les statuts et suivre les informations utiles.
Les rôles tenant structurent l’administration
La gestion des utilisateurs et des rôles a été ajoutée dans le contexte tenant. Les équipes d’un parc n’ont pas forcément accès aux mêmes actions, ni aux mêmes responsabilités.
Cette séparation aide à utiliser le SaaS comme un outil d’équipe, avec des responsabilités plus nettes qu’un compte administrateur unique.
Lire rapidement ce qui attend l’équipe
Le jour de l’activité, l’équipe a besoin d’informations rapides : nombre de participants, réservations attendues, chiffres liés à la journée ou au créneau, statut des commandes.
Nous avons ajouté un calculateur de chiffre d’affaires et de participants pour faciliter cette lecture. L’objectif n’est pas de produire un reporting exhaustif, mais d’aider la réception à vérifier ce qui compte au bon moment.
Une interface utile réduit les allers-retours
Quand les données sont dispersées, l’équipe recalcule, filtre ou recoupe manuellement. En rapprochant les indicateurs des réservations, le back-office devient plus opérationnel.
Ce type de détail compte dans un SaaS métier : la qualité se mesure aussi à ce que l’équipe peut faire après la vente.
Un SaaS guidé par l’exploitation terrain
Le principal enseignement du projet : une vente en ligne devient réellement utile lorsqu’elle prépare déjà le travail du terrain. Le parcours client, le paiement et l’administration doivent donc être pensés ensemble, pas comme trois couches séparées.
Les informations non publiques restent volontairement écartées de cette fiche. Ce qui peut être partagé suffit toutefois à montrer le cœur du projet : rendre une vente en ligne utilisable par des équipes qui accueillent réellement des participants.
Interfaces du produit
Les captures publiques montrent deux faces du produit : l’administration utilisée par les parcs et la boutique consultée par les visiteurs.
Ce qui rend la réservation exploitable
La valeur se situe dans ce que l’achat produit ensuite : une réservation fiable, compréhensible et prête à être utilisée par l’équipe du parc.
- Le stock est relié au planning, au-delà d’une simple fiche produit.
- Chaque tenant garde son domaine, ses rôles, ses statuts et ses contenus dans son propre contexte.
- Les bons cadeaux et remises restent traçables dans le checkout et l’administration.
- Une interface de réception utile réduit les vérifications manuelles le jour de l’activité.
Vous avez un sujet proche ?
Nous pouvons cadrer et développer une plateforme SaaS de réservation lorsque la vente dépend de créneaux, de stocks, de paiements et de règles métier précises.