Ateliers, cours, séances, locations : une réservation est une promesse sur un créneau, un prix et une place. La première version doit tenir cette promesse quand deux personnes cliquent en même temps, quand le prix dépend de la date, et quand quelqu'un annule. Ce qui va dans la première version, ce qui attend, et le piège des calendriers.
Publié le
Une réservation semble simple : un créneau, un bouton, une confirmation. Elle cesse de l’être au moment où le produit a des utilisateurs réels, et toujours aux mêmes endroits.
Notre principe de conception
La disponibilité est vérifiée et écrite dans le même geste, jamais en deux temps. Et une règle qui n’a pas été écrite en français avant d’être codée n’est pas une règle, c’est une future exception.
| Le mécanisme | Ce qu’il évite |
|---|---|
| Verrou sur le créneau pendant la réservation et le paiement | La double réservation, et la place bloquée par un paiement abandonné : le verrou expire |
| Prix calculé par une règle côté serveur, jamais dans la page | Le prix modifié dans le navigateur, et les écarts entre ce qui est affiché et ce qui est encaissé |
| Fuseau horaire porté par chaque créneau | Le cours de 18 h qui apparaît à 17 h chez un client à l’étranger, et le rappel envoyé une heure trop tard |
| Politique d’annulation en configuration, appliquée automatiquement | Le traitement manuel de chaque cas, et les réponses différentes à deux clients dans la même situation |
| Confirmation et rappel journalisés, échec signalé | Le client qui ne vient pas parce que le courriel n’est jamais parti, et personne ne le sait |
Votre produit tient-il ces cinq cas ? Décrivez ce qu’on réserve et comment on paie. Nous vous disons ce qui manque, et si c’est une correction ou une brique à refaire.
Décrire mon projetEncaisser au moment de réserver simplifie tout : la place est prise quand l’argent est là, et l’annulation est un remboursement. Payer sur place ou après demande une gestion des absents, des relances et des impayés, et c’est une autre première version. La plupart des produits gagnent à encaisser d’abord, avec un acompte si le montant est élevé.
Si les prestataires publient leurs créneaux uniquement dans votre produit, le calendrier est simple. S’ils en ont déjà un ailleurs, un agenda, une autre plateforme, il faudra tôt ou tard se synchroniser, et c’est là que les doubles réservations reviennent par la fenêtre. La première version peut l’exclure, à condition de le dire aux prestataires et de le prévoir dans la façon dont les créneaux sont stockés.
Jusqu’à quand, avec quel remboursement, qui décide en cas de désaccord. La réponse s’écrit en quelques lignes avant le cadrage, et elle devient une configuration, pas du code. Une politique simple et appliquée à la lettre vaut mieux qu’une politique fine traitée à la main.
Ce que nous livrons
Les fiches et les créneaux, publiés par les prestataires ou par vous ; la réservation avec verrou et expiration ; le prix par règle côté serveur ; le paiement à la réservation par un prestataire, avec ses retours traités ; la confirmation et le rappel, journalisés ; l’annulation automatique selon la politique configurée ; l’administration des créneaux et des réservations. Le plus souvent un MVP standard, à cause du paiement. Hors première version : synchronisation avec des calendriers externes, avis, options et suppléments, tarifs saisonniers complexes, application mobile, multi-établissement.
Décrivez ce qu'on réserve, qui publie les créneaux et comment on paie. Le cadrage dit ce qui va dans la première version, et à quel prix.