Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

PRD: Marketplace (v. 2)

1. Executive Summary

One-sentence positioning

A centralized, self-service hub where Account Administrators can discover, purchase, and instantly activate native add-ons, AI tools, and third-party integrations to scale their operations.

Problem We’re Solving

Currently, accessing features not included in a base plan requires a manual, high-friction process involving Sales or Support interactions. This delays customer time-to-value and burdens internal teams with manual provisioning tasks, resulting in missed expansion revenue.

Proposed Solution (High Level)

We are building an "App Store" style experience within the Operations web app. This allows admins to browse a catalog of features, understand pricing, and trigger provisioning automatically—updating billing in HubSpot and unlocking entitlements in the app without human intervention.

Primary Value Delivered

  • Revenue enablement: Unlocks expansion MRR via friction-free upsells.

  • Operational efficiency: Eliminates manual provisioning tickets for support/engineering.

  • Strategic differentiation: Positions CXT as a platform ecosystem rather than just a tool.

Who This Is For

  • Buyer / Decision Maker: Billing Admins (Account owners responsible for financial decisions).

  • Primary Users: Org Admins (Who browse/configure).

  • Secondary / Indirect Users: Dispatchers and Drivers (Who benefit from the unlocked features like Chat or Route Optimization).

2. Strategic Context & Alignment

2.1 Why Now

