Skip to content

Design: CRM Live MRR + Stripe Connect Revenue Dashboard

Superseded — kept for lineage

This is the early DRAFT (2026-05-06). The committed direction is in MRR dashboard — subscription cache decision, which supersedes this draft. Retained here as part of the product memory.

Generated by /office-hours on 2026-05-06 Branch: claude/coupon-plan-restrictions Repo: rakletv3 Status: DRAFT Mode: Startup (Intrapreneurship)

Problem Statement

We need a live dashboard in crm.raklet.com that lists all customers with their MRR and Stripe Connect transaction revenue, replacing the weekly spreadsheet merge workflow.

Demand Evidence

  • Current pain is weekly and recurring, not occasional.
  • Existing process depends on manual export and spreadsheet stitching.
  • The target success condition is to stop preparing the weekly sheet and use the CRM dashboard as the primary source.

Status Quo

  • Revenue reporting is assembled manually from multiple systems.
  • A static HTML prototype was generated from service-connected data and used as reference.
  • The prototype currently hardcodes customer data in-browser and is not safe/maintainable for production embed.

Target User & Narrowest Wedge

  • Primary owner: founder (hands-on producer of the report), with leadership as consumer.
  • V1 wedge: single table with filters and totals (no BI suite), directly replacing weekly spreadsheet flow.

Constraints

  • Must live inside crm.raklet.com and fit existing CRM UX patterns.
  • Must not expose raw finance/customer data in client-side hardcoded payloads.
  • Needs near-real-time behavior requirement from user (fresh enough for operational use).
  • Must reconcile data from at least two systems: MRR source and Stripe Connect transaction fee source.

Premises

  1. Do not ship static hardcoded dataset HTML to production CRM.
  2. Start with one trusted dashboard page in CRM with table + totals as V1 wedge.
  3. To satisfy near-real-time needs, use short-lived cache and explicit refresh contract rather than ad hoc browser service calls.

Approaches Considered

Approach A: CRM-native minimal page over pre-aggregated data

Summary: Add server-rendered CRM page with Kendo table and summary cards from existing backend aggregation.

Effort: M Risk: Low Pros: - Fastest secure path. - Reuses current CRM grid/controller conventions. - Lower integration complexity. Cons: - Near-real-time may be limited by aggregation cadence. - Less flexible for future analytics. Reuses: - Raklet.Crm/Controllers/CustomerController.cs - Raklet.Crm/Views/Customer/Index.cshtml - Raklet.Crm/Views/Shared/Common/_SideBar.cshtml

Summary: Build dedicated backend reporting service/API that returns customer-level MRR + Stripe Connect tx metrics with short cache TTL, consumed by new CRM dashboard page.

Effort: L Risk: Medium Pros: - Best fit for near-real-time requirement. - Clear security boundary and ownership. - Future-ready for exports/alerts/drilldowns. Cons: - More backend + validation work. - Requires reconciliation rules and test coverage. Reuses: - Existing CRM page shell, navigation, and grid rendering patterns. - Existing org/customer identifiers from CRM model.

Approach C: Embed prototype-style HTML module

Summary: Keep prototype UX and embed/iframe inside CRM with data bridge.

Effort: M-L Risk: High Pros: - Preserves prototype look quickly. Cons: - Weak data/auth boundary. - Harder to maintain. - High chance of data drift and trust issues. Reuses: - Prototype presentation only.

Approach B is recommended because the user explicitly requires near-real-time and wants this to replace weekly spreadsheet workflow. Finance-facing dashboards fail when freshness and trust are unclear, so we need a single authoritative reporting contract behind CRM.

Open Questions

  • Pending explicit approach choice from user (A/B/C prompt was skipped).
  • What near-real-time target is acceptable: 5 min, 15 min, 1 hour?
  • Canonical MRR source of truth for CRM report: ProfitWell snapshot, internal billing table, or computed subscription state?
  • Stripe Connect revenue definition: application fees only vs net fees vs gross tx volume slice?
  • Currency normalization rules for mixed-currency orgs.

Success Criteria

  • Founder no longer prepares weekly spreadsheet manually.
  • Dashboard totals match known weekly report within agreed tolerance.
  • Per-customer row data includes MRR and Stripe tx revenue with clear timestamp.
  • Leadership can consume summary totals directly from CRM page.

Distribution Plan

  • Delivery channel: crm.raklet.com internal page in existing CRM nav.
  • Build/deploy: normal rakletv3 build pipeline for CRM/backend; no external static artifact hosting.
  • Runtime: backend reporting endpoint/service with cache policy and audit timestamp shown in UI.

Dependencies

  • Access and mapping between customer/org IDs across MRR source and Stripe Connect data.
  • Backend service ownership for reporting endpoint.
  • Test fixtures covering reconciliation edge cases (missing match, zero tx, currency mismatch).

The Assignment

Define the exact metric contract in writing before implementation: 1. mrr_amount definition and source. 2. tx_revenue_amount definition (which Stripe fields and window). 3. freshness SLA (last_updated_at, max acceptable staleness).

This one contract decision prevents weeks of dashboard trust debt.

What I noticed about how you think

  • You quickly moved from "nice chart" to "embed this into crm.raklet.com so we have a live dashboard", that is deployment-first thinking.
  • You already had a working prototype from service data, which shows bias to shipping something tangible first.
  • You set a strong bar by saying you want this to be live and to replace weekly reporting flow, not a demo view.