Inventaire des activités
Visites à créneaux : conserver une capacité vendable fiable
Une jauge journalière ne suffit pas lorsqu’une activité possède plusieurs départs, guides, langues et durées. La capacité doit être calculée au bon niveau puis protégée pendant la réservation.
Réponse directe
Définir l’unité réellement limitée
Selon l’activité, le stock peut représenter des sièges, des places de groupe, des équipements, un guide ou l’accès à un site. Une visite de quinze personnes avec deux guides n’est pas automatiquement une jauge de trente : l’entrée du lieu, le transport ou le matériel peuvent imposer une autre limite. Documentez la contrainte la plus basse et les dépendances entre départs.
Le standard OCTO pour les activités traite séparément les produits, leur disponibilité et le cycle de réservation. Ce découpage aide à ne pas confondre une fiche vendable avec une place effectivement libre.
Relier calendrier, départ et unités
| Niveau | Ce qu’il décrit | Contrôle |
|---|---|---|
| Produit | Visite et conditions générales | Actif et publiable |
| Créneau | Date, heure locale, durée, langue | Départ confirmé |
| Unité | Adulte, enfant, groupe ou équipement | Règle de capacité et prix |
| Option | Place temporairement retenue | Expiration et libération |
| Réservation | Places définitivement engagées | Confirmation et annulation |
Une capacité vendable se recalcule après chaque option expirée, confirmation, annulation ou fermeture manuelle. Gardez la raison des ajustements et l’auteur d’un blocage de créneau.
Comparer les canaux sur un cas concurrent
Un site direct, une agence et une marketplace peuvent demander la dernière place presque simultanément. Interrogez la disponibilité au moment de confirmer, et prévoyez une réponse claire si la place a disparu. Ne transformez pas une simple réponse de recherche en garantie. Une vente refusée doit libérer le paiement en attente ou déclencher la procédure de remboursement selon l’état réel.
Les mises à jour de calendrier peuvent arriver avec retard. Suivez les écarts par canal et le délai entre changement de capacité et visibilité de ce changement, particulièrement pour les départs proches.
Tester les cas qui saturent la jauge
- Mettre en vente un départ avec deux places et trois canaux actifs.
- Créer une option, la laisser expirer et contrôler la remise en vente.
- Faire réserver simultanément la dernière place depuis deux canaux.
- Fermer le départ pour météo, puis vérifier messages, billets et remboursements.
- Déplacer un participant vers un autre créneau et contrôler les deux jauges.
Une règle de capacité par départ et unité, avec journal des blocages, options, confirmations et écarts de synchronisation.
Mesurer la capacité réellement vendue
Comparez places publiées, réservées, consommées et perdues par expiration d’option ou fermeture tardive. Examinez séparément les surventes et les places restées invendues alors qu’elles étaient libres. Ces deux écarts orientent des corrections différentes : meilleure confirmation d’un côté, meilleure libération et diffusion du stock de l’autre.
Tester la dernière place avec une ressource commune
Créez deux visites différentes utilisant le même guide, avec des horaires qui se chevauchent. Réservez la dernière capacité depuis un canal puis interrogez l’autre. Contrôlez ce qui consomme réellement la ressource : nombre de billets, départ complet ou durée d’occupation. Ajoutez ensuite une exception de calendrier. Le résultat attendu est une disponibilité réalisable par l’équipe, pas seulement un nombre positif dans un catalogue.
| Cas à rejouer | Preuve à conserver |
|---|---|
| Deux activités et un guide partagé | Planning du guide et capacité des deux produits. |
| Exception dans une série récurrente | Récurrence, exception et confirmations existantes. |
| Requête avec rôle marketplace | Rôle du compte et réponse de l’API. |
| Départ supprimé après vente | Références vendues, notification et responsable de reprise. |
Activités : ressources, créneaux, API opérateur et distribution : fonctions documentées, limites et questions à poser à quatre acteurs du secteur.
Relier capacité et composition des participants
La capacité se lit avec les unités du produit et les catégories qui composent la réservation. Une personne gratuite peut suivre une règle de places différente d’un simple prix nul. Testez le nombre de voyageurs, la quantité commerciale et les quantités par catégorie sur l’option choisie, puis retrouvez leur effet dans le stock et la confirmation.
Les bornes d’âge ne sont pas universelles. Viator les décrit comme des valeurs propres au produit ; une interface doit les reprendre plutôt que conserver les tranches d’une autre activité. Pour un groupe privé, vérifiez aussi l’unité vendue et les exigences d’accompagnement avant de modifier la composition. Consultez le Participants d’activités : âges, unités et règles de réservation.
Relier les places aux ressources communes
Un créneau ouvert peut encore dépendre d’une salle, d’un véhicule ou d’une équipe mobilisés par une autre offre. Définissez la consommation par variante et retrouvez le stock partagé. Dans un test pédagogique, une vente privée bloque une ressource entière tandis qu’un billet collectif utilise une place. La recette doit expliquer ces unités et examiner la capacité des offres voisines, au lieu de comparer seulement leurs nombres de participants.
Ressources partagées : éviter la double promesse entre activités
Cas à rapprocher : Places numérotées : relier plan, séance et billet
Une capacité globale ne démontre pas la configuration de places numérotées. Pour une séance avec placement, rapprochez plan, zone, rang et billet final. Les places retenues dans un panier et celles attribuées à une commande doivent rester distinguées.
Places numérotées : relier plan, séance et billet · Vérifier les preuves de ce dossier
Approfondir le parcours : Heure limite de réservation : créneau ouvert et vente encore possible
La capacité d’un créneau ne suffit pas à démontrer qu’il est encore vendable. La limite de réservation doit être retrouvée séparément du nombre de places et de la dernière admission. Une recherche ancienne demande une relecture à l’approche du départ.
Heure limite de réservation : créneau ouvert et vente encore possible · Rapprocher les preuves du parcours
Une séance, plusieurs contraintes · données fictives
La ressource la plus rare fixe le plafond de l’activité.
Une sortie accompagnée fictive propose des places à des visiteurs. Pour cet exemple, les capacités concernent uniquement les visiteurs, hors personnel : vingt places à bord, dix-huit équipements utilisables et un groupe limité à seize visiteurs par la règle d’organisation retenue. Chaque visiteur consomme une unité de chacune de ces ressources.
- 20 places visiteursCapacité de places retenue pour la séance.
- 18 équipementsUnités utilisables et disponibles sur le même créneau.
- 16 visiteurs par groupeLimite d’organisation applicable dans cet exercice.
Plafond commun : minimum de 20, 18 et 16 = 16 visiteurs. Retenir vingt places à partir du seul plan de sièges ignorerait les deux autres contraintes.
| Situation | Calcul | Résultat de lecture |
|---|---|---|
| 12 visiteurs confirmés et 4 options actives | 16 − 12 − 4 = 0 | Aucune place supplémentaire, même si les quatre options ne sont pas encore payées. |
| Deux des quatre options sont libérées | 16 − 12 − 2 = 2 | Deux visiteurs peuvent être ajoutés si les trois ressources restent disponibles. |
| Un adulte et un enfant demandent ces deux places | Deux participants, donc deux unités de chaque ressource dans ce scénario. | Un tarif enfant gratuit ne signifie pas une consommation de capacité nulle. |
| Un second groupe utilise les mêmes équipements au même horaire | Comparer les affectations communes sur la période réelle d’utilisation. | Deux plafonds de séance distincts ne créent pas un second lot d’équipements. |
Changer le nombre de billets ne suffit pas toujours à libérer la ressource.
Après une annulation, vérifiez la libération de la place, de l’équipement et de l’affectation au groupe. Un billet annulé qui garde une affectation active peut laisser une capacité artificiellement bloquée. À l’inverse, une libération appliquée deux fois expose à une promesse excessive.
Comment relire deux séances successives ?
Rapprochez leurs heures de début et de fin, puis ajoutez le temps de retour, de contrôle et de remise en disponibilité de la ressource. Une fin commerciale à 11 h ne prouve pas qu’un équipement peut être réaffecté à 11 h sur un autre lieu.
Que faut-il adapter dans une autre activité ?
Définissez les unités réellement consommées : participants, sièges, guides, véhicules, équipements ou places numérotées. Précisez les règles d’âge et d’accessibilité ainsi que les catégories qui partagent une ressource. Si un participant consomme plusieurs équipements, le simple minimum de capacités ne suffit plus : il faut calculer la consommation par catégorie.
Les limites de cet exercice ne sont pas des règles applicables à un opérateur réel. Pour votre activité, utilisez les capacités confirmées par les responsables concernés. Suivre les mouvements de stock · Attribuer les contrôles et les passages de relais.
OCTO : disponibilité retenue, expiration et confirmation
La retenue temporaire de capacité et la confirmation de réservation sont des étapes différentes du parcours OCTO.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| availabilityId | Un contrôle de disponibilité fournit la référence nécessaire à la création de la réservation. | Conserver produit, option et disponibilité sélectionnés dans le même contexte. |
| ON_HOLD | La création retient la capacité jusqu’à confirmation ou expiration ; la durée demandée est bornée par le fournisseur ou son prestataire OCTO. | Lire l’échéance retournée au lieu de supposer une durée universelle de retenue. |
| Confirmation | Une réservation retenue peut être confirmée tant qu’elle n’a pas expiré. | Vérifier le statut retourné avant de présenter la prestation comme confirmée. |
| Annulation | Le parcours documente POST /bookings/{uuid}/cancel, distinct d’une suppression HTTP DELETE. | Suivre le contrat de l’opération et ses conditions d’annulation. |
Le standard ne constitue pas un catalogue vendable et ne prouve pas l’activation de toutes les fonctions pour un revendeur.
OCTO — Core Bookings · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
FareHarbor : distinguer inscription, alerte et réservation
La liste d’attente peut envoyer plusieurs types de messages. Aucun ne doit être confondu avec une place confirmée.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Confirmation d’inscription | L’inscription en ligne déclenche toujours un courriel ; l’envoi après ajout manuel est configurable et désactivé par défaut. | Distinguez ce message de l’alerte annonçant une place disponible. |
| Alerte automatique | Une annulation ou un changement peut déclencher l’alerte après un délai configuré, si la place correspond au type de client. | Conservez le type demandé et testez le déclencheur ; l’alerte ne bloque pas la place. |
| Après l’alerte | Un client déjà averti automatiquement ne reçoit plus d’autre alerte automatique pour ce créneau. Book now peut ensuite conduire à un créneau redevenu complet. | Vérifiez la réservation obtenue avant de clore la demande. |
| Affichage de la liste | Un cutoff ou le paramètre bookable-only=yes du lien d’intégration peut masquer l’option. | Testez le lien publié sur le site, avec un créneau complet. |
Aide FareHarbor mise à jour le 29 septembre 2026. Les types conditionnels, dont enfant exigeant un adulte, ne fonctionnent pas dans Waitlist.
FareHarbor — fonctionnement de Waitlist · mise à jour par la source le 29/09/2026 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
bookingkit : lire le calendrier et mesurer la portée d’une action
Une action sur le créneau entier peut toucher plusieurs dossiers. Relisez sa portée avant de traiter un changement demandé par une seule personne.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Jour en rouge foncé | Dans la vue mensuelle, cette couleur repère le jour ayant le plus de participants du mois. | Une couleur relative ne prouve pas que tous les créneaux sont complets ; ouvrez les capacités. |
| Move appointment | Le déplacement emporte les réservations du créneau vers une date libre dans le calendrier et déclenche un courriel aux participants. | Vérifiez que tous les dossiers sont concernés et relisez les informations de remplacement. |
| Delete appointment | Cette action annule toutes les réservations du créneau. Elle permet de choisir l’étendue du remboursement et déclenche un courriel. | Ne l’utilisez pas comme synonyme d’annulation d’un seul participant ; contrôlez aussi le traitement financier choisi. |
| Add payment | Cette action marque comme payée une commande en paiement sur place, par exemple en espèces ou par carte. | Un statut saisi dans l’outil doit être rapproché du justificatif de paiement correspondant. |
Choisir une action à la bonne échelle
Exemples fictifs, sans modification de réservation ni envoi de courriel.
Un seul participant se retire d’un créneau partagé
Plusieurs dossiers sont inscrits à la même activité ; une personne demande à annuler.
Demande : 1 participant
Créneau : plusieurs réservations
Action envisagée : Delete appointmentLecture du cas. L’action envisagée touche toutes les réservations du créneau. Il faut traiter la demande au bon niveau et vérifier ses conséquences financières, sans annuler les autres dossiers.
Une activité est déplacée à cause de la météo
L’équipe envisage Move appointment pour l’ensemble du créneau.
Périmètre : tous les inscrits
Nouvelle date : à confirmer
Notification automatique : prévue par l’aideLecture du cas. Avant l’action, vérifiez l’accord et la solution retenue pour les dossiers concernés. Après l’action, contrôlez la nouvelle date et le suivi des participants ; le déclenchement d’un courriel ne prouve pas que chacun l’a lu.
Fonctions de l’interface bookingkit documentées dans l’aide consultée le 23 octobre 2026. Leur présence ne prouve ni une synchronisation immédiate de tous les revendeurs ni une fonction équivalente dans chaque API.
bookingkit — Monthly View · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Checkfront Classic Items : des créneaux qui se chevauchent partagent le même stock
Deux horaires affichés ne créent pas deux stocks indépendants. Pour préparer une visite ou une location, relisez le produit, les intervalles et la quantité commune avant de promettre la dernière place.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Créneaux superposés | Dans Classic Items, les créneaux qui se chevauchent partagent la quantité de l’item. | Ne multipliez pas la capacité par le nombre d’heures de départ affichées. |
| Préparation entre créneaux | Le réglage Maintenance Time ne s’applique pas aux timeslots ; la documentation propose de laisser des intervalles entre eux. | Contrôlez les heures réellement proposées et le temps nécessaire pour remettre la ressource en service. |
| Créneau retiré | Les factures conservent les anciennes valeurs du créneau, sauf modification de la facture ; le créneau retiré n’est plus accessible dans le calendrier d’inventaire. | Gardez le suivi des réservations existantes avant une réorganisation des horaires. |
| Visibilité de l’item | Staff Only reste visible et réservable en interne ; In Packages Only apparaît dans un package. | Un produit absent de la page publique n’est pas forcément supprimé ou impossible à réserver en interne. |
Deux départs, une quantité commune
Exemple fictif avec deux ressources identiques disponibles. Il illustre un chevauchement, sans calculer la disponibilité d’un compte Checkfront.
- 09 h–10 h 30 : deux ressources
Le premier groupe mobilise les deux ressources pendant cet intervalle.
- 10 h–11 h : une ressource demandée
La nouvelle demande recouvre une partie du premier créneau.
- 10 h–10 h 30 : trois ressources nécessaires
Le besoin simultané dépasse les deux ressources du stock commun ; des heures différentes ne suffisent pas à éviter le conflit.
Deux contrôles avant de modifier les horaires
Scénarios fictifs, sans modification d’un calendrier fournisseur.
Une seconde heure de départ est prise pour un second stock
Un opérateur fictif dispose de deux ressources et propose deux créneaux partiellement simultanés.
Ressources communes : 2
Premier créneau : 2 ressources occupées
Second créneau superposé : 1 ressource demandéeLecture du cas. Ne confirmez pas la demande en donnant deux nouvelles ressources au second créneau. Vérifiez le besoin simultané et les règles du produit.
Un créneau retiré existe toujours dans une facture
Une ancienne réservation fictive porte sur un horaire que l’équipe ne retrouve plus dans le calendrier d’inventaire.
Facture : ancien horaire conservé
Créneau : retiré du calendrier
Réservation existante : à suivreLecture du cas. Le retrait du créneau ne suffit pas à expliquer le traitement de la réservation. Retrouvez sa facture et la décision concernant le client avant de modifier ou d’annoncer un nouvel horaire.
Réglages Classic Items consultés le 23 octobre 2026. Ce périmètre ne décrit pas tous les produits de Checkfront ni le contrat de son API. Les réservations et les quantités des exemples sont fictives.
Checkfront — Configuring allocation and visibility for items using the Item Builder (Classic Items) · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
OCTO : confirmer avant l’heure limite et garder le contexte du créneau
L’heure de début d’une activité et la dernière heure de confirmation ne répondent pas à la même question. Une lecture correcte de la disponibilité conserve aussi l’option choisie et les éventuelles pauses d’ouverture.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Confirmation avant utcCutoffAt | Le champ utcCutoffAt indique l’échéance avant laquelle la réservation doit être confirmée. | Comparez l’instant de confirmation à cette échéance. Commencer le parcours avant la limite ne démontre pas que la confirmation est arrivée à temps. |
| Début local et échéance UTC | localDateTimeStart exprime le début du produit dans son heure locale ; utcCutoffAt donne une échéance en UTC. | Comparez des instants tenant compte du décalage horaire. L’activité peut ne pas avoir commencé alors que la confirmation n’est déjà plus possible pour ce créneau. |
| Identifiant dans le périmètre de l’option | L’identifiant de disponibilité est unique au sein de l’option. | Conservez le produit et l’option avec l’identifiant. Deux options portant le même identifiant de créneau ne doivent pas être fusionnées sur ce seul champ. |
| Plusieurs périodes d’ouverture | openingHours peut contenir plusieurs périodes, y compris pour une disponibilité comportant une heure de début. | Conservez les pauses et vérifiez la période pertinente ; une première ouverture et une dernière fermeture ne prouvent pas une ouverture continue. |
Deux créneaux dont le contexte change la décision
Réponses fictives simplifiées. Les identifiants et horaires ne correspondent à aucune réservation réelle.
L’activité commence plus tard mais la limite est dépassée
Le 10 novembre 2026, une activité fictive commence à 15 h dans un fuseau à UTC+1. Sa confirmation doit intervenir avant 12 h UTC.
localDateTimeStart : 2026-11-10T15:00:00+01:00
utcCutoffAt : 2026-11-10T12:00:00Z
Confirmation tentée : 2026-11-10T12:15:00ZLecture du cas. La tentative intervient à 13 h 15 locales : l’activité n’a pas commencé, mais l’échéance de 13 h locales est dépassée. Le seul horaire de début ne permet pas de conclure que ce créneau est encore confirmable.
Le même identifiant apparaît dans deux options
Un catalogue fictif a deux options d’un produit et reçoit la même valeur d’identifiant de disponibilité dans chacune.
Produit : visite fictive
Option A, disponibilité : slot-1
Option B, disponibilité : slot-1Lecture du cas. L’unicité documentée porte sur l’option. Conservez les couples option et disponibilité, avec le produit, puis les conditions propres à chaque réponse. Ne dédupliquez pas ces deux offres sur slot-1 seul.
Périmètre : modèle Availability du cœur OCTO, consulté le 23 octobre 2026. Les réponses du fournisseur et leur fraîcheur restent à vérifier. Les heures fictives ci-dessous servent uniquement à comparer les instants ; elles ne décrivent pas une activité proposée à la vente.
OCTO — Availability, API Core · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
London Pass : les fenêtres de réservation varient selon l’attraction
Un pass et une réservation de créneau se préparent séparément. La page officielle donne des fenêtres différentes pour plusieurs attractions londoniennes ; elles servent à organiser les démarches, sous réserve des places proposées.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| London Eye | La page annonce une réservation dans l’application Go City jusqu’à quinze jours avant la visite et demande d’anticiper d’au moins un jour. | Préparez cette démarche sans promettre un créneau de dernière minute ; les disponibilités du jour et du lendemain sont souvent limitées. |
| Tower Bridge | La fenêtre annoncée est de dix jours ; la démarche demande le numéro de commande ou de pass et le courriel utilisé à l’achat. | Retrouvez ces informations pour chaque pass concerné avant de conclure à une anomalie de réservation. |
| Westminster Abbey | La réservation dans l’application est annoncée jusqu’à dix jours avant la visite, avec un pass valide pour la réservation. | Comparez la date du créneau aux jours utilisables du pass et conservez la confirmation obtenue. |
| The View from The Shard | La page annonce jusqu’à trente jours d’anticipation et demande le numéro de commande et le courriel d’achat. | N’appliquez pas cette fenêtre de trente jours aux autres attractions ; vérifiez le créneau réellement proposé. |
Deux fenêtres à vérifier avant de signaler une absence de places
Délais et programmes fictifs, sans interrogation d’un calendrier réel.
Le London Eye est recherché vingt jours avant la visite
Une équipe fictive cherche un créneau London Eye vingt jours avant la visite et conclut immédiatement que l’attraction est complète.
Anticipation de la recherche : 20 jours
Fenêtre annoncée London Eye : jusqu’à 15 jours
Disponibilité réelle : non vérifiéeLecture du cas. La recherche précède la fenêtre annoncée pour ce parcours. Préparez une nouvelle vérification dans cette fenêtre ; l’absence de créneau à ce stade ne démontre pas que l’attraction est complète.
La fenêtre du Shard est appliquée à Tower Bridge
Un programme fictif prévoit de réserver toutes les attractions trente jours avant la visite, en reprenant la règle du Shard pour Tower Bridge.
Attraction à réserver : Tower Bridge
Délai repris : 30 jours
Fenêtre publiée pour Tower Bridge : jusqu’à 10 joursLecture du cas. Corrigez le calendrier de préparation par attraction. Une fenêtre plus courte n’est pas un défaut du pass ; retrouvez aussi le numéro requis et le courriel d’achat pour réaliser la démarche.
Informations de la page officielle consultées le 23 octobre 2026. Fenêtres de réservation, attractions admises et places proposées peuvent évoluer. Faites correspondre la formule du pass, le visiteur, la date et la confirmation du créneau.
The London Pass — Reservations for attractions · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
bookingkit : le minimum de participants se contrôle par commande
Le minimum d’une commande et le seuil nécessaire pour maintenir un départ répondent à deux questions différentes. Le paramétrage bookingkit doit être essayé à cette échelle.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Activation et périmètre | Le module s’active dans les paramètres et se règle pour chaque expérience. | Retrouvez le paramètre de l’expérience vendue, sans supposer qu’il couvre tout le catalogue. |
| Minimum de commande | Le minimum s’applique au panier ou à la commande, pas à chaque date. Avec un minimum de trois, une commande plus petite ne peut pas être finalisée. | Essayez une commande de deux puis de trois personnes sur le même produit. |
| Capacité globale | La capacité totale d’un événement reste distincte du minimum par réservation. | Suivez séparément l’effectif cumulé du départ et les quantités admises dans une commande. |
| Maximum par commande | L’aide indique qu’un plafond automatique de billets par commande n’est pas pris en charge ; elle propose une consigne et un contrôle manuel. | Ne présentez pas une limite écrite dans la description comme un blocage automatique. |
Deux limites de réservation à ne pas confondre
Réglages fictifs pour préparer la recette du parcours.
Deux commandes sont additionnées pour satisfaire le minimum
Un minimum fictif de trois est configuré ; deux clients veulent chacun commander pour deux personnes.
Minimum par commande : 3
Première demande : 2 personnes
Deuxième demande : 2 personnesLecture du cas. Le total potentiel de quatre ne valide pas deux commandes de deux dans ce réglage. Préparez un parcours et une règle commerciale adaptés, puis vérifiez l’effectif réel du départ séparément.
Une consigne de huit billets est prise pour un plafond technique
Une description fictive indique huit billets au maximum par commande, sans contrôle automatique correspondant.
Consigne commerciale : maximum 8
Contrôle automatique établi : non
Surveillance des commandes : à organiserLecture du cas. Organisez la surveillance et le traitement des dépassements avant la mise en vente. La présence de la consigne ne prouve pas qu’une neuvième place sera refusée au paiement.
Aide bookingkit datée du 1er septembre 2026, consultée le 23 octobre 2026. Rejouez le parcours dans le compte et le canal concernés. Ce réglage ne démontre pas, à lui seul, une décision automatique de maintien ou d’annulation du départ.
bookingkit — Minimum number of participants · mise à jour par la source le 01/09/2026 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- Ventrata : Capacité des activités et ressources : Ventrata indique que la disponibilité d’un produit dépend notamment de sa capacité, de ses ressources, des horaires et des réservations. (consultée le )
- TourCMS : API opérateur et marketplace : L’opération Show Supplier de TourCMS est réservée aux comptes opérateurs ; les partenaires marketplace sont orientés vers Show Channel. (consultée le )
- bookingkit : Calendrier des expériences : bookingkit distingue les rendez-vous ponctuels et récurrents et documente leurs dates et heures dans la définition d’une expérience. (consultée le )
- Civitatis : Distribution d’activités pour professionnels : Civitatis Pro présente plusieurs modèles de collaboration pour agences, affiliés, hébergements, OTA et plateformes. (consultée le )
- OCTO — Core Bookings : Le standard ne constitue pas un catalogue vendable et ne prouve pas l’activation de toutes les fonctions pour un revendeur. (consultée le )
- FareHarbor — fonctionnement de Waitlist : Aide FareHarbor mise à jour le 29 septembre 2026. Les types conditionnels, dont enfant exigeant un adulte, ne fonctionnent pas dans Waitlist. (consultée le )
- bookingkit — Monthly View : Fonctions de l’interface bookingkit documentées dans l’aide consultée le 23 octobre 2026. Leur présence ne prouve ni une synchronisation immédiate de tous les revendeurs ni une fonction équivalente dans chaque API. (consultée le )
- Checkfront — Configuring allocation and visibility for items using the Item Builder (Classic Items) : Réglages Classic Items consultés le 23 octobre 2026. Ce périmètre ne décrit pas tous les produits de Checkfront ni le contrat de son API. Les réservations et les quantités des exemples sont fictives. (consultée le )
- OCTO — Availability, API Core : Périmètre : modèle Availability du cœur OCTO, consulté le 23 octobre 2026. Les réponses du fournisseur et leur fraîcheur restent à vérifier. Les heures fictives ci-dessous servent uniquement à comparer les instants ; elles ne décrivent pas une activité proposée à la vente. (consultée le )
- The London Pass — Reservations for attractions : Informations de la page officielle consultées le 23 octobre 2026. Fenêtres de réservation, attractions admises et places proposées peuvent évoluer. Faites correspondre la formule du pass, le visiteur, la date et la confirmation du créneau. (consultée le )
- bookingkit — Minimum number of participants : Aide bookingkit datée du 1er septembre 2026, consultée le 23 octobre 2026. Rejouez le parcours dans le compte et le canal concernés. Ce réglage ne démontre pas, à lui seul, une décision automatique de maintien ou d’annulation du départ. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Peut-on vendre la dernière place sur plusieurs canaux ?
Seulement si l’inventaire et la confirmation évitent deux engagements concurrents. Testez explicitement ce cas avec chaque canal.
Une option consomme-t-elle une place ?
La règle dépend du produit. Sa durée, son effet sur la capacité et sa libération doivent être explicites pour éviter un stock artificiellement bloqué.
Faut-il une jauge par langue ?
Si la langue dépend d’un guide ou d’un départ précis, elle doit être reliée à la capacité correspondante. Une simple traduction de fiche ne garantit pas la prestation dans cette langue.
La capacité d’un produit est-elle toujours son nombre de billets ?
Elle peut dépendre de ressources partagées. Modélisez guide, véhicule, salle ou matériel avant de diffuser le stock.
Un créneau récurrent reste-t-il ouvert pendant une fermeture ?
La récurrence et ses exceptions doivent être configurées et testées. Vérifiez les jours exclus et l’effet sur les réservations déjà confirmées.
Pourquoi séparer quantité commerciale et voyageurs ?
Une unité peut représenter un groupe ou une autre règle de vente. La capacité et la liste de participants doivent rester lisibles avec leur propre unité.
Un jour rouge foncé dans le calendrier bookingkit signifie-t-il que tout est complet ?
Non. L’aide définit le rouge foncé comme le jour ayant le plus de participants du mois. Ouvrez la date et examinez les participants et les capacités des activités ; la couleur seule ne donne pas le stock restant.
Les réservations des attractions London Pass ouvrent-elles toutes trente jours avant la visite ?
Non. La page consultée le 23 octobre 2026 annonce jusqu’à trente jours pour The View from The Shard, quinze pour le London Eye et dix pour Tower Bridge et Westminster Abbey. Relisez la règle de chaque attraction et les créneaux réellement proposés.
Simulation locale
Relire une capacité à un instant donné
Les retenues sont supposées distinctes des confirmations. Le calcul ne lit aucun stock réel et ne garantit pas une place.
| Résultat illustré | Exemple |
|---|---|
| Solde arithmétique | 5 places |
| Dépassement dans cet exemple | 0 place |
Calcul : capacité − confirmations − retenues.
Hypothèses de l’exemple
- Capacité saisie : 20
- Places confirmées saisies : 12
- Places temporairement retenues saisies : 3
Aucun accès à vos dossiers ou à un fournisseur. Les calculs restent dans cet onglet, sans envoi ni sauvegarde par ce module.
