Listes de demandes

Les listes de demandes permettent de gérer les processus de demande dans les offres. Les participants peuvent demander une réservation, un intermédiaire peut l’approuver ou la refuser, ou vous pouvez inviter des personnes ciblées à une offre.

Selon la configuration, edoobox retient des places pendant la période de demande, envoie des rappels, joint le Booking.pdf de la demande et inscrit les personnes dans la liste définitive des participants après acceptation. Pour chaque liste, vous définissez un nom public, un rappel, une durée de validité, l’envoi de Booking.pdf et la création de réservations provisoires.

Vidéos explicatives

Ces vidéos complètent ce guide. La langue parlée est indiquée pour chaque vidéo.

Les images d’aperçu sont chargées directement depuis ce site. La lecture établit une connexion avec YouTube, uniquement pour la vidéo choisie.

Cette vidéo présente la demande de devis comme étape préalable à une réservation définitive. Elle explique la liste des demandes, le devis PDF, l’acceptation ou le refus, ainsi que le suivi et les rappels des demandes en attente.

L’exemple date de 2024. Si l’approbation est obligatoire, vérifiez tous les points d’entrée de réservation. Un bouton d’inscription standard supplémentaire ne déclenche pas automatiquement la même procédure d’approbation.

Voir sur YouTube

Exemples de listes de demande

Réservation soumise à approbation : Une employée effectue une réservation provisoire et transmet la confirmation de demande à sa supérieure hiérarchique. La réservation ne devient définitive qu'après approbation.
Manifestation d'intérêt : Les personnes intéressées formulent une demande, et des places peuvent être réservées jusqu'à la décision.
Invitation pour un groupe de personnes spécifique : Un département ou un groupe de VIP reçoit une invitation et peut accepter ou refuser en quelques clics.
Préinscription avec délai de réponse limité : Vous envoyez des invitations, définissez une durée de validité et libérez les places après expiration.

Les listes de demandes constituent ainsi une étape intermédiaire avant la réservation définitive. Elles conviennent non seulement aux situations classiques de liste d'attente, mais aussi aux approbations internes, aux séminaires avec admission, aux invitations de sponsors ou aux offres pour lesquelles une place ne doit être confirmée qu'après vérification manuelle. Si les personnes doivent elles-mêmes initier une demande, vous avez besoin du bouton de demande dans le processus de réservation. Si vous invitez activement les personnes, ce bouton public peut être omis.

1. Créer une liste de demandes

Ouvrez dans le menu de l'application Listes de demandes et créez une nouvelle liste. Saisissez une désignation publique, qui peut être visible dans l'administration, les e-mails et, selon le processus, dans le processus de réservation. Maintenez la désignation dans toutes les langues actives.

Paramètre	Effet
Valeur par défaut	La liste est automatiquement ajoutée aux nouvelles offres.
Envoyer également le PDF de réservation	Le Booking.pdf de la demande est joint à l'e-mail de la liste des demandes.
Créer des réservations provisoires	Des places sont réservées pour les demandes ouvertes ; cette option nécessite le PDF de réservation.
Rappel	Définit quand les demandes ouvertes sont rappelées.
Validité	Définit jusqu’à quand une réponse à la demande est possible.

Le rappel doit précéder la fin de validité de la demande. Selon le processus, le rappel et la durée de validité peuvent être calculés à partir du début de l’offre ou de la date de la demande. Si vous activez les réservations provisoires, les places déjà réservées et celles retenues par des demandes sont comptabilisées ensemble afin que les participants ne puissent pas surréserver dans le processus public. Selon leurs droits, les administrateurs peuvent néanmoins effectuer une surréservation manuelle. Si Booking.pdf n’est pas envoyé, la logique de réservation peut être limitée selon la configuration ; vérifiez donc ensemble l’envoi du PDF et les réservations provisoires.

Saisissez la désignation publique et tous les messages dans toutes les langues actives. Si une traduction est manquante, la liste des demandes peut apparaître incomplète ou dans la mauvaise langue lors du processus de réservation.

Formulaire, langue et deuxième adresse e-mail

Pour les processus d'approbation, une deuxième adresse e-mail est souvent nécessaire, par exemple l'adresse d'un supérieur hiérarchique. Créez à cet effet un champ de données participant approprié et réglez la visibilité de manière à ce que le champ n'apparaisse dans le processus de liste des demandes que lorsqu'il y est nécessaire.

