Questions fréquentes sur Scorpaq

Scorpaq est une plateforme de commerce, d’opérations et d’analyse décisionnelle pour restaurants, cafés, hôtels et complexes hôteliers.

Le produit est en cours de développement. Ce site présente son orientation et recueille les demandes d’accès anticipé ; il n’active pas un espace de travail opérationnel.

Non. Le QR ouvre un parcours de découverte, commande et paiement relié aux opérations et aux analyses.

Un menu affiche les produits et les prix ; le parcours prévu transmet aussi la commande à la préparation et au service. Scorpaq n’est pas un système complet de caisse, de PMS ou d’ERP.

Non. Le parcours principal fonctionne dans le navigateur du téléphone.

Le client ouvre le lien QR de l’établissement et consulte le menu proposé dans son navigateur. Les points de service et les moyens de paiement dépendent de la configuration de l’établissement.

Non. Découvrir, commander et payer ne nécessite pas de compte client persistant.

Une commande conserve son contexte de service et son enregistrement de transaction. L’absence de compte obligatoire ne signifie pas qu’aucune donnée de commande ou de paiement n’est traitée.

Aux établissements d’hôtellerie-restauration, notamment restaurants, cafés, hôtels et complexes hôteliers.

Un café peut organiser ses tables ; un hôtel, le service en chambre et la piscine. Chaque établissement configure son menu, son équipe et ses points de service sans devoir utiliser tous les contextes.

Scanner → Découvrir → Commander → Payer.

Le lien QR identifie le point de service ; le client consulte le menu et compose sa commande. Le paiement suit les options proposées, et le résultat en ligne doit être vérifié avant de considérer la commande comme payée.

Oui. Les clients peuvent consulter le menu disponible avant de décider.

Consulter le menu n’engage pas à acheter. Le client choisit les articles et décide de poursuivre selon les prix et la disponibilité indiqués par l’établissement.

Oui. Il est conçu en priorité pour le navigateur du téléphone.

L’objectif est un parcours mobile clair jusqu’à la confirmation. Les visuels conceptuels du site ne certifient pas la compatibilité avec tous les appareils ou navigateurs.

Non. Le socle ne crée ni identité persistante ni empreinte entre établissements.

Une commande reste rattachée à son établissement et à son contexte de service. Aucun profil client commun ni identité publicitaire entre établissements n’est présenté comme fonction de base.

Oui. Le fonctionnement multilingue fait partie de la conception.

Ce site propose huit langues avec une sélection manuelle. Les langues du produit destiné aux clients et sa disponibilité par pays doivent être confirmées pour le déploiement réel ; les traductions du site ne les garantissent pas.

En reliant découverte du menu, commandes, options de paiement, traitement des commandes et visibilité opérationnelle.

Le parcours prévu relie la table ou un autre point de service à la commande, à la préparation et à l’état du service. L’équipe reste responsable de l’exécution et des exceptions.

Oui. Les restaurants et cafés indépendants sont une cible principale.

L’objectif est une configuration autonome du menu, des points de service et des rôles. Une demande d’accès anticipé n’active automatiquement ni le service ni un prestataire de paiement.

L’architecture permet plusieurs sites ; le déploiement commercial dépend du contexte.

Les sites sont rattachés à la structure concernée, avec des droits et un contexte opérationnel explicites. La configuration et le périmètre commercial d’un réseau doivent être convenus avant activation.

Non. Elle vise à réduire les obstacles évitables et à soutenir les équipes.

Les clients peuvent toujours demander de l’aide à l’équipe. La commande numérique vise à réduire les tâches répétitives, tout en laissant à l’équipe la responsabilité de l’accueil.

Non. Le socle V1 ne dépend pas d’intégrations natives POS, PMS ou ERP.

Aucune synchronisation automatique avec une caisse, un système hôtelier ou un logiciel comptable existant n’est promise. Les processus séparés et leurs limites doivent être examinés avant le pilote.

Oui. Les hôtels et complexes hôteliers sont une cible principale.

L’hôtel choisit les espaces, menus et équipes à configurer. Scorpaq ne devient pas pour autant un système de réservation ou de gestion des séjours.

Service en chambre, restaurant, bar, piscine et salon.

Chaque espace configuré nécessite un point de service clair pour situer la commande. Citer un espace ne garantit pas que tous les processus de l’établissement sont déjà disponibles.

Oui. Un socle commun adapte l’expérience aux différents contextes de service.

Les espaces partagent le modèle de base, mais peuvent avoir des menus et responsabilités différents. L’aperçu explique cette structure ; il ne prouve pas un déploiement hôtelier en production.

Oui. C’est un usage hôtelier prévu.

Le lien de chambre ou de point de service fournit le contexte opérationnel. La consultation automatique du PMS, l’imputation sur la chambre et la synchronisation des réservations ne sont pas promises.

Cela peut être pris en charge lorsque l’établissement active ce service.

L’établissement doit identifier le point de service et l’offre disponible. Cela n’implique ni suivi automatique des clients ni détection de leur position.

L’architecture prévoit des paiements indépendants du prestataire, selon sa disponibilité, le pays et la préparation du déploiement.

L’établissement doit disposer d’une relation adaptée avec un prestataire compatible. Ce site de présentation ne reçoit pas de paiements de clients et une candidature ne les active pas.

Si la politique de l’établissement le permet, le règlement en espèces ou par terminal physique sur place peut compléter le paiement en ligne via prestataire.

