Functional Requirement Document (FRD)
This Functional Requirement Document specifies what Tours does from a behavioral perspective: its modules, pages, features, flows for each actor (traveler, operator, influencer, admin, guest), validation, and the business rules that govern them. It translates the goals in the Business Requirement Document into concrete, testable functionality across the storefront, the four portals, and the admin CMS — all served from one Next.js 16 application. Where behavior is governed by data, this document uses tour vocabulary (tour, operator, departure); underlying database table names appear only where a technical reference is useful.
| Field |
Value |
| Product |
Tours — tours & experiences booking marketplace |
| Vendor |
CreativeCape Solutions |
| Document type |
Functional Requirement Document (FRD) |
| Audience |
Product owners, QA, implementers |
| Parent / child |
Parent: BRD · Child: SRS |
Actors & Roles
| Actor |
Portal |
Session |
Notes |
| Guest |
Storefront / |
none |
Browses catalog; may start checkout before registering. |
| Traveler / Customer |
/customer |
member JWT (accountType: customer) |
Books tours, manages bookings, reviews, wishlist. |
| Operator |
/operator |
member JWT (accountType: operator) |
Authors tours, fulfils reservations, requests payouts. |
| Influencer / Affiliate |
/influencer |
dedicated portal auth |
Promotes tours, earns commission. |
| Admin |
/admin |
admin JWT + RBAC |
Governs catalog, bookings, content, settings. |
Module Overview
Tours groups functionality into ten functional areas. Listing tours and taking bookings are part of the free core; premium features and additional integration providers unlock via CreativeCape add-on licensing.
| # |
Module |
Purpose |
Priority |
| 1 |
Catalog |
Public tour / destination / operator browsing with search, filters, and reviews |
Must |
| 2 |
Booking & Checkout |
Departure selection, extras, coupons, tax, and booking creation |
Must |
| 3 |
Payments |
Online gateway + offline methods (Cash / Bank Transfer); pluggable driver registry |
Must |
| 4 |
Bookings & Fulfilment |
Confirmation on paid, departure availability, cancellation/refunds, vouchers and invoices |
Must |
| 5 |
Customer Portal |
/customer — bookings, payments, reviews, wishlist, messaging |
Must |
| 6 |
Operator Portal |
/operator — tour authoring, reservations, earnings, payouts, analytics |
Must |
| 7 |
Influencer Portal |
/influencer — referral links, commissions, payouts, marketing materials |
Should |
| 8 |
Admin / CMS |
/admin — catalog ops, customers, bookings, marketing, content, settings |
Must |
| 9 |
Add-ons & Licensing |
Built-in add-ons (integration providers + premium features), license/purchase-code activation |
Should |
| 10 |
Auth & Permissions |
Member and admin sessions, OTP/email verification, social sign-in, RBAC |
Must |
1. Catalog
Public storefront under / (the (site) route group).
| Route |
Page |
/ |
Homepage (hero, sections, featured content) |
/tours |
Tour catalog with search, destination, price, and sort filters |
/tours/[slug] |
Tour detail — itinerary accordion, inclusions, departures, reviews |
/[slug] |
Public operator profile / CMS pages |
/blogs, /blogs/[slug] |
Marketing blog list and post |
/about, /contact, /faq, /enquiry, /how-it-works, /gallery, /careers |
CMS / marketing pages |
/booking/checkout, /booking/confirmed |
Booking checkout and confirmation |
Functional requirements
| ID |
Requirement |
Priority |
| F-CAT-1 |
The catalog shall list published tours with faceted filtering (destination, price, duration) and sorting. |
Must |
| F-CAT-2 |
Tour detail shall render a day-by-day itinerary accordion, inclusions, available departures (dates, prices, remaining capacity), aggregate ratings (rating_avg/rating_count), and approved reviews. |
Must |
| F-CAT-3 |
Destinations shall organise tours geographically, each with its own landing page and published counts. |
Must |
| F-CAT-4 |
Operator profiles shall aggregate tour count, rating, and reviews. |
Should |
| F-CAT-5 |
Hot public reads (catalog, tour detail, destinations, facets) shall be cached server-side with short TTLs. |
Should |
2. Booking & Checkout
APIs under /api/v1/bookings.
| ID |
Requirement |
Priority |
| F-BK-1 |
The checkout shall accept a chosen departure, optional extras, and an optional coupon. |
Must |
| F-BK-2 |
A coupon shall be re-priced server-side to preview its discount before the booking is created. Coupons support PERCENT or AMOUNT discounts, a minimum total, a max-discount cap, redemption limits, a validity window, and scoping (ALL / TOURS / DESTINATIONS). |
Must |
| F-BK-3 |
Extras (optional priced add-ons) selected by the traveler shall be included in the total. |
Must |
| F-BK-4 |
GET /api/v1/bookings/payment-methods shall list the active gateways for the method picker. |
Must |
| F-BK-5 |
POST /api/v1/bookings/checkout shall re-price the departure server-side, re-validate the coupon, apply tax, and create a booking. Online gateways return a redirect/approval; offline methods return a pending booking. |
Must |
| F-BK-6 |
POST /api/v1/bookings/verify (and the gateway return flow) shall confirm payment with the driver and finalize the booking. |
Must |
3. Payments
| ID |
Requirement |
Priority |
| F-PAY-1 |
The platform shall support a configurable online payment gateway using a redirect/approval flow with test/live/sandbox modes. |
Must |
| F-PAY-2 |
The platform shall support offline methods (Cash / Bank Transfer) that create a pending booking fulfilled by admin "Mark as Paid". |
Must |
| F-PAY-3 |
Premium gateways shall ship as self-contained add-on drivers in a pluggable registry, configured in admin settings. |
Should |
| F-PAY-4 |
Active gateway configuration shall be read from the integration_connections table (channel PAYMENTS), with secrets decrypted server-side only. |
Must |
4. Bookings & Fulfilment
Booking statuses: pending, paid, failed, refunded, cancelled.
| ID |
Requirement |
Priority |
| F-FUL-1 |
When a booking becomes paid, it shall be confirmed automatically, linked to its departure and the originating payment; the departure's remaining capacity shall be decremented; operator earnings (and any influencer commission) shall be recorded. |
Must |
| F-FUL-2 |
pending offline bookings shall be fulfilled via the admin booking action (mark_paid), which re-resolves stored line items, confirms the booking, sets paid_at, and redeems any coupon. |
Must |
| F-FUL-3 |
Each departure shall carry a date, a price (adjusted by season/rates), and a seat capacity; sold-out or past departures shall not be bookable. |
Must |
| F-FUL-4 |
Bookings shall honour the operator's cancellation policy; refunds shall be computed against the policy and processed through the original gateway. |
Should |
| F-FUL-5 |
Travelers shall receive a booking voucher/invoice (PDF), and departures shall expose an iCal feed for calendars. |
Should |
| F-FUL-6 |
Travelers and operators shall exchange messages tied to a booking. |
Should |
5. Customer Portal
Portal under /customer (member session; rendered dynamically to reflect live theming).
| Route |
Purpose |
/customer/dashboard |
Overview: upcoming trips, recent bookings, activity |
/customer/bookings |
Bookings with status, departure, and details |
/customer/payments |
Payment history and invoices |
/customer/reviews |
Reviews written by the traveler |
/customer/wishlist |
Saved tours |
/customer/messages, /customer/notifications |
Operator messaging and in-app notifications |
/customer/support |
Support requests |
/customer/settings |
Account, profile, and preferences |
6. Operator Portal
Portal under /operator (same member session, accountType: operator).
| Route |
Purpose |
/operator/dashboard |
Business overview |
/operator/tours |
Author tours — departures, pricing, availability, inclusions, itinerary, languages, location |
/operator/reservations |
Bookings against the operator's tours |
/operator/calendar |
Departure schedule and availability blocks |
/operator/payouts, /operator/billing |
Payout requests and statements |
/operator/insights |
Earnings and performance analytics |
/operator/reviews |
Traveler reviews with operator replies |
/operator/inbox |
Messaging with travelers |
/operator/settings |
Operator profile and settings |
Operator onboarding is available from the storefront (a "become an operator" flow) so a member can convert to an operator account.
7. Influencer Portal
Portal under /influencer (dedicated portal auth).
| Route |
Purpose |
/influencer/dashboard |
Overview of clicks, bookings, and earnings |
/influencer/tours |
Browse tours to promote |
/influencer/referral-links |
Generate and manage referral links |
/influencer/bookings |
Bookings attributed to the influencer |
/influencer/commission |
Commission ledger |
/influencer/payouts |
Payout requests |
/influencer/marketing-materials |
Shareable banners and assets |
/influencer/analytics, /influencer/ai-chat |
Performance analytics and AI assistant |
/influencer/profile, /influencer/notifications, /influencer/settings |
Profile, notifications, and settings |
8. Admin / CMS
Panel under /admin/(panel) (admin session, permission-gated).
- Catalog — tours, operators, customers, destinations, inclusions, extras, calendars.
- Bookings (with per-booking detail and Mark as Paid), payments, payouts, dashboard (revenue/analytics).
- Marketing — coupons and the influencers (affiliate) program.
- Content / CMS — pages, blogs, hero-slider, testimonials, why-choose-us, gallery, partners, faqs, about, media, menus, builder, theme-builder.
- Leads — contacts, newsletter, enquiries. Reviews moderation.
- Settings — payments, booking, tax, currencies, countries, locations, integrations, notifications (email/sms/whatsapp/in-app/push/webhook) + notification log, languages, monetization, plans, theme, roles, permissions, users, api-tokens, webhooks, backup, and activity.
9. Add-ons & Licensing
| ID |
Requirement |
Priority |
| F-ADD-1 |
Tours shall ship a library of built-in add-ons: integration providers across Payments, Email, Storage, Analytics, Video, CAPTCHA, Live Chat, AI Chatbot, SMS, WhatsApp, and Social Auth — plus premium feature plugins (e.g. maps, two-factor auth, audit logs, privacy/consent). |
Should |
| F-ADD-2 |
Free defaults shall include SMTP (email), an online gateway plus Cash and Bank (payments), Cloudflare R2 (storage), GA4 (analytics), and YouTube/Vimeo (video); other providers are premium. |
Should |
| F-ADD-3 |
A premium provider or feature shall serve only when unlocked. Activation is per-add-on via a purchase code entered in admin → Add-ons, exchanged once for an RS256 JWT bound to { addon, domain } and then verified offline on every check; the domain license may also grant entitlements ("*", a channel id, or "channel:provider"). Localhost/dev hosts are unlocked. |
Should |
| F-ADD-4 |
Server-side gates (premiumBlock / featureBlock) and the client useFeatureActive() hook shall check installation and entitlement before exposing a feature. |
Should |
10. Auth & Permissions
| Aspect |
Traveler / Operator |
Admin |
| Session cookie |
member_session (HS256 JWT, 30 days) |
admin_token (HS256 JWT, 7 days default) |
| Routing |
accountType (customer / operator) |
Direct admin login |
| Verification |
Email/OTP via email, SMS, or WhatsApp |
— |
| Social sign-in |
OAuth providers (e.g. Google, Facebook) when configured |
— |
| Authorization |
Role-based portal access |
Fine-grained resource:action matrix |
- Auth routes (
/(auth)): login, register, forgot-password, reset-password, verify-email. Influencers authenticate through their own portal routes.
- OTP/verification delivery channel is admin-configurable; a QA test-contact/test-code bypass exists for staging.
- Admin RBAC —
permissions-catalog.ts defines resources × CRUD actions; requirePermission(action, resource) enforces per route and returns 403 when denied, emitting an audit event on mutations. System/super roles bypass the matrix.
Key User Stories & Acceptance Criteria
| ID |
As a… |
I want to… |
Acceptance criteria |
| U-1 |
Guest |
filter tours and open a tour detail |
Filters by destination/price/duration return matching published tours; detail shows itinerary, inclusions, departures, and reviews. |
| U-2 |
Traveler |
book a departure with an extra and a coupon |
Total is recomputed server-side including extra, coupon, and tax; an online payment yields a confirmed booking, an offline method yields a pending booking. |
| U-3 |
Traveler |
see my booking and download its voucher |
The booking appears in /customer/bookings with correct status; a PDF voucher/invoice is downloadable. |
| U-4 |
Operator |
publish a tour with dated departures |
The tour appears in the catalog once published; each departure enforces its capacity and blocks sold-out/past dates. |
| U-5 |
Operator |
request a payout on my earnings |
Earnings recorded on paid bookings are payable; a payout request is created and tracked. |
| U-6 |
Influencer |
share a referral link and see commission |
A booking through the link is attributed; a commission is recorded when the booking is paid. |
| U-7 |
Admin |
mark an offline booking paid |
"Mark as Paid" confirms the booking, sets paid_at, decrements capacity, redeems any coupon, and records earnings/commission. |
| U-8 |
Admin |
moderate a submitted review |
Only approved reviews appear publicly and affect rating_avg/rating_count. |
Validation & Business Rules
- Server-side re-pricing: departure prices, extras, coupons, and tax are recomputed on the server at booking time — never trusted from the client.
- Uploads: file uploads pass through the server to R2/S3; images are processed (resize/convert) with sharp before storage.
- BR-A A booking is confirmed only when it is
paid; offline bookings require admin Mark as Paid.
- BR-B A booking consumes seats against its departure's capacity; sold-out and past departures are not bookable.
- BR-C Premium add-ons require a valid entitlement or purchase code (dev/localhost unlocked).
- BR-D Integration secrets are stored AES-256-GCM encrypted and never returned to clients.
- BR-E Admin mutations are permission-checked and audited.
Error & Edge-Case Handling
| Scenario |
Expected behavior |
| Coupon expired or below minimum total |
Checkout rejects the coupon with a helpful message; total falls back to undiscounted. |
| Departure sold out between preview and submit |
Checkout re-checks capacity server-side and blocks the booking. |
| Online payment fails or is abandoned |
Booking is left failed/pending; capacity is not consumed until paid. |
| Premium provider not licensed |
The feature is hidden/blocked with an activation prompt; no server action runs. |
| Unauthorized portal access |
Route guards return 401/redirect to login; object-level queries are owner-scoped to prevent IDOR. |
For functional questions or feature requests, contact support at creative-cape.com.
© CreativeCape Solutions · creative-cape.com · support@creative-cape.com