Dans les modèles d'e-mail, vous pouvez utiliser ##OfferlistSecondMailExists## pour vérifier si une deuxième adresse e-mail est présente. Ainsi, des informations supplémentaires ne s'affichent que si la demande est effectivement envoyée à une autre personne. La logique exacte pour les conditions se trouve dans IF et EACH dans les modèles d'e-mail.

Règles de validité personnalisées

À l'aide de règles personnalisées, vous déterminez le délai de réponse en fonction de l'intervalle avant le début de l'offre. Jours avant le début ≥ est une limite inférieure : si plusieurs règles correspondent, la limite inférieure la plus élevée applicable est retenue. Jours de validité est calculée à partir de la demande et ne doit pas être supérieure à la limite inférieure saisie dans l'interface utilisateur.

Jours avant le début ≥	Jours de validité	Exemple
30	14	Avec 40 jours d'avance, la nouvelle demande reste valable 14 jours.
7	3	Avec 10 jours d'avance, elle reste valable 3 jours.
1	1	Avec 2 jours d'avance, elle reste valable 1 jour.

Aucune plage correspondante : Avec moins d'un jour d'avance, aucune ligne ne correspond dans cet exemple. Cela peut entraîner une demande sans date d'expiration calculée. Même au moment du début ou après celui-ci, cette échelle de règles n'est pas un délai automatique fiable. Vérifiez la valeur de validité réelle d'une demande de test de dernière minute. Si chaque demande doit recevoir un délai fixe, utilisez à la place une validité simple appropriée à partir de la saisie ou avant le début de l'offre.

Vérifiez le rappel et la validité ensemble : un rappel doit être effectué suffisamment tôt avant l'expiration effective. Décidez en équipe s'il faut créer une nouvelle demande après l'expiration du délai ou contacter d'abord la personne.

2. Ajouter la liste de demandes à l'offre

Ouvrez l’offre souhaitée, puis accédez à Listes de demandes via Plus. Vous y trouvez les listes disponibles et ajoutez celle qui convient à l’aide du bouton plus. Les listes par défaut apparaissent automatiquement dans les nouvelles offres ; vérifiez les offres existantes et complétez-les manuellement si nécessaire.

Plusieurs listes par offre sont possibles si vous souhaitez séparer différents processus, par exemple l'approbation interne et l'invitation VIP.

3. Intégrer le bouton de demande dans le processus de réservation

Pour permettre aux participants de soumettre une demande sur le site web, insérez le widget Bouton de demande dans le modèle Détails de l'offre du Design Manager. Associez la liste de demandes souhaitée et ajustez les libellés de début et de fin ainsi que la couleur du bouton.

Si plusieurs listes de demandes sont utilisées, créez un bouton de demande distinct pour chaque liste. Vérifiez ensuite l'affichage public avec une réservation de test.

4. Ajuster le processus de décision

La page de décision, sur laquelle les demandes sont acceptées ou refusées, est conçue dans le Design Manager dans le modèle Demandes : Accepter ou Refuser. Testez la page avec une demande de démonstration réelle dans un second onglet du navigateur afin que les modifications enregistrées soient visibles immédiatement.

Sur la page de fin, les textes de remerciement, les boutons de décision et les noms des pièces jointes PDF peuvent être adaptés selon le widget. Cela est important lorsque les mêmes modèles sont utilisés pour les autorisations et les invitations.

5. Modèles d’e-mail et conditions IF

Des modèles spécifiques sont disponibles pour les listes de demandes : E-mail de liste de demandes, E-mail de rappel de liste de demandes, E-mail de refus de liste de demandes et Booking.pdf (liste de demandes). Ces modèles s’appliquent à toutes les listes de demandes du compte et doivent donc être formulés de manière suffisamment générale.

La variable de remplacement ##OfferlistSecondMailExists## peut être utilisée dans les conditions IF lorsqu’une deuxième adresse e-mail est présente. Il faut pour cela disposer d’un champ de données participant adapté dans les paramètres globaux des e-mails.

{IF?OfferlistSecondMailExists = true}Cette demande est également envoyée à la seconde adresse e-mail enregistrée.{ENDIF}

Si la deuxième adresse e-mail ne doit apparaître que pour les listes de demande, réglez la visibilité du champ dans le formulaire participant sur le type de réservation Seule la liste de demande est autorisée. Approfondissement : IF et EACH dans les modèles d'e-mail.

