Ce qu'un système de réservation doit savoir faire quand vous ne maîtrisez pas la vente

La plupart des logiciels de réservation de parking sont pensés pour un acheteur qui maîtrise sa vente. Un parking commercial ne la maîtrise pas. Entre la moitié et la quasi-totalité de ses nuitées sont vendues par une autre société, sur le site d'une autre société, au prix que cette société a fixé. La fonction qui décide si le logiciel tient la route n'est donc pas le formulaire de réservation. C'est ce que fait le système quand deux canaux vendent la même place pour la même nuit et qu'aucun des deux ne vous prévient.

Les pages qui sortent aujourd'hui sur ce sujet parlent de réservation de places pour des salariés. Ces produits font très bien leur travail. Leur acheteur possède la place et connaît la personne qui la prend. Vous, ni l'un ni l'autre.

Le formulaire de réservation, c'est la partie facile

N'importe quel éditeur sait faire un formulaire. Le problème d'un parking commercial, c'est que presque personne ne le remplit.

Les réservations arrivent de revendeurs qui ont leur propre tunnel d'achat, leur propre mail de confirmation et leur propre numérotation. Elles arrivent aussi de votre site, d'un appel un mardi après-midi, et d'un conducteur qui se présente à 5h20 sans rien avoir réservé. Un système qui part du formulaire et traite tout le reste comme de l'import part de la plus petite source de volume que vous ayez.

Autant le dire tout de suite, parce que la question tombe à chaque démonstration : ParkAgenda ne fournit pas de moteur de réservation pour votre site et n'expose aucune recherche de disponibilité publique. Si vous vendez en direct, votre site devient une source de réservation comme une autre, avec sa numérotation et un taux de commission à zéro. Le produit, c'est l'arrière-boutique d'exploitation, pas la vitrine.

Les quatre chemins par lesquels une réservation entre vraiment

Il y a quatre voies d'entrée, et un éditeur doit pouvoir vous montrer les quatre en fonctionnement sur un vrai parking. Demandez la démonstration dans cet ordre. La première est celle que la plupart des produits ne savent pas faire.

• Le format de mail du revendeur. Votre parking reçoit une adresse surveillée. Le revendeur continue d'envoyer exactement le mail qu'il envoie déjà, et un adaptateur écrit pour lui le transforme en réservation. On ne demande rien au revendeur, parce que le revendeur ne changera rien.
• Une récupération par API. ParkAgenda interroge Parkos aujourd'hui, marchand par marchand, avec un curseur sur ce qui a bougé depuis le dernier passage, un recouvrement volontaire et un rapprochement sur la fenêtre d'arrivée. La réponse brute est conservée à côté de la synchronisation, pour que vous puissiez vérifier ce que le revendeur a réellement envoyé.
• Un import CSV. Idempotent sur le triplet parking, source et référence : rejouer le même fichier ne change rien. Chaque ligne revient créée, mise à jour, inchangée ou en échec avec un motif. C'est comme cela que l'historique est repris. Aujourd'hui c'est notre équipe qui le lance, pas vous.
• Quelqu'un qui saisit. Le comptoir, le téléphone, le client sans réservation. C'est une réservation comme les autres, rattachée à sa source, dans la même file.

Maintenant la partie honnête. Capter un revendeur nommé, cela veut dire un analyseur que notre équipe a écrit et qu'elle maintient. Ce n'est pas un partenariat certifié et il n'existe aucun catalogue de connecteurs à parcourir. La liste des noms est courte et finie. Parkos et AlloPark y figurent. Une source absente de la liste passe par l'API REST ou par un CSV, et écrire un nouvel adaptateur est un travail qui se chiffre comme un travail. Si un éditeur vous parle de connecteurs prêts à l'emploi, demandez-lui lequel de vos quatre revendeurs il a déjà analysé.

La nuit où deux canaux vendent la même place

Voici un exemple chiffré. Les chiffres sont construits pour l'exemple, ils ne sont pas mesurés.

Prenez un parking de 250 places près de Roissy. Durée moyenne de séjour de neuf jours, donc environ vingt-huit voitures qui entrent et vingt-huit qui sortent un jour ordinaire. Soixante-dix pour cent des nuitées passent par des revendeurs, répartis sur quatre enseignes, avec une commission comprise entre quinze et vingt-cinq pour cent. Comptez 81 euros le séjour, neuf euros la nuit.

Mardi, un client réserve neuf jours chez le revendeur A. Jeudi, il retrouve les mêmes dates quatre euros moins cher chez le revendeur B, réserve à nouveau et annule la première. Le revendeur A enregistre l'annulation dans son espace à 23h40. Le revendeur B envoie sa confirmation deux minutes plus tard. Si votre seule synchronisation est un export nocturne, vous détenez maintenant deux réservations vivantes pour une seule voiture, et vendredi matin votre tableau affiche 251 voitures pour 250 places.

Les 81 euros ne sont pas le coût principal. Le coût principal, ce sont les quinze minutes qu'un opérateur passe à 5h du matin à chercher laquelle des deux est la bonne pendant que la file s'allonge derrière le comptoir, puis le relevé du revendeur en fin de mois qui facture une commission sur un séjour qui n'a jamais eu lieu. Multipliez par un mois de juillet où cela arrive quatre fois par semaine.

