System Requirements Document for untitled-project

1. Introduction

untitled-project is a multi-tenant CRM for gyms. It enables each gym tenant to manage bookings, payments, coupons, vouchers, and equipment-image highlights within its own isolated operational workspace.

The system serves gym owners, front-desk staff, and platform operators. Gym owners and staff use the CRM to run tenant-specific day-to-day operations, while platform operators provision and manage the gym tenants that use the platform.

The product is delivered as a Blazor Server web application that uses SignalR for real-time updates and notifications, and as a MAUI Blazor Hybrid mobile application that shares the same component library as the web app. Both applications connect to backend services through a secured API Gateway using EF Core backed by MS SQL Server. Payments are collected through native UPI payment by opening a phone payment app such as GPay or BHIM, similar to most Indian apps. The interface is modern and unique, and AI-generated equipment imagery drives the gym highlight sections.

2. System Overview

The current product is an application-owned, custom-UI gym CRM with authenticated access and role-restricted operational areas.

Current delivery includes:

• A public Landing page explaining the multi-tenant gym CRM.
• Self-service enrollment for gym owners creating a new gym tenant.
• Returning identity verification for gym owners, gym staff, and platform operators.
• Tenant-scoped access for gym operational work.
• Booking creation, viewing, updating, and cancellation.
• Payment recording and viewing in association with bookings.
• Coupon creation, viewing, updating, and redemption.
• Voucher creation, viewing, updating, and redemption.
• Uploading and managing equipment images used as highlights about a gym.
• Platform-operator provisioning and management of gym tenants.
• A Blazor Server web application with SignalR-driven real-time updates and notifications.
• A MAUI Blazor Hybrid mobile application sharing the same component library as the web app.
• MS SQL Server as the backend data store.
• A secured API Gateway using EF Core, through which the web and mobile applications connect to backend services.
• Native UPI payment checkout by opening a phone payment app such as GPay or BHIM.
• A modern, unique interface in which AI-generated equipment imagery drives the gym highlight sections.

The system must organize data per gym tenant. A gym's operational records and gym-specific equipment-image highlights must remain associated with the correct tenant.

2a. Product Interpretation and Delivery Boundary

The product is a first-party CRM application for gyms rather than a public member booking marketplace.

Anonymous visitors can learn about the CRM on Landing. Gym owners can establish first access through Sign Up, creating a gym tenant. Returning gym owners, staff, and platform operators use Login to verify their identity before accessing durable operational records.

Tenant operational work occurs only in the authenticated, tenant-scoped areas of the application. Gym owners and staff access the operational pages assigned to their role. Platform operators use Tenants to provision and manage gyms across the multi-tenant system.

Current scope is limited to CRM operations for gyms, bookings, payments, coupons, vouchers, tenant management, and per-gym equipment-image highlights. The source does not establish member self-service accounts, public member booking, membership management, staffing schedules, inventory management, accounting, messaging, or external payment-provider processing; these are outside the current scope.

2c. Platform and Payment Delivery Model

• Web application: The product web app must be built in Blazor Server. Real-time updates and notifications must use SignalR, so live booking slots, payment status changes, and notification markers update in place without a page reload.
• Mobile application: The mobile app must be built in MAUI Blazor Hybrid, sharing the same component library as the web app rather than being built twice.
• Backend data store: The backend data store must be MS SQL Server.
• Secured API Gateway: A secured API Gateway must be built using EF Core to access MS SQL Server. The Blazor Server web application and MAUI Blazor Hybrid mobile application must connect to backend services through this gateway.
• Payment gateway: The payment gateway must use native UPI payment by opening a phone payment app such as GPay or BHIM, similar to most of the Indian apps.
• UPI checkout on mobile: On mobile, checkout uses a UPI deep-link intent that opens the user's installed payment app (GPay, BHIM, PhonePe, or another UPI app) to complete the payment.
• UPI checkout on web: Because UPI intent links cannot fire from a desktop browser, web checkout presents a QR / collect fallback: a scannable UPI QR field and a collect request that the user confirms in their phone payment app.
• Payment status sequence: Both surfaces present a clearly ruled status sequence from Initiated to Awaiting confirmation to Paid, updated in real time through SignalR.
• UI direction: The UI must be modern and unique, and all equipment AI images must be brought into the product as equipment-image highlights driving the gym highlight sections.