6. Consulter les réservations de liste de demande

Dans l’offre, ouvrez la section Listes de demandes via Participants. Sélectionnez la liste pour voir toutes les demandes avec les statuts en attente, accepté, refusé ou expiré. Les demandes ouvertes méritent une attention particulière, car une décision reste à prendre. Après acceptation, la réservation est finalisée et la personne est ajoutée à la liste définitive des participants.

La liste peut être contrôlée et exportée par statut. Les demandes ouvertes sont particulièrement importantes, car elles réservent des places selon les paramètres. Les demandes acceptées doivent ensuite être vérifiées dans la réservation, la facture, le paiement et l'historique des e-mails. Les demandes refusées restent visibles pour la traçabilité, mais ne peuvent pas être converties automatiquement en réservations définitives.

7. Inviter, rappeler et exporter les participants

Pour les invitations actives, ouvrez Offre → Participants → Listes de demandes, sélectionnez la liste et ajoutez des personnes. Envoyer les demandes et Envoyer les rappels prennent en compte les entrées de cette liste qui n'ont pas encore reçu de réponse dans l'offre choisie. Un filtre de tableau ne limite pas cet envoi en masse aux lignes actuellement visibles.

Le guide complet Invitations, rappels et export CSV explique le périmètre de l’envoi, la limite de 5 000 entrées par export ainsi que les liens de décision personnels et les codes QR.

Deux procédures courantes

Procédure	Que configurer ?	Important
Réservation soumise à approbation	Créer une liste de demandes, l'ajouter à l'offre, intégrer le bouton de demande dans Design Manager, et tester la page de décision et les modèles d'e-mail.	La réservation, la validité, le rappel et la deuxième adresse e-mail sont cohérents.
Envoyer des invitations	Créer une liste de demandes, l'ajouter à l'offre, importer ou sélectionner des personnes, envoyer l'invitation.	Un bouton de demande public n'est pas obligatoire si seules les personnes invitées activement doivent répondre.

Lorsque les réservations provisoires sont actives, les places déjà réservées et les places retenues par les demandes ouvertes sont additionnées. edoobox empêche ainsi la surréservation dans le processus public. Les administrateurs peuvent néanmoins surréserver manuellement selon leurs droits ; ces cas doivent être documentés en connaissance de cause.

Vérifier l'approbation pour chaque inscription supplémentaire

Une connexion confirme l’identité ; elle ne transforme pas automatiquement une inscription normale ultérieure en demande soumise à approbation. Le bouton de demande lance le processus lié à la liste concernée. Un bouton d’inscription standard ou un lien direct de réservation déjà distribué peut, en revanche, ouvrir un autre parcours.

Associez la liste de demandes à l'offre et vérifiez dans le design utilisé le bouton de demande, y compris le choix de la liste et le champ de la deuxième adresse e-mail.
Retirez les actions d'inscription normales proposées en parallèle des conceptions pertinentes pour le processus de validation publique prévu. Vérifiez également l'aperçu des offres, la page de détail et les liens du site web existants.
Lancez une demande avec un testeur non connecté. Vérifiez le statut de la liste ouverte, le destinataire responsable, la page de décision personnelle et l'état avant l'acceptation.
Restez ensuite connecté et lancez une autre inscription pour la prochaine offre soumise à validation. Le processus de demande avec vérification individuelle doit à nouveau se produire.
Vérifiez en outre un lien direct normal encore connu. Si une réservation définitive sans validation en résulte, le processus souhaité n'est pas encore entièrement sécurisé. Clarifiez ce chemin avant la mise en service.

Masquer un bouton ne bloque pas côté serveur tous les anciens liens de réservation ou les parcours alternatifs. Aucun paramètre général du compte n’est garanti ici pour convertir rétroactivement tout parcours de réservation standard en demande. Documentez les points d’entrée prévus et examinez les exceptions avec le support.

Dans le cas d'une inscription collective, la décision reste commune ; une validation distincte par supérieur hiérarchique pour chaque personne n'en résulte pas. Si chaque personne a besoin d'une décision individuelle, planifiez des demandes séparées et vérifiez leurs destinataires.

Cycle de contrôle avant le déploiement

