Business Requirement Document (BRD)

This Business Requirement Document defines the commercial and product vision for Tours — a production-ready, white-label tours & experiences booking marketplace delivered as a self-hosted Next.js template. It is written for buyers, project sponsors, and business stakeholders who need to understand why the product exists, who it serves, and what it must deliver to succeed as a brandable platform for discovering and booking tours. It is the parent document for the Functional Requirement Document (FRD) and the Software Requirement Specification (SRS).

Field	Value
Product	Tours — tours & experiences booking marketplace
Vendor	CreativeCape Solutions
Document type	Business Requirement Document (BRD)
Audience	Buyers, sponsors, product stakeholders
Delivery model	Self-hosted Next.js template (buyer-owned)
Status	Baseline

Executive Summary

Tours lets a tour operator, travel agency, or destination-marketing business stand up a credible, full-featured online booking storefront in hours instead of months — without building one from scratch. The product ships as a single Next.js 16 application the buyer fully owns and controls, serving five distinct experiences from one codebase: a public storefront, a customer portal, an operator portal, an influencer/affiliate portal, and an admin panel / CMS. The core is free to sell tours and take bookings end to end; premium integration providers and feature modules unlock through CreativeCape license entitlements so a marketplace can grow exactly as far as its audience demands.

Because the product is white-label, branding, content, currency, and locale all come from settings — nothing is hardcoded. A buyer can therefore resell client-branded tour marketplaces without touching code.

Vision

Vision statement: Give anyone the power to run their own tour-booking business — owned, branded, and monetized on their terms.

Tours exists to remove the cost, time, and technical risk of launching an online tour marketplace. Rather than commissioning a bespoke build or renting a per-seat SaaS, a buyer purchases the template once, installs it through a guided wizard, brands it from the admin panel, and begins listing and selling tours. Operators onboard themselves, travelers self-serve their bookings, and influencers drive referral revenue — all from the same platform.

Business Goals & Objectives

#	Goal	Objective (measurable intent)	Priority
G1	Time-to-launch	A buyer installs via the wizard and goes live on standard serverless hosting without manual database setup.	Must
G2	Ownership	The buyer owns the code, data, and infrastructure — no per-seat SaaS fees, no vendor lock-in.	Must
G3	Sell tours end to end	Catalog, checkout, payment, and confirmed booking work out of the box.	Must
G4	Manage departures	Dated departures, seasonal pricing, capacity/availability, itineraries, inclusions, and extras.	Must
G5	Multi-sided marketplace	Operators list and fulfil; travelers book; influencers earn commission; admin governs.	Must
G6	White-label resale	Theme, logo, copy, currency, and locale are settings-driven so buyers deliver client-branded sites.	Must
G7	Extensibility	Premium add-ons unlock via purchase code / license entitlement without code surgery.	Should
G8	Quality & trust	Production-grade security (encrypted secrets, JWT sessions, RBAC) and a clean, conventional codebase.	Must
G9	Low support load	Self-service install wizard, in-product documentation, and consistent conventions reduce buyer questions.	Should

Commercial objectives

Sell a complete product, not a starter kit. A working storefront, four role portals, and an admin CMS ship ready to use.
Tiered revenue model. A free core (listing tours, taking bookings) drives adoption; a large catalog of built-in add-ons (integration providers plus premium feature modules) drives upsell.
Protect intellectual property. Premium add-ons are gated by CreativeCape licensing — entered as a purchase code in admin and verified offline by RS256 signature.
Enable resale & white-label. Full brandability (theme, logo, copy, currency, locale) lets buyers deliver client-branded tour marketplaces.

Business Context & Opportunity

Small and mid-size tour operators are underserved: bespoke booking builds are expensive and slow, while horizontal SaaS booking tools charge recurring per-seat fees and rarely allow true white-labeling. Tours targets the gap with a buy-once, self-host, own-forever model that combines a consumer-grade storefront with the multi-party operational tooling (operator onboarding, payouts, commissions, moderation) that a real marketplace needs.

