KoratDeux types d’activité partagent ce système de réservation : service et clinic. Ils exécutent le même code — prestations, rendez-vous, affectation, forfaits — et le type clinique renomme l’interface en rendez-vous, patients et cures, parce qu’un cabinet dentaire et un salon d’ongles ont le même problème de planning avec d’autres mots. Le choix du type change le vocabulaire et rien de structurel : un produit clinique séparé divergerait du produit service en deux versions.
Une prestation est une durée et un prix que vous fixez
Le catalogue est une liste de prestations, chacune avec une durée et un prix. La durée n’est pas décorative : c’est elle qui rend un agenda de rendez-vous significatif, puisqu’un soin de quatre-vingt-dix minutes et une coupe de quinze n’occupent pas la même part de la journée. Les clients parcourent la page publique du commerce, choisissent et réservent ; cette section de page est fournie par le module lui-même, bâtie sur la même bibliothèque d’interface que les autres, donc elle paraît native plutôt que rapportée.
La réservation, et la confirmation que le salon valide lui-même
Une demande porte un nom, un téléphone, une date, une heure et une note. Elle arrive en attente, et le commerce confirme. Le compteur en attente est l’une des pastilles vivantes du tableau de bord, aux côtés des commandes actives, des tables qui appellent et des congés à traiter — un commerce faisant tourner plusieurs modules a un seul endroit où tout ce qui attend un humain est compté.
L’étape de confirmation n’est pas une friction gratuite. Un système qui accepte automatiquement tout ce que le calendrier peut loger prendra le rendez-vous dont l’intervenant est absent ce jour-là, et le onze heures qui ne tient que si le dix heures est court. Faire de l’acceptation un acte humain garde le savoir propre du commerce dans la boucle, et donne au client une réponse ferme plutôt qu’un créneau qui se déplace en silence.
Chaque rendez-vous peut être affecté à un membre de l’équipe. Ce seul champ transforme une liste de réservations en journée de travail : il répond à « qui s’en occupe », il permet de rendre un client fidèle à la même personne, et il alimente l’historique client, donc le commerce sait pour lequel de ses intervenants les habitués reviennent.
Forfaits et cures prépayés : N séances valables N jours
Le prépayé a son propre modèle plutôt que d’être une vente ordinaire. Un forfait est soit une cure de N séances valable N jours, soit un abonnement valable N jours. Le client l’achète et consomme une séance à la fois ; un onglet « mes forfaits » montre ce qu’il détient et ce qu’il lui reste. Ce reste est l’enregistrement de référence, tenu sur le même serveur que les rendez-vous qui le consomment, et non sur une carte tamponnée au fond d’un portefeuille.
Acheter un forfait est aussi l’une des transactions qualifiantes de la vue d’éligibilité aux avis : un client qui a payé une cure peut donc écrire un avis sur le commerce avant même d’avoir consommé sa première séance.
Il n’y a pas de rappel par SMS, parce qu’il n’y a pas de SMS. La vérification téléphonique et l’envoi de SMS ne sont pas construits — l’endpoint répond 501 et le dit. Les notifications atteignent les clients dans l’app, et les e-mails ne partent que vers des adresses vérifiées.
Le type clinique est un changement de vocabulaire, pas un dossier médical. Il renomme l’interface en rendez-vous, patients et cures. Il ne stocke ni notes cliniques, ni ordonnances, ni rien de ce qui devrait vivre dans un dossier patient informatisé, et il n’est pas conçu pour cela.
Ce que le propriétaire obtient autour : rapports, CRM et RH
Un commerce de service ou une clinique obtient trois tuiles — rendez-vous, prestations, forfaits — plus tout ce que reçoit n’importe quel type d’activité. Les rapports couvrent chiffre d’affaires, nombre de commandes, panier moyen, répartition espèces / PromptPay / autre, cinq meilleures ventes, histogramme sur sept jours, périodes aujourd’hui, 7 jours, 30 jours ou tout, réimpression de reçu et texte de facture partageable. Pour un commerce de service, la liste des meilleures ventes se lit comme « quels soins paient réellement », rarement celui de l’affiche.
Le CRM bâtit une liste de clients à partir du registre des ventes, avec notes et étiquettes, historique d’achats, points de fidélité accumulés à un taux fixé par le commerce dans sa propre devise, contre une vente minimale et une récompense configurables. Les RH couvrent le côté équipe : pointage d’entrée et de sortie avec GPS et note, demandes de congés, plannings, et paie avec minutes travaillées et heures supplémentaires au-delà de huit heures par jour, sur un salaire horaire ou mensuel, plus annonces et tâches assignables. La paie est cloisonnée — un membre ordinaire ne voit que sa propre rémunération, le propriétaire et le gérant voient tout le monde.
L’accès repose sur une matrice de permissions : treize capacités de base plus celles que déclarent les modules installés, des préréglages de rôles pour propriétaire, gérant, service, cuisine et employé, et des dérogations par personne. Les tuiles disparaissent quand un membre n’a pas la capacité, et un membre qui n’a encore aucune permission voit un écran qui le dit exactement, plutôt qu’une liste vide qui se lit comme un bug. Dans l’app Android ces contrôles s’exécutent sur le client ; la même matrice existe en base sous has_capability(business_id, capability), développée côté serveur pour les politiques de sécurité au niveau des lignes.
Deux voisins pour un salon ou une clinique. Un commerce qui reçoit sans rendez-vous appelle ses clients par la file d’attente plutôt que par l’agenda, et la page pour les professionnels résume ce que les quatre types cœur partagent de toute façon.
Le système de modules en dessous et les extensions installables
Service est l’un des quatre modules cœur, avec Restauration, Hébergements et Commerce — les types d’activité sont les modules. Un module déclare un identifiant, les types d’activité qu’il revendique, un libellé, un titre de catalogue, une action principale, une vue de catalogue, et facultativement des capacités, des tuiles de console, un écran de console et une section de page client. Ce contrat est ce qui permet de construire automatiquement un éditeur de permissions à partir des capacités que déclarent les modules installés.
Par-dessus s’ajoutent sept extensions installables qui fonctionnent pour tout type d’activité, depuis la boutique de plugins de la console : permissions d’équipe, moyens de paiement, adhésions et abonnements, et rappels de renouvellement. Les deux dernières vont de soi pour un commerce de service — une formule que les clients achètent depuis la page du commerce, et un rappel avant qu’elle n’expire. La désinstallation passe par une confirmation qui dit clairement que les données ne sont pas supprimées, et une extension désinstallée ne fournit ni tuile, ni permission, ni section de page client. Les plugins tiers ne sont pas encore ouverts, et la boutique le dit elle-même. Ce qui existe aujourd’hui, c’est une architecture modulaire avec des extensions maison, et ouvrir les candidatures est l’étape suivante.
Les avis, après le rendez-vous
Le recours à une prestation est l’un des types vérifiés de la vue d’éligibilité aux avis : un client qui a réellement été reçu peut écrire un avis, et tous les autres obtiennent une carte verrouillée expliquant pourquoi le bouton n’est pas là. La note en étoiles est recalculée par un déclencheur en base à partir des lignes d’avis, jamais saisie. Les avis acceptent des photos, un résumé de la distribution de cinq à une étoile, la modification et la suppression du dernier que vous avez laissé, un nouvel avis à la visite suivante pendant que l’ancien reste, et des réponses publiques du propriétaire.