2b. Page Content and Component Coverage

• Cross-page integration responsibility: The Blazor Server web application and MAUI Blazor Hybrid mobile application must connect to backend services through the secured API Gateway, which uses EF Core backed by MS SQL Server.

Landing

• Information and state
  • Explains that untitled-project is a CRM for gyms.
  • Presents the product’s multi-tenant organization.
  • Introduces supported booking, payment, coupon, voucher, and equipment-highlight capabilities.
  • Explains that the system serves gym owners, gym staff, and platform operators.
  • Presents the product as a Blazor Server web app with SignalR real-time updates and a MAUI Blazor Hybrid mobile app.
  • Explains native UPI payment checkout by opening a phone payment app such as GPay or BHIM.
  • Showcases AI-generated equipment imagery as the gym highlight sections.
• Primary actions
  • Navigate to Sign Up for gym-owner enrollment.
  • Navigate to Login for returning access.
• Supporting actions
  • Review the CRM capability summary before establishing identity.
• Domain entities
  • Gym tenant.
  • Booking.
  • Payment.
  • Coupon.
  • Voucher.
  • Equipment highlight.
• Component responsibilities
  • Public product introduction.
  • Capability overview.
  • Entry-point navigation for enrollment and returning access.
  • Equipment-highlight showcase driven by AI-generated equipment imagery.
• States and recovery
  • Landing remains available without authentication.
  • If navigation to Sign Up or Login cannot be completed, the user remains on Landing and can retry the selected action.

Login

• Information and state
  • Provides returning identity verification for Gym Owner / Tenant Administrator, Gym Staff / Front Desk Operator, and Platform Operator (Multi-Tenant).
  • Does not expose tenant operational data before successful verification.
• Primary actions
  • Submit identity-verification information.
• Supporting actions
  • Navigate to Sign Up when a gym owner needs first-time enrollment.
• Domain entities
  • Application identity.
  • Authenticated session.
  • Gym tenant scope.
• Component responsibilities
  • Verify returning identity.
  • Establish an authenticated session.
  • Route a verified user to the correct authorized destination.
• States and recovery
  • Loading state while verification is processed.
  • Success state establishes an authenticated session.
  • Error state explains that access was not established without disclosing protected tenant data.
  • The user can correct input and retry verification.
  • A user who needs first access can continue to Sign Up.

Sign Up

• Information and state
  • Supports self-service first-use enrollment for Gym Owner / Tenant Administrator.
  • Creates the basis for a new gym tenant and the owner’s first authenticated access.
• Primary actions
  • Provide enrollment information and submit the request to create a tenant.
• Supporting actions
  • Navigate to Login when the owner already has established access.
• Domain entities
  • Gym tenant.
  • Gym Owner / Tenant Administrator identity.
  • Authenticated session.
• Component responsibilities
  • Collect the minimum enrollment information required to establish the owner and gym tenant.
  • Create the new tenant.
  • Establish the owner’s initial access after successful enrollment.
• States and recovery
  • Loading state while enrollment is processed.
  • Success state confirms tenant creation and continues to Dashboard.
  • Error state prevents partial access from being treated as successful.
  • The owner can correct enrollment input and retry.
  • Returning owners can continue to Login instead of enrolling again.

Dashboard

• Information and state
  • Displays a tenant-level operational summary for the authenticated gym tenant.
  • Provides routing to bookings, payments, coupons, vouchers, and gym equipment highlights where the user has access.
  • Shows tenant-scoped activity rather than cross-tenant data.
  • Reflects live booking-slot and payment-status changes in place through SignalR without a page reload.
  • Surfaces real-time notification markers for new or changed operational events.
• Primary actions
  • Navigate to tenant operational areas.