Stakeholders & Personas

Persona	Description	Primary needs
Admin / Store Owner	Operates the marketplace day to day from `/admin`.	Catalog control, booking fulfilment, revenue reporting, settings, licensing, integrations, moderation.
Operator (host/seller)	Lists and sells tours; a `hosts` record.	Tour authoring, departures & pricing, reservations, earnings & payouts, traveler messaging, analytics.
Traveler / Customer (buyer)	Discovers and books tours.	Easy booking, an organized portal, clear itineraries, simple payments, reviews and wishlist.
Influencer / Affiliate	Promotes tours for commission.	Referral links, commission tracking, payouts, and shareable marketing materials.
Guest	Unauthenticated visitor.	Browse the catalog and begin checkout before creating an account.
Buyer / Developer	Purchases and deploys Tours.	Easy install, clean code, license control, extensibility, brandability.

Persona routing notes

The Admin works in /admin, behind an admin JWT session with a fine-grained resource:action permission matrix.
Operators and Travelers share one member JWT session; an accountType field routes them to /operator or /customer.
Influencers sign in through their own portal at /influencer.
The Buyer/Developer is served by the /install wizard, the deployment guides, and a conventional Next.js App Router architecture.

Scope

In scope

Public storefront: tour catalog, tour detail (itinerary, inclusions, departures, reviews), destinations, operator profiles, marketing/CMS pages, blog, and booking checkout.
Booking & checkout: departure selection, extras (add-ons), coupons, tax, and pluggable payment gateways.
Bookings & fulfilment: automatic confirmation on paid, departure availability and capacity limits, cancellation/refund policy, vouchers/invoices, and traveler↔operator messaging.
Customer portal (/customer): bookings, payments, reviews, wishlist, messages, notifications, support, and account settings.
Operator portal (/operator): tour authoring, reservations, calendar, earnings, payouts, billing/statements, reviews, inbox, and insights.
Influencer portal (/influencer): referral links, referred bookings, commission ledger, payouts, marketing materials, and analytics.
Admin panel / CMS (/admin): catalog, operators, customers, bookings, payments, payouts, marketing (coupons, influencers), CMS content, settings, integrations, and license/add-on activation.
Install wizard (/install), Cloudflare R2 / S3-compatible media storage, and admin-managed integration configuration.

Out of scope (buyer-supplied or add-on)

Hosting, domain registration, and SSL provisioning — buyer responsibility.
Third-party service accounts (SMTP/email, SMS, WhatsApp, payment-gateway credentials) — supplied by the buyer.
Premium capabilities delivered only as licensed add-ons (e.g. maps, two-factor auth, audit logs, AI chatbot).
Premium channel providers beyond the free defaults (e.g. additional payment, email, storage, analytics, or chat providers).

Business Requirements (MoSCoW)

ID	Requirement	Priority
BRQ-1	The platform must let an admin publish tours with itineraries, inclusions, extras, and dated departures.	Must
BRQ-2	A traveler must be able to browse, select a departure, check out, pay, and receive a confirmed booking.	Must
BRQ-3	Booking totals must be recomputed server-side; client-supplied prices are never trusted.	Must
BRQ-4	Operators must be able to self-onboard and author their own tours, manage reservations, and request payouts.	Must
BRQ-5	The platform must support online and offline payment methods via a configurable gateway registry.	Must
BRQ-6	Influencers must be able to generate referral links and earn tracked commission on attributed bookings.	Must
BRQ-7	Branding, content, currency, and locale must be settings-driven (white-label) — no hardcoded brand or currency.	Must
BRQ-8	Integration secrets must be encrypted at rest and never returned to clients in plaintext.	Must
BRQ-9	Admin operations must be permission-gated per role.	Must
BRQ-10	The platform should support coupons (percent/amount) with limits, validity windows, and scoping.	Should
BRQ-11	The platform should gate premium add-ons behind valid license entitlements or purchase codes.	Should
BRQ-12	Travelers should receive downloadable booking vouchers/invoices and calendar (iCal) feeds.	Should
BRQ-13	The platform could offer AI-assisted tooling for influencers and content workflows.	Could
BRQ-14	The platform will not provide native mobile apps in the core (REST API is provided for mobile clients).	Won't (this release)

