How Qualimundi works
Qualimundi turns complex trip planning into a clear sequence: discover a curated journey, inspect the day-by-day plan, start a non-binding inquiry, continue the conversation in your traveller account, and receive a structured offer when the trip is ready to move.
Live example
Train, recover, and excel
A regimented retreat balancing high-performance training with targeted recovery by the sea.
Live sample journeys
These cards come from the same live package payload QM1 already uses elsewhere on the site.
Traveller POV
The public side stays persuasive and premium, but the flow is real. Every step below already exists in the current QM1 product.
Step 01
Visitors land on package listings, destination pages, experience pages, or campaign-style content and browse live journeys built for discovery, clarity, and trust.
Current touchpoints: package list, destinations, experiences, home, blog, and about pages.
Open the journeys listStep 02
A visitor opens a journey like Elite Sports Performance Retreat and sees mapped days, stay data, inclusions, FAQs, and the public-facing local lead story when owner data is available.
When an owner profile is available, QM1 also exposes the public-facing local lead profile.
View journey detailsStep 03
The inquiry wizard captures dates, group size, travel intent, and account details. If needed, QM1 creates the traveller account during the same flow.
Current flow: inquiry wizard, confirmation email, success page, and reference id.
Start a non-binding inquiryStep 04
After the first inquiry, the visitor can continue in the traveller area to review inquiry details, chat with the owner side, check files, and use the separate support channel.
Current flow: login, inquiry list, inquiry detail tabs, support chat, and profile management.
Sign in to continue in your traveller accountStep 05
When the owner side publishes an offer, the traveller sees it in QM1, can accept or decline it, and completes staged Stripe payments from the same inquiry lifecycle.
Current flow: offer accept or decline, checkout redirect, webhook confirmation, and instalment status tracking.
Sign in to continue in your traveller accountOwner POV
Public-facing copy should say local lead. Operationally, the workflow lives in Portal, where the owner side manages content, inquiries, chat, and offers.
Public terminology: local lead. Operational surface: Portal owner workflow.
Step 01
The owner side builds the package deal, adds day content, imagery, and supporting details, and prepares the public product that QM1 will display.
Step 02
Once the deal is ready and active, QM1 surfaces it through the public browsing pages, detail pages, and related destination or experience entry points.
Step 03
The inquiry originates in QM1 but becomes part of the shared inquiry lifecycle, where the owner side can review the request and pick up the conversation.
Step 04
Portal handles the operational side: review inquiry details, continue the chat, prepare the commercial offer, and publish it back into the shared traveller flow.
Step 05
The final commercial handoff stays connected. The owner side manages the operational lifecycle, while the traveller completes acceptance and staged payment actions in QM1.
Overall flow
Instead of a generic ecosystem strip, this chart shows the actual handoffs: who acts, where the action happens, and how the traveller experience stays continuous across QM1, Portal, and Buzzard.
From the outside, Qualimundi should feel like one coherent journey. Underneath it, the experience moves through clear chapters: content creation, public discovery, inquiry capture, owner response, commercial negotiation, payment confirmation, and the future handoff into the booked trip.
Traveller
What the visitor or logged-in traveller experiences directly.
QM1
Public discovery, inquiry capture, traveller account, support, and payment entry points.
Local Lead
The public human trust layer that gives the trip a real guide and local face.
Portal
Owner-side operations: content management, inquiries, chat, offers, and follow-through.
Buzzard / Shared Systems
Source of truth, shared records, and the content or data handoff layer.
QM1
Listings, detail pages, and local lead storytelling can only exist once the underlying deal data is ready to be consumed.
Local Lead
Owner profile data becomes the visible local lead layer that travellers later use as a trust signal.
Portal
Package details, day content, commercial structure, and owner-facing setup are managed operationally before anything goes public.
Buzzard / Shared Systems
Shared schema, package content, owner profile data, and downstream records all depend on Buzzard as the master source.
Traveller
They browse live journeys, compare destinations and experiences, and decide whether the trip feels credible enough to ask about.
QM1
Listings, journey detail pages, destination discovery, FAQs, inclusions, and itinerary framing create the public-facing value proposition.
Local Lead
Country context, specialties, languages, and response expectations turn a static itinerary into something guided and trustworthy.
Buzzard / Shared Systems
QM1 continues to rely on approved package and owner data instead of a disconnected marketing-only story.
Traveller
Dates, group shape, travel intent, and extra context are entered inside a non-binding inquiry flow.
QM1
The 5-step wizard, confirmation email, success state, and first account handoff all happen on the traveller-facing site.
Portal
The owner side can immediately see the inquiry in the shared lifecycle and prepare to respond.
Buzzard / Shared Systems
The account, inquiry metadata, and reference id land in the same shared model the wider product already uses.
Traveller
Inquiry details, files, and the ongoing conversation stay visible so the trip keeps moving forward after the first inquiry.
QM1
Inquiry tabs, AJAX chat, files visibility, and the separate support entry point keep the traveller inside one coherent product experience.
Local Lead
The traveller still understands there is a real local expert behind the trip, even though the operational tooling lives elsewhere.
Portal
Owners review inquiry details, continue the chat, inspect files, and manage the live conversation from their operational workspace.
Buzzard / Shared Systems
Inquiry messages, file metadata, and state updates stay synchronized because the lifecycle runs against shared data.
Traveller
Pricing, participants, payment schedule, and cancellation logic are visible before the traveller accepts or declines with feedback.
QM1
Drafts stay hidden, published offers become visible, and traveller remarks are captured back into the shared lifecycle.
Local Lead
The traveller still connects the offer to a trusted guide, even though the offer itself is managed operationally in Portal.
Portal
Owners can create offers, publish them into the traveller flow, read rejection feedback, revise, and republish when needed.
Buzzard / Shared Systems
Offer states, traveller remarks, and status changes persist in the shared data model rather than in isolated frontend copy.
Traveller
Accepting the offer triggers checkout, returns the traveller to a pending confirmation state, and keeps support available while the payment completes.
QM1
Stripe checkout, pending confirmation, polling, success or cancel flows, and continued support all happen on the traveller-facing side.
Local Lead
Once the booking starts to harden, the local lead becomes less of a trust layer and more of an implied delivery partner for the trip.
Portal
Owners can track commercial progress and the downstream operational state without moving the traveller out of QM1.
Buzzard / Shared Systems
Offer and inquiry status move into payment-related states only once the webhook-backed confirmation lands in the shared system.
Coming next
Everything above this marker reflects current product behaviour. The chapter below is shown as a clearly marked future extension after payment confirmation and active support.
Traveller
The future state includes confirmation clarity, pre-departure guidance, and a smoother sense of what happens between payment and departure.
QM1
Confirmation states, pre-departure documents, and logistics visibility are natural next chapters for the traveller-facing product.
Local Lead
Future product work could make the active handoff to the local lead more explicit once the trip is operationally locked in.
Portal
Owner-side preparation, logistics follow-through, and post-booking readiness belong in the operational layer behind the scenes.
Buzzard / Shared Systems
Future modules would likely extend the shared lifecycle beyond offer and payment into confirmation, trip-ready states, and follow-up.
How the apps work together
Status logic
Agency audit layer
This lower section exists to support audits, copywriting, messaging reviews, and UX critique without turning the whole page into internal documentation.
Current touchpoints
Terminology
Responsibilities
Audit focus
Next step
Travellers should leave this page ready to browse. Agencies should leave it understanding where the public experience stops and the operational lifecycle begins.