Manual provisioning processes are a bottleneck to scale. As we introduce more modular features (AI Vision, Premium Analytics, AI Document Processes) and partnerships (GigSafe, http://Captur.ai ), we need a scalable mechanism to distribute them without increasing support or sales headcount.

2.2 Strategic Alignment

  • Product Vision: Empowers customers to "seamlessly grow with our platform".

  • Brand Voice: Aligns with "Operator-first" and "Outcome-led" principles by giving users direct control over their tools.

  • Monetization: Supports the shift toward usage-based and modular pricing models.

2.3 Non-Goals (Explicit)

What this project is intentionally not doing

  • Full Plan Management: Users cannot downgrade their core subscription tier (e.g., Enterprise to Professional) via this interface in v1.

  • Revenue Share Management: Automated payouts to 3rd party partners are out of scope.

  • Complex Payments: We are not building a new payment gateway; we are relying on existing billing methods (HubSpot/Billing Server).

3. Problem Statement & Opportunity

3.1 Current State

Today, if a customer wants "Route Optimization," they must email support, wait for a quote, sign an addendum, and wait for an engineer to toggle a feature flag. This process takes days20.

3.2 Impact

  • Business: Lost impulse revenue; high Cost to Serve (CTS) for simple toggles.

  • User: Frustration and delay when they have an immediate operational need.

3.3 Opportunity

By automating this, we target a <60 second time-to-value. This turns compliance and optimization features into instant-access tools, increasing adoption and customer stickiness.

4. User Experience: End-to-End Journey

This section describes how users discover, enable, and live with the feature over time.

4.1 Feature Discovery

Where users encounter this

  • Primary: A dedicated "Marketplace" tab in the main navigation.

  • Contextual: "Locked" features in the UI (e.g., the Premium Analytics tab on the Dashboard) will have empty states prompting users to "Unlock in Marketplace".

What users see

A unified catalog view featuring:

  • Featured Hero: High-value items (e.g., Itinerary Planning).

  • Categorized Lists: Grouped by category: "Operations & AI," "Finance," "Compliance", “Healthcare”, etc., and type (in-app feature, integration, or partnership).

  • Status Indicators: Visual distinction between "Active" (Managed), "Available", and “Coming Soon” (Unavailable) items.

4.2 Activation & Access Control

Who Can Enable This

  • View: All users can browse the catalog.

  • Purchase/Activate: Only "Billing Admins" can commit to financial changes. Non-billing admins will see a disabled button with a tooltip.

  • Open Question: Can we create the concept of a “Billing Admin” within our existing permissions structure or do we need something new?

How It Is Enabled (By Item Type)

  • Type A: Partner Items (e.g., GigSafe)

    • Action: User clicks "Learn More" or "Visit Partner".

    • Behavior: A modal/toast appears: "Redirecting to Partner site. Setup completes externally."

    • Outcome: Opens external tab. No billing change in CXT.

  • Type B: Integration Items (e.g., QuickBooks)

    • Action: User clicks "Connect".

    • Behavior:

      1. Opens Connection Wizard Modal.

      2. User inputs API Key / Client Secret / other credentials and connection information.

      3. User clicks "Test Connection" (spinner -> success check).

      4. User completes any necessary field mapping.

      5. User clicks "Save & Sync."

      6. Billing Confirmation Modal appears

        1. For usage based integrations: "Confirm addition of $X per <user|driver|order> to your bill?"

        2. For fee based integrations: "Confirm addition of $X/mo to your bill?"

    • Outcome: Integration is active; data begins syncing.

  • Type C: In-App/Native Items (e.g., Premium Analytics, Itinerary Planning)

    • Action: User clicks "View Pricing"

    • Behavior:

      1. Page scrolls to Pricing Tiers (Starter/Pro/Enterprise).

      2. User selects a tier and clicks "Activate."

      3. Billing Confirmation Modal appears: "Confirm addition of $X/mo to your bill?"

    • Outcome: Entitlement is provisioned immediately (<60s); billing is updated in HubSpot.262626.

4.3 Post-Activation Experience (Steady State)

Day-to-Day UX Changes

  • Marketplace View: Cards change visual state from White/Black (Available) to Light Green (Installed). Buttons change from "Add/Connect" (primary styling) to "Manage/Configure" (tertiary styling).

  • App Navigation: New menu items appear (e.g., "Itinerary Planning" appears in the Dispatch menu).

Failure & Edge States

  • Provisioning Fail: If HubSpot/Billing Server billing succeeds but feature activation fails, the system auto-alerts support and sets the UI to a "Processing/Retrying" state. It allows manual rollback.

  • Payment Fail: If a payment fails in HubSpot/Billing Server, the entitlement enters a "Suspended" state, and the user sees a banner to update payment details.

5. Scope & Phasing

Phase 1 — MVP / Initial Release

  • Catalog: Search, Filter, Detail Pages.

  • Item Support:

    • Flat-rate recurring add-ons (Itinerary Planning).

    • Simple Redirect Partners.

  • Backend: HubSpot Billing connection (Write-only), Entitlement Service.

     

Phase 2 — Future Enhancements

  • Usage-Based Billing: Metered integrations (price per API call/scan).

  • Self-Service Proration: Handling mid-cycle upgrades seamlessly.

  • Review System: Ability for users to leave star ratings/reviews on marketplace items.

6. Functional Requirements (High Level)

  • Catalog Management: System must support defined data models for Partners, Integrations, and In-App items.

  • Role Enforcement: API must block non-Billing Admins from executing purchase endpoints.

  • Idempotency: Purchase requests must be idempotent to prevent duplicate charges on network retries.

  • Propagation: Entitlements must propagate to Mobile (Driver App), Web (Ops), and Client Portal.

7. System Architecture & Technical Considerations

7.1 Systems Involved

  • Marketplace API: Gateway for UI requests.

  • HubSpot: Source of Truth for Billing/Subscriptions.

  • Entitlements Service: Source of Truth for "What can this tenant do?"41.

7.2 Data Ownership & Flow

  • Write: Marketplace UI -> Orchestrator -> HubSpot (Creates Subscription).

  • Read: HubSpot (Webhooks) -> Entitlements Service -> App Features.

7.3 Key Technical Decisions

  • HubSpot as Billing Truth: We do not store credit cards or manage invoices; we delegate strictly to HubSpot.

  • Configuration-Driven UI: The Marketplace UI should be rendered based on a config file (similar to @nav.service.ts) to easily add new items.

8. Data Model & Schema Strategy

Standardized Fields

  • MarketplaceItem: id, title, summary, type (partner/integration/in-app).

  • Entitlement: tenant_id, feature_code, state, start_ts, end_ts.

     

Extensibility

  • IntegrationItem requires a flexible wizardConfig schema to define input fields (API Key vs. OAuth tokens) without code changes.

9. Monetization, Packaging & Enablement

9.1 Pricing & Packaging

  • Recurring: Flat monthly fee (e.g., $49/mo).

  • Usage: Pay-per-unit (e.g., $0.10 per load).

  • Trial: Items can have a trial_available flag resulting in a $0 line item for N days44.

9.2 Sales & Support Enablement

  • Sales can link directly to specific Marketplace Items.

  • Support can view a tenant's "Entitlements" in the admin back-office to debug access issues45.

     

10. Success Metrics & Guardrails

Primary Success Metrics

  • Expansion MRR: Revenue generated from self-service actions46.

  • Provisioning Success Rate: ≥ 99.5% success on first try47.

  • Time-to-Value: < 60 seconds from "Purchase" to "Feature Active"48.

     

Operational Guardrails

  • Least Privilege: Only Billing Admins can buy.

  • Auditability: Every action is logged in an append-only audit trail.

11. Risks, Tradeoffs & Open Questions

Open Product Decisions

  • Proration: Do we charge the full month immediately, or pro-rate v1? Decision: V1 is simple monthly alignment; Proration is V2.

Technical Risks

  • HubSpot Rate Limiting: High volume of usage events could trigger 429 errors. Mitigation: Queueing system.

  • Sync Drift: HubSpot and Entitlements Service getting out of sync. Mitigation: Nightly reconciliation job.

12. Delivery Plan & Epics

Primary Epic(s)

  • Epic 1: Marketplace UI & Catalog (The "Storefront").

  • Epic 2: Billing Orchestrator & HubSpot Connector.

  • Epic 3: Entitlements Service & App Propagation.

Target Milestones

  • Phase 0 (Internal): Itinerary Planning only; feature flagged.

  • Phase 1 (Pilot): Add Partner Redirects; enable Trials.

  • Phase 2 (GA): Full public launch with Usage-based billing.

13. Appendix & Links

PRD Quality Bar (Checklist)

Before marking this PRD “Ready”:

  • Clear user journey from discovery → mature state
  • Explicit non-goals documented
  • System boundaries defined
  • Activation and permissions clearly stated
  • Success metrics agreed upon