• Supporting actions
  • Review tenant-level booking, payment, promotion, and equipment-highlight context.
• Domain entities
  • Gym tenant.
  • Booking.
  • Payment.
  • Coupon.
  • Voucher.
  • Equipment highlight.
• Component responsibilities
  • Serve as the recurring operational entry point for Gym Owner / Tenant Administrator and Gym Staff / Front Desk Operator.
  • Maintain tenant context while routing to authorized workflows.
  • Subscribe to SignalR updates so live booking, payment, and notification state stays current.
• States and recovery
  • Loading state while tenant-level data is retrieved.
  • Empty states when the tenant has no records for a represented area.
  • Error state explains that the summary could not be loaded and supports retry.
  • Unauthorized destinations are not made available to a user lacking the required role-restricted access.

Bookings

• Information and state
  • Displays bookings belonging to the authenticated gym tenant.
  • Supports booking creation, viewing, updating, and cancellation.
  • Presents a live booking board of horizontal time bands where occupied slots are graphite blocks and available slots are off-white outlines.
  • Updates the exact changed slot in place through SignalR, flashing orange once before settling.
• Primary actions
  • Create a booking.
  • Select and view an existing booking.
  • Update an existing booking.
  • Cancel an existing booking.
• Supporting actions
  • Return to Dashboard or continue to Payments when payment work is needed for a booking.
• Domain entities
  • Gym tenant.
  • Booking.
  • Associated payment.
• Component responsibilities
  • Maintain tenant-scoped booking records.
  • Show the observable state of created, updated, and cancelled bookings.
  • Preserve the association between a booking and any related payment record.
  • Render live slot availability and apply real-time SignalR slot changes at the exact affected time band.
• States and recovery
  • Loading state while booking data is retrieved.
  • Empty state when the tenant has no bookings.
  • Success state confirms the created, updated, or cancelled booking result.
  • Error state prevents an unsuccessful change from appearing complete.
  • The user can correct the relevant booking input or retry the operation.
  • After completion, the user can continue managing bookings or proceed to related payment work.

Payments

• Information and state
  • Displays payment records for the authenticated gym tenant.
  • Supports recording and viewing payments associated with bookings.
  • Presents UPI checkout as a payment instrument panel with a ruled status sequence from Initiated to Awaiting confirmation to Paid.
  • On mobile, offers an orange "Open payment app" control that fires a UPI deep-link intent into the user's installed payment app.
  • On web, offers a QR / collect fallback with a large QR field and a collect request, since UPI intent links cannot fire from a desktop browser.
• Primary actions
  • Record a payment for a booking.
  • View a recorded payment.
• Supporting actions
  • Return to the related booking when booking information must be reviewed.
• Domain entities
  • Gym tenant.
  • Booking.
  • Payment.
• Component responsibilities
  • Associate each recorded payment with the applicable booking.
  • Present tenant-scoped payment records.
  • Show the observable result of successfully recording a payment.
  • Drive the UPI payment status sequence in real time through SignalR, from Initiated to Awaiting confirmation to Paid.
• States and recovery
  • Loading state while payment records are retrieved.
  • Empty state when the tenant has no payment records.
  • Success state confirms that a payment record has been recorded.
  • Error state prevents an unsuccessful payment record from being treated as recorded.
  • The user can correct payment information or retry recording.
  • The user can continue to payment review or return to the related booking.

Coupons

• Information and state
  • Displays coupon records for the authenticated gym tenant.
  • Supports coupon creation, viewing, updating, and redemption.
• Primary actions
  • Create a coupon.
  • View a coupon.
  • Update a coupon.
  • Redeem a coupon.
• Supporting actions
  • Review the observable coupon state after creation, update, or redemption.
• Domain entities
  • Gym tenant.
  • Coupon.
  • Coupon redemption.
• Component responsibilities
  • Maintain tenant-scoped coupons.
  • Present coupon records and redemption status.
  • Record the outcome of a coupon redemption.