Testez toujours une liste de demandes avec une demande de démonstration avant d'inviter de vraies personnes. Vérifiez à cet égard la page publique de l'offre, le bouton de demande, la page de confirmation, l'e-mail de la liste de demandes, le Booking.pdf, l'e-mail de rappel et le changement de statut dans l'administration.

La désignation publique est-elle gérée dans toutes les langues actives ?
Le bouton de demande est-il associé à la bonne liste ?
La durée de validité et le rappel sont-ils appropriés sur le plan métier ?
Les réservations provisoires et Booking.pdf ont-ils été vérifiés ensemble ?
Les modèles d'e-mail sont-ils formulés de manière suffisamment générale pour toutes les listes de demandes ?
La page de décision pour l'acceptation et le refus a-t-elle été testée ?
L'export et le lien de code QR ont-ils été vérifiés avec des données de démonstration ?

Dans les processus d'approbation, il doit être clair qui reçoit la demande, qui est habilité à prendre une décision et ce qui se passe après une acceptation ou un rejet. Dans les processus d'invitation, il doit être clair si les personnes qui ne répondent pas sont rappelées, réinvitées ou contactées manuellement.

Exemple d'application : tester une demande avec approbation du supérieur hiérarchique

Une personne de test lance une réservation provisoire via le bouton Demande. L'administration vérifie si l'e-mail avec Booking.pdf est bien reçu, si la page de décision est compréhensible et si, après acceptation, la personne apparaît dans la liste définitive des participants. Ensuite, une deuxième demande est rejetée afin de vérifier également cet état.

Important à savoir : Limitations

Fonction	Limitation avec les listes de demandes
MustPay	Peut être activé, mais n'a pas d'effet de paiement contraignant en cas d'acceptation ; la réservation peut être créée avec l'état Paiement en attente.
Inscription groupée	Pour les réservations groupées, seule la personne de contact est affichée dans la liste ; l'acceptation ou le refus s'applique à l'ensemble.
Compte à rebours	Non affiché dans la liste des demandes.
Multi-offre	Ne peut pas être combiné.
Choix libre de la date	Ne peut pas être combiné.

Activez dans les Paramètres e-mail l'e-mail lors de l'inscription si votre équipe doit être informée rapidement des nouvelles demandes. L'e-mail d'information d'inscription peut être étendu avec des variables de remplacement appropriées.

Vérifiez également avec soin les listes de demandes utilisées avec des types d’offres spécifiques. Les multi-offres, le libre choix des dates et les processus Countdown ne sont pas des combinaisons standard pour les listes de demandes. Même lorsque MustPay est activé, l’acceptation ne déclenche pas automatiquement une étape de paiement obligatoire comme dans une réservation immédiate standard.

Le rappel et le délai de réponse sont des paramètres distincts

Même sans date de fin de validité fixe, une demande peut posséder une date de rappel. Le rappel automatique vérifie un moment de rappel enregistré qui est arrivé à échéance, ainsi qu'une entrée ouverte et non encore marquée comme rappelée. L'activation d'un rappel ne génère donc pas simultanément un délai de réponse.

Avant toute utilisation, choisissez si une demande doit rester valable sans limite de temps ou expirer après une durée fixe. Dans l’entrée de démonstration, vérifiez les dates de fin de validité et de rappel réellement enregistrées. Si votre processus exige une date limite, ne vous fiez pas uniquement au réglage du rappel. Après une modification ultérieure, suivez la procédure de vérification des entrées existantes.

Contrôler les délais

Pour les listes de demandes, le rappel et la validité sont étroitement liés. Le rappel doit être envoyé avant l'expiration de la demande, afin que la personne interrogée puisse encore réagir. Testez donc l'invitation, le rappel, l'acceptation, le refus et la demande expirée en tant que processus complet.

Gérer les demandes expirées et retirées

Le tableau distingue désormais explicitement les statuts en attente, accepté, refusé et expiré. Les statuts en attente et expiré ne sont pas des décisions librement sélectionnables à la main. Avant de relancer une invitation expirée, vérifiez d’abord sa validité et la capacité actuelle.

Si une réservation de demande encore ouverte est annulée, les nouvelles conditions d'annulation n'entraînent ni frais d'annulation ni remboursement automatique. En revanche, une réservation devenue définitive après acceptation est traitée dans le processus d'annulation normal. Après chaque décision, vérifiez la réservation, la facture et l'historique des e-mails.