Scorpaq FAQ

Scorpaq is a Hospitality Commerce, Operations & Intelligence Platform connecting guest ordering, service operations, payments and business performance.

The product is in development; this website explains its direction and accepts Early Access applications. It is not an activated business workspace.

No. QR is an entry point; Scorpaq connects browse, order and payment with service operations and business intelligence.

A menu displays items and prices; the planned workflow also carries an order into preparation and service. Scorpaq is not a full POS, PMS or ERP.

No. The core guest journey works in a phone browser without an app download.

Guests enter through the business’s QR link and use the available menu in their browser. The service points and payment options depend on that business’s setup.

No. Persistent guest account creation is not required for browse, order or payment.

An order still needs its service context and transaction record. Avoiding a mandatory account does not mean that an order or payment has no associated data.

Restaurants, cafés, hotels, resorts and hospitality groups.

A café may use tables, while a hotel may organise room service and pool areas. The business configures its own menu, team and service locations rather than adopting every context.

Scan → Browse → Order → Pay.

The QR link identifies the service location; guests browse items and choose their order. Payment follows the options made available by the business, and an online result must be verified before the order is treated as paid.

Yes. Guests can browse the available menu before choosing whether to order.

Viewing a menu creates no purchase commitment. Guests decide what to add and whether to proceed, subject to the availability and prices shown by the business.

Yes. The core journey is designed for a phone browser.

The goal is a usable mobile flow from menu to order confirmation. This website’s concept images do not certify compatibility with every device or browser.

No. A persistent cross-business guest identity is not the baseline.

An order belongs to its business and service context. Scorpaq does not present a shared customer profile or cross-business advertising identity as a core feature.

Yes. The platform is designed for multilingual experiences.

This website offers eight languages with a manual language selector. Guest-product languages and country availability must be confirmed for the actual deployment; website translations alone do not guarantee them.

They can connect guest ordering and payment with menus, kitchen, service and operating visibility.

The intended flow links the table or other service point to the order, preparation and service status. Teams retain responsibility for fulfilment and handling exceptions.

Yes. The product is designed for independent businesses as well as larger operating structures.

Self-service setup is the goal: define the menu, service points and staff roles. Applying for Early Access does not automatically activate the service or a payment provider.

The architecture supports multi-location structures; commercial rollout depends on the operating context.

Locations belong to the relevant business structure, with permissions and operating context kept explicit. A chain rollout needs its configuration and commercial scope agreed before activation.

No. It is designed to reduce friction and support teams, not remove hospitality.

Guests can still ask staff for help or clarification. Digital ordering is intended to reduce repeated tasks while staff remain responsible for the hospitality experience.

The V1 core does not depend on native POS, PMS or ERP integration to function.

Scorpaq does not promise automatic synchronisation with an existing till, hotel system or accounting package. Any separate workflow and its limits should be assessed before a pilot.

Yes. Hotel contexts include restaurant, room service, bar, pool and lounge.

The hotel chooses which areas, menus and teams to configure. This does not make Scorpaq a reservation or accommodation-management system.

Restaurant, room service, bar, pool and lounge service contexts.

Each configured area needs a clear service point so the team knows where an order belongs. Mentioning a service area is not a promise that every property workflow is already available.

Yes. One core adapts to different service locations.

Areas share the underlying model but can have different menus and staff responsibilities. The preview illustrates this structure rather than proving a live property deployment.

Yes, as a hotel service context.

The room or service-location link provides operational context for the request. Automatic PMS lookup, room-charge posting and reservation synchronisation are not promised.

Yes, where the business configures those service contexts.

The business must identify the relevant service point and define what is available there. Scorpaq does not imply automatic guest tracking or location detection.

The architecture includes provider-neutral online payment, subject to provider, country and deployment readiness.

The business needs an eligible relationship with a supported provider. This marketing website does not take guest payments or activate online payment merely through an application.

Where business policy allows, the settlement model can support online-provider payment and pay-at-venue cash or physical POS.

Venue settlement remains subject to the business’s own collection and confirmation process. A payment made on a physical terminal is not automatically verified through a native POS integration.

No. Scorpaq does not custody or redistribute guest funds.

Guest payment processing remains within the provider and business relationship. This is separate from any subscription the business pays for Scorpaq.

Hosted payment is preferred so raw card data does not need to enter Scorpaq application logic, logs or analytics.

Guests should enter payment details on the supported provider’s payment page, not in Scorpaq’s contact forms. Hosted checkout does not itself establish a certification or a guarantee for every provider setup.

No. Payment truth must be verified by the server and provider.

The return page can arrive before a confirmed provider result or after an interrupted connection. An uncertain result must remain uncertain until server verification resolves it.

Through idempotency, replay protection, provider verification and safe handling of uncertain payment states.

Repeating a request must not create a second operation simply because a browser retries. This reduces technical duplication risk; it is not a promise that every payment incident is impossible.

The product is being built to manage categories, items, options, availability and menu controls.

A business controls what guests can see and order at its configured service points. Menu setup does not imply automatic stock, purchasing or accounting synchronisation.

Yes. Owner, Manager, Waiter and Kitchen responsibilities are separated.

Each role should receive the access needed for its task, within the authorised business. Knowing a link or seeing a button does not grant permission to change orders or sensitive settings.

It is being built to connect observed operational and business signals with useful intelligence.

Useful examples include service delays, unavailable products and missing cost context. Concept charts and sample values are not measured customer results or guaranteed financial gains.

Excel export is part of the product direction for reports.

The aim is to let businesses use their report data outside the dashboard. The fields, filters and available exports should be verified in the pilot rather than inferred from a concept image.

No. Missing or weak data must not be disguised as a measured zero.

An insight should show which inputs are available and where gaps remain. A revenue figure without sufficient cost information is not a complete profitability measure.

The workspace is the primary tenant and security boundary, reinforced by authorization and database controls.

Knowing another business’s identifier must not grant access to its records. This page describes the design boundary, not an independent security audit or certification.

No. Security is a server and architecture responsibility, not only a front-end concern.

Requests need checks on the server for the relevant identity, role and business scope. Hiding a control in a browser is only part of the interface, not enforcement of permission.

Yes. No mandatory guest account is required for the core journey.

Data needed to fulfil an order or verify payment is distinct from an optional account or marketing choice. The website’s Privacy Notice covers its forms, not a future production guest service.

No. Guest free text is not a default advertising or profiling input; marketing consent remains separate.

Messages should be used for their service purpose rather than silently becoming advertising profiles. On this website, the optional Early Access marketing choice is separate from the referral-source selection.

Use the existing Contact page.

Choose the privacy/data-request topic for a request about your information, or explain the security concern. Do not include passwords, raw card details or identity documents in an initial message.

Businesses can apply while the Early Access process is being prepared.

An application records your business context so suitability and next steps can be discussed. It does not guarantee acceptance, a launch date or immediate live access.

Scorpaq has a defined commercial model for different hospitality business types and operating structures. Pricing details are shared directly during qualified Early Access and commercial discussions.

Business type and operating structure help define the relevant commercial scope. An application is not a purchase; price and subscription conditions need to be agreed separately.

No free-forever live plan is presented.

Do not interpret the Early Access form or product preview as an unlimited free subscription. Access and commercial conditions are clarified before a business starts using the service.

No free live trial is promised.

Submitting an application does not begin a trial or create a billing commitment. Any pilot duration, scope and payment conditions need to be discussed separately.

Use the Early Access form and provide the requested business details.

Provide accurate contact and business details; location and business type help describe your needs. Referral sources and marketing emails are optional, and passwords, card details or identity documents are unnecessary.