Réserver un terrain, et partager la note.
Une plateforme de réservation de terrains de sport, construite pour ma certification de product builder no-code et IA. Un joueur choisit un créneau, indique combien ils seront, et le prix du terrain se divise entre eux : celui qui réserve décide combien de parts il règle tout de suite. Une fois le paiement passé, le créneau disparaît du catalogue pour les autres visiteurs.
Le travail s'est mené en deux temps : d'abord le pilotage des compétitions côté organisateur, ensuite l'application de réservation côté joueur.
Projet de certification, pas une réalisation client : les terrains, les clubs et les coordonnées visibles sur ces écrans sont des données de démonstration.
Avant : un joueur avance la totalité, puis court après les autres.
Réserver un terrain à plusieurs pose toujours le même problème d'argent : la plateforme encaisse la totalité auprès d'une seule personne, qui passe la semaine à réclamer sa part à chacun. Le paiement n'est pas le sujet du sport, mais c'est lui qui laisse un souvenir.
Le problème était simple à énoncer, moins simple à construire : faire porter le partage par la plateforme elle-même, au moment de la réservation, pour que personne n'ait à payer à la place des autres.
Chacun paie sa part.
Le prix du terrain se divise entre les joueurs prévus, et celui qui réserve choisit combien de parts il règle tout de suite. La sienne seulement, ou celles des joueurs qui ne sont pas encore inscrits.
Le créneau se retire tout seul.
Une fois la réservation payée, le créneau disparaît du catalogue : le visiteur suivant voit un terrain de moins, et réserve donc autre chose. Le gérant garde un planning à jour sans y toucher, et le terrain reste à une seule équipe à la fois.
C'est exactement la mécanique qui, chez un commerçant, tient un stock juste sans que personne y touche : une vente retire l'article des disponibles, et la page suivante affiche l'état réel plutôt qu'un état recopié la veille.
Deux temps, et deux assemblages.
La certification s'est déroulée en deux projets successifs sur le même produit. Le premier a monté le pilotage, côté organisateur. Le second a construit l'application, côté joueur.
Premier temps : piloter les compétitions
- Notion
- La conduite du produit : la feuille de route, le backlog des fonctionnalités et ce qui a été tranché à chaque étape.
- Airtable
- Les compétitions, les clubs, les équipes et leurs joueurs, avec le tableau de bord qui donne au comité l'état de chaque compétition : ce qui est ouvert, ce qui est clôturé, ce qui commence dans la semaine.
-
Le tableau de bord du comité : trois compteurs, ce qui démarre dans les sept jours, et le planning de la semaine. Les compétitions affichées sont des données de démonstration. - Make
- Le rapprochement à l'inscription : le scénario crée l'équipe et les joueurs qui manquent, puis rattache l'équipe à son club, en créant le club s'il manque aussi. Une inscription entre donc sans jamais doublonner ce qui existe déjà.
Second temps : l'application du joueur
- Bubble
- L'application entière : les pages, les comptes, le parcours de réservation, les données (terrains, créneaux, joueurs) et les automatismes qui les relient.
- Stripe
- L'encaissement, y compris le partage du montant entre plusieurs parts.
Le même produit, monté deux fois et de deux façons : c'est exactement l'arbitrage qui se pose au cadrage d'un projet client. Sortir les données de l'application donne des vues de pilotage en quelques minutes, au prix d'un compte de plus à tenir, d'une facture de plus et d'un endroit de plus où quelque chose peut se casser. Les garder dedans donne une application d'un seul tenant, au prix d'un tableau de bord à construire à la main. Le bon choix dépend de qui doit lire quoi, et à quelle fréquence : c'est la question que je pose au départ, et la réponse se justifie devant vous.
Votre métier a sûrement son geste répétitif.
Une disponibilité à tenir, un paiement à répartir, un document à produire. Dites-moi lequel vous coûte le plus de temps.