16 — Services, Rendez-vous et Disponibilités

1. Objectif métier

Mettre en place un planning fiable, lisible et actionnable pour toute l’équipe.

Ce module sert à:

structurer les prestations vendues (services),
ouvrir des créneaux cohérents avec la réalité terrain,
éviter les conflits de réservation,
gérer la vie complète d’un rendez-vous (création, replanification, annulation, clôture),
communiquer clairement avec le client.

Résultat attendu: moins d’allers-retours, moins de surbooking, meilleure expérience client.

2. Qui utilise ce module (admin/operator)

admin: définit le cadre global (services, horaires, capacité, règles de suivi).
operator: applique les règles au quotidien (création, suivi, modification, clôture).

Répartition recommandée:

l’admin cadre,
l’opérateur exécute,
les deux suivent ensemble les incidents planning (retards, annulations, no-show).

3. Prérequis

Checklist avant ouverture du module:

fuseau horaire organisation validé,
pas de confusion entre heure locale équipe et heure locale client,
durée de créneau définie,
capacité simultanée définie,
plages d’ouverture par jour renseignées,
services actifs créés avec durée réaliste,
politique de notification client validée,
synchronisation calendrier externe activée uniquement après test réussi.

Contraintes métier à respecter:

le nom d’un service doit être unique dans l’organisation,
un créneau disponible dépend toujours de 3 éléments: horaires d’ouverture, capacité, rendez-vous déjà actifs,
un rendez-vous manuel doit respecter les mêmes règles de disponibilité qu’un rendez-vous créé via workflow,
un contact ne doit pas être réservé deux fois sur le même instant de début,
tout changement de rendez-vous doit être accompagné d’une communication client.

4. Procédure pas-à-pas (orientée actions produit)

Cadrer la politique de planification.

Fixer la durée standard des créneaux.
Définir la capacité simultanée réelle (et non théorique).
Valider les jours et plages d’ouverture.

Créer les services.

Utiliser des noms compréhensibles côté client.
Définir durée et prix.
Activer uniquement les services réellement opérables.

Vérifier la cohérence service/planning.

Contrôler que la durée service est compatible avec les créneaux.
Éviter les services trop longs qui bloquent toute la journée.

Tester la disponibilité avant mise en production.

Simuler plusieurs jours (semaine normale, journée chargée, week-end si actif).
Vérifier qu’un service long propose moins de créneaux qu’un service court.

Créer un rendez-vous client.

Rechercher le contact.
Si le contact n’existe pas, créer une fiche minimale propre.
Sélectionner un créneau réellement disponible.
Valider le statut initial (pending ou confirmed selon votre process).

Confirmer et notifier.

Confirmer le rendez-vous quand toutes les informations sont validées.
Envoyer une confirmation claire au client (date, heure, service, point de contact).

Replanifier proprement.

Vérifier le nouveau créneau.
Mettre à jour le rendez-vous.
Notifier immédiatement le client avec ancien et nouveau créneau.

Annuler proprement.

Renseigner un motif utile.
Passer le statut à cancelled.
Informer le client et proposer une alternative si nécessaire.

Clôturer la prestation.

Passer à completed après exécution réelle.
Passer à no_show en cas d’absence client.
Éviter les rendez-vous laissés en pending indéfiniment.

Faire une revue hebdomadaire.

Taux d’annulation.
Taux de no-show.
Créneaux saturés.
Créneaux sous-utilisés.

5. Scénarios concrets (minimum 2)

Scénario A: cabinet de services. Objectif: réduire les créneaux perdus. Action: service “Consultation 30 min”, capacité 1, créneaux toutes les 30 minutes. Résultat attendu: planning clair, pas de chevauchement, confirmation client systématique.
Scénario B: replanification client de dernière minute. Objectif: garder la relation client malgré le changement. Action: déplacer un rendez-vous confirmed vers le prochain créneau libre et notifier en moins de 5 minutes. Résultat attendu: rendez-vous maintenu sans conflit ni double réservation.
Scénario C: gestion des absences. Objectif: fiabiliser les indicateurs. Action: marquer en no_show les clients absents et appliquer un script de relance standard. Résultat attendu: meilleure lecture des causes de perte de capacité.

6. Erreurs fréquentes et résolution

Erreur: aucun créneau proposé. Cause fréquente: plages d’ouverture incomplètes ou capacité saturée. Résolution: vérifier horaires, capacité, rendez-vous actifs sur la période.
Erreur: rendez-vous affiché à une heure inattendue. Cause fréquente: fuseau horaire mal configuré. Résolution: corriger le fuseau organisation puis retester sur un cas réel.
Erreur: surbooking constaté. Cause fréquente: création manuelle sans contrôle de disponibilité. Résolution: imposer la vérification créneau avant toute confirmation.
Erreur: client non informé après modification. Cause fréquente: replanification/annulation réalisée sans notification. Résolution: ajouter une étape obligatoire de communication dans la checklist opérateur.
Erreur: écarts avec calendrier externe. Cause fréquente: synchronisation active mais non surveillée. Résolution: faire une revue quotidienne des cas en erreur et corriger le rendez-vous source.

7. Bonnes pratiques et limites

Bonnes pratiques:

standardiser les durées de service pour simplifier l’exploitation,
éviter de multiplier des services quasi identiques,
utiliser des motifs d’annulation/no-show normalisés,
traiter chaque replanification comme un événement client sensible,
piloter le module avec un point hebdomadaire court (30 minutes).

Limites à connaître:

la qualité du planning dépend de la qualité de paramétrage initial,
une action manuelle hors process peut contourner les protections,
la synchronisation calendrier externe peut échouer ponctuellement,
la capacité simultanée mal calibrée fausse toute la disponibilité.

8. Référence rapide (champs/statuts/modes)

Statuts rendez-vous:

pending: créé mais pas encore confirmé.
confirmed: validé et planifié.
cancelled: annulé avant exécution.
completed: exécuté.
no_show: client absent.

Paramètres de disponibilité:

timezone: fuseau de référence.
slot_minutes: granularité de créneau.
business_hours: plages d’ouverture par jour.
max_concurrent: capacité simultanée.

Champs service:

nom,
description,
durée,
prix,
actif/inactif.

Modes d’exploitation:

mode standard: planning interne uniquement,
mode synchronisé: planning interne + calendrier externe (avec supervision).