User Stories (business level)

ID	As a…	I want to…	So that…	Priority
US-B1	Buyer	install and brand the platform without developer help	I can launch a marketplace quickly and cheaply	Must
US-B2	Traveler	book a tour departure and pay online	I secure my spot and get instant confirmation	Must
US-B3	Operator	list my tours and manage bookings	I sell experiences and get paid out	Must
US-B4	Admin	oversee catalog, bookings, and revenue	I run the marketplace and fulfil offline payments	Must
US-B5	Influencer	share referral links and track commission	I earn from the bookings I drive	Should
US-B6	Buyer	resell client-branded copies	I can serve multiple clients from one codebase	Should

Business Rules

ID	Rule
BR-1	Booking confirmed on paid. A booking is confirmed only when its payment reaches paid; for online payments this happens automatically at that moment.
BR-2	Offline bookings need admin "Mark as Paid". Bookings placed with an offline method (Cash / Bank Transfer) are created as pending and confirmed when the admin marks them paid.
BR-3	Booking is against a departure. A tour is booked against a specific dated departure; a confirmed booking consumes seats against that departure's capacity; sold-out or past departures cannot be booked.
BR-4	Totals are recomputed server-side. Price derives from the departure and season; extras, coupons, and tax adjust the total — all recomputed on the server, never trusted from the client.
BR-5	Premium add-ons require a license. A premium provider or feature serves only when unlocked by a valid CreativeCape entitlement or per-add-on purchase code; localhost/dev hosts are unlocked for development.
BR-6	Secrets are encrypted at rest. Integration credentials (gateway keys, SMTP passwords) are stored AES-256-GCM encrypted and never returned in plaintext to clients.
BR-7	Admin actions are permission-gated. Admin operations are checked per route against the role's resource:action permissions; system/super roles bypass the matrix.
BR-8	Earnings & commissions on paid bookings. When a booking is paid, an operator-earnings record is created for later payout; if the booking came through a referral link, an influencer commission is recorded too.

Assumptions, Dependencies & Constraints

Assumptions: the buyer provides hosting, a PostgreSQL database (serverless-compatible URL), and third-party service credentials; travelers pay in the marketplace's configured currency.
Dependencies: a payment gateway, an SMTP/email service, and S3-compatible storage (Cloudflare R2 by default) must be configured for full operation.
Constraints: the application targets serverless hosting with an effectively read-only filesystem, so all media goes to object storage; premium features require a valid license.

Success Metrics

Metric	Target outcome
Install-to-live	A buyer reaches a working storefront and admin through the wizard without manual database setup.
Booking completion	A traveler can browse, pick a departure, check out, and immediately receive a confirmed booking (or after admin "Mark as Paid" for offline).
Pricing integrity	Coupons, extras, and tax apply correctly, and departure availability decrements as bookings are confirmed.
Policy correctness	Cancellation and refund rules behave as documented; sold-out and past departures are not bookable.
Add-on activation	Premium add-ons activate cleanly via purchase code and remain valid offline through the license grace window.
Marketplace satisfaction	The product sustains a strong marketplace rating, with support handled through creative-cape.com.

Risks & Mitigations

Risk	Mitigation
Misconfigured payment or storage credentials block go-live	Guided install wizard, admin Settings → Channels, and diagnostic error surfacing.
Client-side price tampering	Server-side re-pricing of every departure, extra, coupon, and tax at booking time.
License-server outage disrupts a live site	Offline RS256 verification plus a grace window keep the site live during brief outages.
Buyer expects features that are premium-gated	Clear in-scope/out-of-scope and add-on licensing disclosure in this BRD and the product overview.