• States and recovery
  • Loading state while coupon records are retrieved.
  • Empty state when the tenant has no coupons.
  • Success state confirms coupon creation, update, or redemption.
  • Error state prevents unsuccessful coupon changes or redemption from appearing complete.
  • The user can correct coupon information or retry the operation.
  • The user can continue managing coupons after completion.

Vouchers

• Information and state
  • Displays voucher records for the authenticated gym tenant.
  • Supports voucher creation, viewing, updating, and redemption.
• Primary actions
  • Create a voucher.
  • View a voucher.
  • Update a voucher.
  • Redeem a voucher.
• Supporting actions
  • Review the observable voucher state after creation, update, or redemption.
• Domain entities
  • Gym tenant.
  • Voucher.
  • Voucher redemption.
• Component responsibilities
  • Maintain tenant-scoped vouchers.
  • Present voucher records and redemption status.
  • Record the outcome of a voucher redemption.
• States and recovery
  • Loading state while voucher records are retrieved.
  • Empty state when the tenant has no vouchers.
  • Success state confirms voucher creation, update, or redemption.
  • Error state prevents unsuccessful voucher changes or redemption from appearing complete.
  • The user can correct voucher information or retry the operation.
  • The user can continue managing vouchers after completion.

Equipment Highlights

• Information and state
  • Displays equipment-image highlights for the authenticated gym tenant.
  • Supports uploading and managing images that highlight equipment at that gym.
  • Presents AI-generated equipment imagery as the gym highlight sections, art-directed as studio product documentation rather than generic fitness lifestyle photography.
  • Pairs each square equipment crop with a technical annotation strip naming equipment, gym zone, condition, and a numbered orange locator mark.
• Primary actions
  • Upload an equipment image.
  • Manage an existing equipment-image highlight.
• Supporting actions
  • Review the tenant’s existing equipment-image highlights.
• Domain entities
  • Gym tenant.
  • Equipment image.
  • Equipment highlight.
• Component responsibilities
  • Store and present equipment images within the correct gym tenant.
  • Support management of images used as gym equipment highlights.
  • Show the observable result of successful image upload or management.
  • Bring all equipment AI images into the product as managed tenant assets that drive the gym highlight sections.
• States and recovery
  • Loading state while equipment highlights are retrieved.
  • Empty state when the gym has no equipment-image highlights.
  • Success state confirms uploaded or managed equipment highlights.
  • Error state identifies unsuccessful image processing or management without creating a false success state.
  • The owner can correct the image selection or retry the operation.
  • The owner can continue managing equipment-image highlights after completion.

Tenants

• Information and state
  • Displays gym tenants across the multi-tenant CRM for Platform Operator (Multi-Tenant).
  • Supports tenant provisioning and management.
• Primary actions
  • Provision a gym tenant.
  • View and manage an existing gym tenant.
• Supporting actions
  • Review the platform-level tenant list and tenant status needed for cross-tenant administration.
• Domain entities
  • Gym tenant.
  • Platform Operator (Multi-Tenant).
  • Tenant-scoped operational data.
• Component responsibilities
  • Create tenant availability before tenant-scoped operational work exists.
  • Maintain a coherent platform-level view of gym tenants.
  • Preserve the separation of each tenant’s bookings, payments, coupons, vouchers, and equipment highlights.
• States and recovery
  • Loading state while tenant information is retrieved.
  • Empty state when no gym tenants have been provisioned.
  • Success state confirms provisioning or management changes.
  • Error state prevents an unsuccessful tenant change from appearing complete.
  • The platform operator can correct tenant information and retry.
  • After completion, the operator can continue managing tenants.

3. Functional Requirements

FR-01 — Gym CRM

As a Gym Owner / Tenant Administrator, I should use a CRM for my gym so that I can oversee the gym’s operational and commercial activity.

• Provenance: explicit.
• Trigger and access: An authenticated owner enters the role-restricted tenant workspace.
• Required behavior: The CRM shall provide tenant-scoped access to booking, payment, coupon, voucher, and equipment-highlight operations.
• Observable result: The owner can reach and use the accepted operational areas for their gym tenant.
• Failure and recovery: If tenant data cannot be loaded, the system shall present an error state and permit retry without exposing another tenant’s information.
• Continuation: The owner can continue to the relevant operational page from Dashboard.

