Clear answers about the product, guest journey, privacy and implementation.

QR3X Hospitality is a Smart QR guest engagement and revenue platform for hospitality businesses. It connects app-free Guest Hubs, contextual WhatsApp actions, offers, feedback, analytics and optional AR experiences.

No. A menu can be one module, but QR3X is designed to organise multiple guest services and actions such as food, drinks, spa, tours, transfers, offers, rewards, feedback and support.

QR3X is designed for hotels, resorts, villas, restaurants, cafés, beach clubs, spas, wellness businesses and selected tourism or guest-experience operators.

Utility first, WhatsApp conversion, dashboard proof and optional AR wow. Practical guest actions should remain available before visual or camera-based features.

No. The core Guest Hub opens in a mobile web browser after the guest scans a QR code.

Not for the standard guest journey. Specific lead, reward or consent flows may request information only when it is relevant and clearly explained.

Core content should remain available without the camera. Optional AR features can use fallback or non-camera experiences where configured.

The platform is designed for configurable language support. Available languages and translated property content depend on the implementation and approval workflow.

Yes. Different controlled QR codes can open the same property while preserving source labels such as room, table, reception, poolside, spa or campaign.

Normally not when the controlled QR destination remains the same. Reprinting may still be required if the physical label, placement purpose or QR token itself changes.

It can record the configured QR source or placement label. This indicates where the journey started; it does not identify a guest unless the guest separately provides information with consent.

Common placements include rooms, tables, reception, poolside areas, spa desks, event spaces, welcome cards, printed collateral and campaign materials.

No. QR3X is designed to make WhatsApp guest actions easier to discover, more contextual and more measurable.

Yes, where configured. Food, drinks, spa, tours, offers, feedback and other modules can use department-specific routes with a property-level fallback.

Depending on the action, a message can include the property, QR source, table or room context, selected item or service, offer, date or time preference and guest-entered notes.

No. QR3X reports it as enquiry, order or booking intent. The standard platform does not automatically confirm whether the transaction was completed inside WhatsApp.

Yes. Active modules can include spa, wellness, tours, transfers, events, private dining, room services, rewards, feedback and other property-specific services.

Yes, when offers are managed through the active Guest Hub configuration and the QR destination remains unchanged.

Yes. Each property can have its own branding, modules, content, WhatsApp routes, offers, languages and QR-source structure.

The property is responsible for supplying and approving accurate operational content and notifying QR3X when information changes.

The dashboard can show QR scans, approximate sessions, QR sources, module views, offer interest, WhatsApp click intent, feedback, rewards and other configured events.

Not in the standard WhatsApp MVP. It tracks conversion intent unless a separate confirmed-transaction integration is explicitly implemented.

It is a modelled estimate based on configured assumptions and recorded intent signals. It is not guaranteed revenue and should be labelled accordingly.

Yes, where the source is configured and recorded. Typical filters include date, property, module and room, table, reception or campaign source.

No. Guests can normally access the core Guest Hub without providing a name or contact details.

Consent should be requested when personal information is collected for a defined purpose such as a lead, reward claim, contact request or other configured workflow.

The intended approach is privacy-aware and avoids invasive fingerprinting. Approximate session or return-visit measurement should use limited, purpose-led methods.

Yes. QR3X can offer private feedback and service recovery without blocking or hiding the public review option.

No. AR is an optional premium experience layer and should not block menus, offers, services, WhatsApp or feedback.

Depending on scope, examples include welcome objects, selected 3D dish or cocktail previews, rewards and property-specific visual moments.

Browser and device support varies. QR3X uses a hybrid approach with full, simulated or lite fallback modes rather than promising identical AR behavior on every device.

Modern browser camera access generally requires a secure HTTPS origin. QR3X guest experiences should be deployed over HTTPS.

Typical stages are discovery, QR planning, content and WhatsApp readiness, configuration, testing, QR production, controlled pilot and analytics review.

Timing depends on scope, content readiness, approvals, staff ownership, QR placements and optional visual assets. QR3X should not promise a universal fixed timeline.

Yes. A focused launch can start with the most useful modules and expand after the operational workflow is proven.

Yes. The operating process should define who requests, approves and publishes changes, while the property remains responsible for business accuracy.

No. QR3X is a guest engagement layer. It can operate alongside a PMS, POS, booking engine, hotel app or website.

No. Payment-gateway integration is outside the standard shared-hosting MVP unless separately approved and scoped.

Potentially, but each integration requires separate technical, security, data and commercial assessment.

No. The standard guest experience is app-free and browser-based.

The walkthrough can focus on the prospect’s property type, current QR journey, WhatsApp operations, guest services, commercial opportunities and relevant dashboard signals.

Yes. Pilot scope, placements, active modules, staff responsibilities and review criteria should be agreed before launch.

No. Demonstration properties illustrate product workflows. Customer case studies should be labelled separately and used only with approved evidence.

Support scope, response expectations, content changes and operational ownership should be defined in the agreed implementation or service arrangement.