Ce que le système doit en faire : garder les deux enregistrements, repérer que c'est la même voiture sur la même fenêtre, et laisser un humain les fusionner en une seule réservation qui conserve les deux références. La référence doit survivre à la fusion, parce que c'est avec elle que vous discutez la ligne de commission.

La deuxième chose à faire, c'est redemander. Les annulations arrivent en retard et dans le désordre. Une récupération qui ne va chercher que les réservations créées depuis le dernier passage ne verra jamais une annulation antidatée. D'où le recouvrement sur le curseur, et le rapprochement de la fenêtre d'arrivée plutôt que la confiance.

Ce qui doit arriver à une réservation illisible

Une réservation illisible doit s'arrêter, conserver le mail d'origine et dire pourquoi. Elle ne doit jamais être devinée, ni disparaître en silence.

Un revendeur change son gabarit de confirmation à la mi-août. Vous êtes l'un de ses huit cents parkings et personne ne vous prévient. Pendant une semaine, l'analyseur ne sort plus rien d'exploitable. Si ces réservations s'évaporent, vous l'apprenez au comptoir. Si elles atterrissent dans une file de contrôle avec le mail brut et un motif sur chacune, un opérateur les promeut à la main en dix minutes par jour et vous nous demandez de corriger l'adaptateur.

La même file traite l'autre panne : un mail venu d'une adresse jamais vue. ParkAgenda autorise des adresses exactes, pas des domaines. C'est plus long à mettre en place et c'est le bon arbitrage, parce qu'autoriser un domaine revient à laisser n'importe quelle boîte mail de ce revendeur écrire dans votre exploitation.

Depuis cette file, un humain promeut la réservation, la retraite une fois l'adaptateur corrigé, autorise l'expéditeur ou l'écarte. Rien ne part tout seul.

Le nom du revendeur n'est pas le nom sur la carte grise

Le rapprochement est la partie difficile du travail multicanal, pas la captation. Capter, c'est un analyseur. Rapprocher, c'est un arbitrage, et le système doit poser les éléments devant un humain au lieu de faire semblant.

Le revendeur envoie Jean-Pierre Delacroix-Martin. Au comptoir, le client dit Delacroix. La plaque a été saisie par ce client sur un téléphone à une heure du matin, avec un espace au mauvais endroit. Chaque canal numérote ses réservations à sa façon, donc la référence est la seule clé fiable, et elle n'est unique qu'à l'intérieur de sa propre source. C'est pour cela que la déduplication tourne sur parking, source et référence, et c'est pour cela que la plaque portée par la réservation reste un champ texte saisi par quelqu'un, pas une vérité connue du logiciel.

Ce dernier point compte si vous exploitez déjà une lecture automatique de plaques à l'entrée. Ce que lit votre caméra doit correspondre à une chaîne tapée par un inconnu dans le tunnel d'un revendeur quinze jours plus tôt. ParkAgenda ne lit pas les plaques et ne pilote pas votre barrière. Il porte la plaque sur le séjour pour que votre système ait quelque chose à rapprocher, et notre équipe construit le connecteur avec votre fournisseur.

Cinq choses à faire montrer à un éditeur

1. Une réservation qui entre par mail dans le format du revendeur, sans que le revendeur ait rien changé.
2. La file où attend une réservation illisible, avec la preuve brute à côté.
3. Ce qu'affiche l'écran quand vous tentez d'entrer la 251e voiture dans 250 places.
4. Le même client réservé deux fois sur deux canaux, fusionné en un séjour qui garde les deux références.
5. La liste des sources nommées prises en charge aujourd'hui, et un chiffrage pour celle qui vous manque.

Si un éditeur ne sait pas faire la première, tout le reste est de la théorie.

Questions fréquentes

Est-ce que ParkAgenda encaisse le paiement de mon client ?

Non. Les montants portés par une réservation sont ce que le canal déclare payé et ce qui reste dû. L'argent encaissé au comptoir est écrit dans un journal en ajout seul, avec le nom de l'opérateur sur chaque ligne, en espèces ou en carte. Carte veut dire ici que le client a payé sur votre propre terminal et qu'un opérateur l'a déclaré. Il n'y a aucun traitement de paiement dans le produit.

La synchronisation avec les revendeurs est-elle en temps réel ?

Non, et méfiez-vous d'un éditeur qui affirme le contraire. La récupération par API tourne sur une minuterie, avec curseur et recouvrement. Le mail arrive quand le revendeur l'envoie. Rien n'est jamais réécrit chez le revendeur : une annulation faite dans ParkAgenda n'annule rien chez lui.

Puis-je mettre un formulaire de réservation sur mon site ?

Pas avec ParkAgenda. Il n'y a ni widget ni recherche de disponibilité anonyme. Les réservations issues de votre site entrent comme une source de réservation ordinaire, par l'API ou par mail.

Par où commencer

Pour savoir si vos canaux sont lisibles, envoyez-nous un mail de confirmation par revendeur, données personnelles retirées. Cela suffit à vous dire lesquels s'analysent aujourd'hui, lesquels demandent un adaptateur, et ce que coûte celui qui manque.

La page fonctionnalités couvre ce qui se passe après la captation. La page tarifs tient en une offre facturée à la licence par parking. Si vous quittez un autre système, lisez ensuite comment sortir du tableur sans perdre les références, et pourquoi un logiciel de parking d'entreprise ne peut pas faire tourner un parking payant explique pourquoi une bonne partie de ce marché ressemble à un concurrent sans en être un.