FR-02 — Multi-Tenant Data Organization

As a Platform Operator (Multi-Tenant), I should manage a multi-tenant gym CRM so that each gym operates in its own tenant.

• Provenance: explicit.
• Trigger and access: The authenticated platform operator accesses the role-restricted Tenants page.
• Required behavior: The system shall organize CRM data per gym tenant.
• Observable result: A gym tenant is represented as a distinct operational context whose bookings, payments, coupons, vouchers, and equipment highlights are associated with that tenant.
• Failure and recovery: If tenant-scoped information cannot be retrieved or updated, the system shall show an error state and allow the operator to retry without treating the change as complete.
• Continuation: The operator can continue managing tenants from Tenants.

FR-03 — Gym Owner Self-Service Enrollment

As a Gym Owner / Tenant Administrator, I should enroll my gym through self-service sign-up so that I can create a tenant and gain first access.

• Provenance: required_inference.
• Trigger and access: An anonymous prospective owner selects Sign Up from Landing.
• Required behavior: The system shall allow the owner to provide the enrollment information needed to create a gym tenant and establish the owner’s first access.
• Observable result: Successful enrollment creates the gym tenant and establishes an authenticated owner session.
• Failure and recovery: If enrollment fails, the system shall not establish tenant access, shall identify the unsuccessful outcome, and shall allow corrected input and retry.
• Continuation: After success, the owner continues to Dashboard; an already enrolled owner can continue to Login.

FR-04 — Returning Identity Verification

As a Gym Owner / Tenant Administrator, Gym Staff / Front Desk Operator, or Platform Operator (Multi-Tenant), I should verify my identity when returning so that I can access the appropriate protected work.

• Provenance: required_inference.
• Trigger and access: An anonymous returning user opens Login.
• Required behavior: The system shall verify the returning user’s identity and establish an authenticated session before protected records are available.
• Observable result: A successfully verified user is routed to the authorized application context.
• Failure and recovery: If verification fails, protected data shall remain unavailable and the user shall be able to correct input and retry.
• Continuation: Gym owners and staff continue to authorized tenant operations; platform operators continue to Tenants.

FR-05 — Tenant-Scoped Operational Session

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should work within a single authenticated gym tenant so that I act only on the correct gym’s operational records.

• Provenance: required_inference.
• Trigger and access: A verified gym owner or staff member enters a role-restricted operational page.
• Required behavior: The system shall scope booking, payment, coupon, voucher, and equipment-highlight work to a single gym tenant.
• Observable result: Operational data presented and changed through tenant pages belongs to the authenticated tenant context.
• Failure and recovery: If a valid tenant context cannot be established, the system shall withhold tenant operational data and require the user to re-establish valid access through Login.
• Continuation: The user resumes authorized work through Dashboard or the relevant operational page.

FR-06 — Booking Management

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should create, view, update, and cancel bookings so that gym bookings are accurately managed.

• Provenance: explicit for booking support; required_inference for the complete booking lifecycle.
• Trigger and access: An authenticated, authorized user opens Bookings.
• Required behavior: The system shall allow the user to create, view, update, and cancel bookings for the current gym tenant.
• Observable result: The booking list and booking detail reflect the resulting created, updated, or cancelled state.
• Failure and recovery: If a booking action cannot be completed, the system shall not present it as successful and shall allow the user to correct relevant input or retry.
• Continuation: The user can continue managing bookings or proceed to Payments for booking-associated payment work.

FR-07 — Payment Management

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should record and view payments associated with bookings so that booking-related payments are managed by my gym.

• Provenance: explicit for payment support; required_inference for recording and viewing booking-associated payments.
• Trigger and access: An authenticated, authorized user opens Payments or continues from booking work.
• Required behavior: The system shall allow the user to record and view payments associated with bookings in the current gym tenant.
• Observable result: A successfully recorded payment is visible as a payment record associated with the relevant booking.
• Failure and recovery: If payment recording fails, the system shall not create a false completed payment record and shall allow the user to correct information or retry.
• Continuation: The user can review payments or return to the related booking.