Le règlement sur place suit le processus de collecte et de confirmation de l’établissement. Un paiement sur terminal physique n’est pas automatiquement vérifié par une intégration native de caisse.

Non. Scorpaq ne conserve ni ne redistribue leurs fonds.

Le traitement reste dans la relation entre le prestataire et l’établissement. Il est distinct de l’abonnement Scorpaq payé par l’établissement.

Les paiements hébergés par le prestataire sont privilégiés pour éviter leur entrée dans la logique, les journaux ou les analyses.

Les données de carte doivent être saisies sur la page du prestataire, pas dans les formulaires de Scorpaq. Le paiement redirigé ne constitue à lui seul ni certification ni garantie pour chaque configuration.

Non. Le serveur et le prestataire doivent vérifier le paiement.

La page de retour peut s’afficher avant la confirmation du prestataire ou après une coupure. Un résultat incertain doit le rester jusqu’à sa résolution par la vérification serveur.

Par l’idempotence, la protection contre le rejeu, la vérification du prestataire et la gestion sûre des états incertains.

Une nouvelle tentative du navigateur ne doit pas créer une seconde transaction. Cela réduit les doublons techniques, sans garantir l’absence de tout incident de paiement.

La gestion des menus et catalogues fait partie du socle : catégories, articles, options et disponibilité.

L’établissement contrôle ce que les clients peuvent voir et commander à ses points de service. Configurer le menu n’implique aucune synchronisation automatique des stocks, des achats ou de la comptabilité.

Oui. Propriétaire, responsable, personnel de salle et cuisine disposent d’autorisations explicites.

Chaque rôle doit recevoir les accès nécessaires dans l’établissement autorisé. Connaître un lien ou voir un bouton n’autorise pas à modifier les commandes ou les paramètres sensibles.

Analyses et rapports font partie de l’orientation du produit et doivent refléter honnêtement la qualité des données.

Les exemples comprennent les retards de service, les produits indisponibles et les coûts incomplets. Les graphiques et valeurs conceptuels ne sont ni des résultats clients ni des gains garantis.

Les rapports concernés sont conçus pour l’export, notamment vers des formats adaptés à Excel.

L’objectif est de rendre les rapports utilisables hors du tableau de bord. Les champs, filtres et exports disponibles sont à vérifier pendant le pilote, pas à déduire d’un visuel conceptuel.

Non. Les données absentes ou fragiles ne doivent pas devenir un zéro mesuré ou une fausse certitude.

Une analyse doit préciser les données disponibles et les lacunes restantes. Un chiffre d’affaires sans coûts suffisants n’est pas une mesure complète de rentabilité.

L’espace de travail est la limite principale, renforcée par des contrôles d’autorisation et de base de données.

Connaître l’identifiant d’un autre établissement ne doit pas donner accès à ses données. Cette page décrit une limite de conception, pas un audit indépendant ou une certification.

Non. Les limites importantes sont appliquées côté serveur et base de données lorsque cela s’applique.

Le serveur doit vérifier l’identité, le rôle et le périmètre de l’établissement pour chaque demande. Masquer un contrôle dans le navigateur ne fait pas respecter une autorisation à lui seul.

Oui. C’est un principe central ; aucun compte n’est obligatoire pour le parcours principal.

Les données nécessaires à la commande ou à la vérification d’un paiement sont distinctes du compte ou du choix commercial facultatif. L’avis du site couvre ses formulaires, pas un futur service client en production.

Non. Ce ne sont pas des entrées publicitaires ou de profilage par défaut ; le consentement marketing reste séparé.

Les messages doivent servir leur objectif de service, sans devenir discrètement des profils publicitaires. Le choix commercial de l’accès anticipé est séparé de la sélection de la source de découverte.

Sur la page Contact existante.

Choisissez le sujet confidentialité/données pour une demande concernant vos informations, ou décrivez le problème de sécurité. N’envoyez ni mots de passe, ni données complètes de carte, ni pièce d’identité au premier contact.

Scorpaq prépare l’accès anticipé avec des établissements adaptés ; ils peuvent déposer une demande.

La demande recueille le contexte de l’établissement pour examiner sa pertinence et discuter des étapes suivantes. Elle ne garantit ni acceptation, ni date de lancement, ni accès immédiat.

Un modèle commercial défini couvre différents établissements et structures. Les tarifs sont communiqués directement lors d’échanges qualifiés d’accès anticipé et commerciaux.

Le type d’établissement et son organisation aident à définir le périmètre commercial. Une demande n’est pas un achat ; prix et conditions d’abonnement doivent être convenus séparément.

Le modèle actuel ne comprend pas d’offre gratuite à vie en production.

Le formulaire et l’aperçu ne constituent pas un abonnement gratuit illimité. L’accès et les conditions commerciales sont précisés avant de commencer à utiliser le service.

Ce n’est pas le parcours commercial par défaut du modèle actuel.

Envoyer une demande ne lance pas une période d’essai et ne crée pas d’engagement de paiement. Durée, périmètre et conditions financières du pilote doivent être discutés séparément.

Remplissez le formulaire d’accès anticipé de Scorpaq.

Indiquez des coordonnées et des informations exactes sur l’établissement ; sa localisation et son activité aident à comprendre ses besoins. Sources de découverte et e-mails commerciaux sont facultatifs ; mots de passe, cartes et pièces d’identité sont inutiles.