FR-08 — Coupon Management and Redemption

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should create, view, update, and redeem coupons so that promotions can be managed and applied correctly.

• Provenance: explicit for coupon support; required_inference for the stated create, view, update, and redemption lifecycle.
• Trigger and access: An authenticated, authorized user opens Coupons.
• Required behavior: The system shall allow the user to create, view, update, and redeem coupons for the current gym tenant.
• Observable result: Coupon records show the result of creation, update, or redemption.
• Failure and recovery: If a coupon action or redemption cannot be completed, the system shall preserve the prior confirmed state, identify the failure, and allow retry or corrected input.
• Continuation: The user can continue managing coupons after the completed action.

FR-09 — Voucher Management and Redemption

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should create, view, update, and redeem vouchers so that vouchers can be managed and applied correctly.

• Provenance: explicit for voucher support; required_inference for the stated create, view, update, and redemption lifecycle.
• Trigger and access: An authenticated, authorized user opens Vouchers.
• Required behavior: The system shall allow the user to create, view, update, and redeem vouchers for the current gym tenant.
• Observable result: Voucher records show the result of creation, update, or redemption.
• Failure and recovery: If a voucher action or redemption cannot be completed, the system shall preserve the prior confirmed state, identify the failure, and allow retry or corrected input.
• Continuation: The user can continue managing vouchers after the completed action.

FR-10 — Equipment Image Highlights

As a Gym Owner / Tenant Administrator, I should upload and manage equipment images used as highlights about my gym so that the gym’s equipment is represented accurately.

• Provenance: explicit for equipment images used as gym highlights; required_inference for upload and management.
• Trigger and access: An authenticated, authorized owner opens Equipment Highlights.
• Required behavior: The system shall allow the owner to upload and manage equipment images for use as highlights about the current gym tenant.
• Observable result: Successfully uploaded or managed images appear in that gym’s equipment highlights.
• Failure and recovery: If image upload or management fails, the system shall not show an unconfirmed image as successfully managed and shall allow the owner to correct image selection or retry.
• Continuation: The owner can continue managing the gym’s equipment-image highlights.

FR-12 — Blazor Server Web App with SignalR Real-Time Updates

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should use a Blazor Server web app with SignalR so that live booking slots and notifications update instantly.

• Provenance: explicit.
• Trigger and access: An authenticated, authorized user opens the product web app.
• Required behavior: The product web app shall be built in Blazor Server, real-time updates and notifications shall use SignalR, and the web app shall connect to backend services through the secured API Gateway, which shall use EF Core backed by MS SQL Server.
• Observable result: Live booking slots, payment status changes, and notification markers update in place without a page reload.
• Failure and recovery: If a real-time update cannot be delivered, the system shall not present stale state as current and shall allow the user to refresh or retry.
• Continuation: The user continues working in the current tenant context with current operational state.

FR-13 — MAUI Blazor Hybrid Mobile App

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should use a MAUI Blazor Hybrid mobile app so that I can run gym operations from a phone with the same components as the web app.

• Provenance: explicit.
• Trigger and access: An authenticated, authorized user opens the mobile app.
• Required behavior: The mobile app shall be built in MAUI Blazor Hybrid, shall share the same component library as the web app, and shall connect to backend services through the secured API Gateway, which shall use EF Core backed by MS SQL Server.
• Observable result: The mobile app presents the same tenant-scoped operational capabilities as the web app without a separately built UI.
• Failure and recovery: If the mobile app cannot load tenant data, the system shall present an error state and permit retry without exposing another tenant's information.
• Continuation: The user continues the relevant operational workflow on mobile.

FR-14 — Native UPI Payment Checkout

As a Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator, I should pay through native UPI by opening a phone payment app so that checkout matches the flow Indian users already trust.

• Provenance: explicit.
• Trigger and access: An authenticated, authorized user initiates payment for a booking in the current gym tenant.
• Required behavior: The payment gateway shall use native UPI payment by opening a phone payment app such as GPay or BHIM, similar to most Indian apps. On mobile, checkout shall use a UPI deep-link intent that opens the user's installed payment app. On web, because UPI intent links cannot fire from a desktop browser, checkout shall present a QR / collect fallback with a scannable UPI QR field and a collect request.
• Observable result: The payment instrument panel shows a ruled status sequence from Initiated to Awaiting confirmation to Paid, updated in real time through SignalR.
• Failure and recovery: If the payment app cannot be opened, the intent is declined, or the collect request is not confirmed, the system shall not mark the payment as Paid and shall allow the user to retry or choose the fallback method.
• Continuation: On confirmation, the user can review the payment record or return to the related booking.

FR-15 — Modern Unique UI with AI Equipment Imagery

As a Gym Owner / Tenant Administrator, I should present a modern, unique interface with AI-generated equipment imagery so that my gym's equipment is a credible differentiator.

• Provenance: explicit.
• Trigger and access: An authenticated, authorized user views the product UI, and the owner manages equipment highlights.
• Required behavior: The UI shall be modern and unique, and all equipment AI images shall be brought into the product as equipment-image highlights driving the gym highlight sections.
• Observable result: Equipment highlight modules pair a square AI equipment crop with a technical annotation strip, and the interface reads as a gym operations instrument panel rather than a generic SaaS dashboard.
• Failure and recovery: If an equipment image cannot be processed or displayed, the system shall identify the unsuccessful outcome without creating a false success state and shall allow the owner to correct the image selection or retry.
• Continuation: The owner can continue managing the gym's equipment-image highlights.

FR-11 — Tenant Provisioning and Management

As a Platform Operator (Multi-Tenant), I should provision and manage gym tenants so that tenant-scoped operational work can exist and remain manageable across the platform.

• Provenance: required_inference.
• Trigger and access: An authenticated, authorized platform operator opens Tenants.
• Required behavior: The system shall allow the platform operator to provision and manage gym tenants.
• Observable result: A successfully provisioned gym becomes available as a distinct tenant context for operational work.
• Failure and recovery: If a tenant provisioning or management operation fails, the system shall not treat the tenant change as complete and shall allow correction and retry.
• Continuation: The platform operator can continue reviewing and managing tenants.

4. User Personas

Gym Owner / Tenant Administrator

The Gym Owner / Tenant Administrator runs a single gym tenant in the multi-tenant CRM and is accountable for the gym’s commercial and operational representation.

• Primary goal: Maintain accurate, controllable gym operations, promotions, payment records, bookings, and equipment-image highlights within the gym’s own tenant.
• Responsibilities: Establish first access for a new gym tenant, review tenant-level activity, oversee bookings and payments, manage coupons and vouchers, and upload and manage equipment images used as highlights about the gym.
• Inputs and decisions: Provides enrollment information when starting a new gym; decides how bookings, payment records, coupons, vouchers, and equipment highlights should be maintained.
• Interaction with other accepted participants: Works in the same tenant-scoped operational environment as Gym Staff / Front Desk Operator. The owner’s tenant is provisioned and managed at the platform level by Platform Operator (Multi-Tenant).
• Observable success: The gym’s bookings, payments, promotions, and equipment highlights are accurately represented and controllable within the correct tenant.
• Provenance: required_inference from Planning Scope.

Gym Staff / Front Desk Operator

The Gym Staff / Front Desk Operator handles the gym’s daily member-facing operational work within the assigned gym tenant.

• Primary goal: Ensure bookings, payment records, coupon redemptions, and voucher redemptions are handled correctly during gym operations.
• Responsibilities: Create and adjust bookings, record and review booking-associated payments, and apply coupons or vouchers when they are redeemed.
• Inputs and decisions: Selects the relevant tenant booking, enters operational booking or payment information, and determines whether the applicable coupon or voucher should be redeemed in the current workflow.
• Interaction with other accepted participants: Performs daily tenant work that the Gym Owner / Tenant Administrator oversees. Works only within the tenant context made available through the multi-tenant platform.
• Observable success: Members are booked, charged, and discounted correctly without leaving the front-desk workflow.
• Provenance: required_inference from Planning Scope.

Platform Operator (Multi-Tenant)

The Platform Operator (Multi-Tenant) oversees gym tenants across the CRM platform.

• Primary goal: Ensure each gym operates in its own manageable tenant while the platform retains a coherent view of the tenant estate.
• Responsibilities: Provision and manage gym tenants and maintain the platform-level organization required for tenant-scoped booking, payment, coupon, and voucher operations.
• Inputs and decisions: Provides and updates the tenant information needed for provisioning and management decisions.
• Interaction with other accepted participants: Creates and manages the tenant contexts used by Gym Owner / Tenant Administrator and Gym Staff / Front Desk Operator.
• Observable success: Gym tenants are available, manageable, and separated so that each gym’s operational records remain in its own tenant.
• Provenance: required_inference from Planning Scope.

5. Core User Flows

Flow 1 — Gym Owner Creates a New Gym Tenant

1. An anonymous prospective Gym Owner / Tenant Administrator opens Landing.
2. The owner reviews the explanation of the multi-tenant gym CRM and its booking, payment, coupon, voucher, and equipment-highlight capabilities.
3. The owner selects Sign Up.
4. On Sign Up, the owner provides the information required to enroll and create a gym tenant.
5. The owner submits the enrollment request.
6. The system processes the enrollment request and creates the tenant when successful.
7. The owner observes successful tenant creation and an authenticated first-access state.
8. The owner continues to Dashboard for the new tenant.
9. If enrollment fails, the owner sees the unsuccessful result, corrects relevant input, and retries; no tenant access is treated as established until enrollment succeeds.

Flow 2 — Returning User Verifies Identity

1. A returning Gym Owner / Tenant Administrator, Gym Staff / Front Desk Operator, or Platform Operator (Multi-Tenant) opens Login.
2. The user provides identity-verification information.
3. The user submits the verification request.
4. The system verifies the identity and establishes an authenticated session on success.
5. A Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator continues to an authorized tenant workspace, beginning with Dashboard.
6. A Platform Operator (Multi-Tenant) continues to Tenants.
7. If verification fails, protected records remain unavailable; the user corrects input and retries.
8. A gym owner needing first access may continue to Sign Up.

Flow 3 — Owner or Staff Manages a Booking

1. An authenticated Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator enters Dashboard in the current gym tenant.
2. The user selects Bookings.
3. On Bookings, the user chooses to create a new booking or select an existing booking.
4. For a new booking, the user provides booking information and submits the booking action.
5. For an existing booking, the user views the booking and chooses to update or cancel it.
6. The system records the created, updated, or cancelled booking state for the current tenant.
7. The user observes the resulting booking state.
8. The user continues managing bookings or proceeds to Payments when payment work is needed.
9. If a booking change fails, the system does not present the action as complete; the user corrects relevant input or retries.

Flow 4 — Owner or Staff Records and Reviews a Payment

1. An authenticated Gym Owner / Tenant Administrator or Gym Staff / Front Desk Operator opens Payments from Dashboard or continues from booking work.
2. The user identifies the booking associated with the payment.
3. The user records the payment information.
4. The user submits the payment-recording action.
5. The system associates the payment record with the applicable booking in the current tenant.
6. On mobile, the user selects the orange "Open payment app" control, which fires a UPI deep-link intent into an installed payment app such as GPay or BHIM.
7. On web, because UPI intent links cannot fire from a desktop browser, the user scans the UPI QR field or sends a collect request and confirms it in their phone payment app.
8. The payment instrument panel shows the ruled status sequence Initiated to Awaiting confirmation to Paid, updated in real time through SignalR.
9. If the payment app cannot be opened, the intent is declined, or the collect request is not confirmed, the payment is not marked Paid and the user retries or chooses the fallback method.
10. The user