# CloudRevenue — Completed Exemplar BRD

> **What this is**: A fully authored BRD for the CloudRevenue portfolio dashboard. Every section is filled in to the level a real VP of Cloud Sales Operations would sign off on. It is the *finished state* the [CloudRevenue starter](cloudrevenue-starter.md) reaches when the discipline has been applied end to end.
>
> **How to use it**: Read it as the second worked example (alongside [AIRS Longitudinal](airs-exemplar.md)) for what a complete BRD looks like. AIRS is a research-grade exemplar; CloudRevenue is a commercial-operations exemplar. The two together give you finished BRDs across two domains, so the *shape* of a complete BRD becomes visible rather than domain-specific.
>
> **Then**: When you complete the [CloudRevenue starter](cloudrevenue-starter.md) yourself, compare your Sections 4–8 against the ones here. The point is not to match this BRD field for field; it is to see whether your version passes the three validity checks from Chapter 2 (single-sentence, disagreement, reversal). If it does, your BRD is defensible even if it differs from this one.

---

## Business Requirements Document

### CloudRevenue Portfolio Dashboard — Q4 Investment Planning

- **Project**: Portfolio dashboard for Cloud Sales Operations supporting Q4 investment decisions across the eight product families in the cloud portfolio
- **Stakeholder**: VP of Cloud Sales Operations
- **Date**: 2026-06-10 (draft) / 2026-06-24 (sign-off)
- **Priority**: High

### 1. Executive Summary

The VP of Cloud Sales Operations needs to identify the three product families that should absorb the largest Q4 investment reductions, with defensible rationale for each, in time for the leadership offsite on 2026-09-15. This dashboard consolidates revenue performance, customer-retention, sales-cycle, and territory-coverage metrics across the eight product families in the cloud portfolio into a single source of truth with metric definitions agreed across all eight product general managers in advance. Its primary job is to support the VP's offsite presentation and the accompanying pre-read; its secondary job is to support the routine monthly portfolio review that the VP's office runs with the eight GMs.

### 2. Business Context

Cloud Sales Operations currently relies on a quarterly slide deck assembled by the VP's chief of staff from eight different product-family reports, each maintained by the product GM's own analytics team using inconsistent metric definitions. The Q3 2026 deck took 47 working hours to assemble and surfaced metric-definition disputes in three of the eight product families that absorbed the first hour of the leadership offsite. The Q4 offsite is the trigger event for this project because the offsite converts directly into an investment reduction that will be announced within two weeks; a metric-definition dispute during that offsite is not a discussion — it is a decision delay with a public deadline attached.

The dashboard replaces the assembly work but does not replace the GM conversation. GMs continue to own their product families; the dashboard's job is to eliminate the metric reconciliation cost so the offsite time is spent on decisions rather than definitions.

### 3. Key Business Questions

***Revenue Performance***

1. Which product families have grown, held, or declined in trailing-twelve-month revenue, and by how much?
2. Which product families' Q4 forecasts deviate most from the quarter's planned revenue, and what is driving the deviation?
3. Which product families have the highest revenue concentration in the top ten customers?
4. Which product families' annual recurring revenue is at risk from contracts up for renewal in Q4 or Q1?

***Customer Retention***

1. Which product families have the highest customer churn in the trailing twelve months, and how does churn correlate with sales-cycle length?
2. Which product families show the largest gap between gross retention and net retention?
3. Which customer segments (size band, vertical, geography) drive the most churn for each product family?

***Sales Cycle and Territory***

1. Which product families have the longest average sales cycle, and how has the cycle length trended over the last six quarters?
2. Which territories have the largest revenue concentration in a single product family (territory-product dependency risk)?

### 4. Success Criteria

| Criterion | Measurement |
| --- | --- |
| **Offsite readiness** | The VP can name the three Q4 defund candidates and the rationale for each in under two minutes using only the dashboard, without switching to slides or spreadsheets. Confirmed by a dry-run walkthrough with the chief of staff two weeks before the offsite. |
| **Metric-definition consensus** | All eight product GMs sign off on the definitions of the six primary metrics (trailing-twelve-month revenue, gross retention, net retention, average sales cycle length, top-ten customer concentration, renewal-at-risk ARR) before deployment. Sign-off logged as an appendix to this BRD with the GM's name and date. |
| **Chief-of-staff assembly time** | The Q4 pre-read that currently takes 47 hours to assemble is produced from the dashboard in under 4 hours, including the GM-review round. Measured over the first two quarterly cycles post-deployment. |
| **Monthly review adoption** | The monthly portfolio review with the eight GMs uses the dashboard as the primary visual artifact for at least two consecutive monthly cycles. Confirmed by zero slide-prep hours in the two meetings following deployment. |
| **Territory dependency surfacing** | Any territory with more than 40% of revenue concentrated in a single product family appears on a dedicated risk callout on the territory panel; the VP can identify the top three territory-product dependency risks in under thirty seconds. |

### 5. Stakeholder Requirements

#### Primary Users

- **VP of Cloud Sales Operations**: Weekly use during Q3 pre-offsite prep (July–September 2026); monthly use thereafter for the standing portfolio review. Uses the dashboard for portfolio decisions, GM discussions, and the offsite presentation itself. Requires a presentation-mode view (large screen, minimal chrome, one metric visible at a time) for the offsite; a working view (standard density) for the pre-read and monthly review.
- **Chief of Staff to the VP**: Daily use during Q3 pre-offsite prep, weekly thereafter. Uses the dashboard to assemble the pre-read, prepare talking points for GM conversations, and reconcile the six primary metrics against source-system pulls when disputes surface. Requires drill-through to source-system row-level data on all six primary metrics.
- **Eight Product Family GMs**: Monthly use for the standing portfolio review; on-demand use throughout the quarter. Each GM primarily views their own product family's slice of the portfolio but must be able to compare against the other seven for context. Requires filtered views that persist across sessions (a GM does not want to re-filter to their product every visit).

#### Secondary Users

- **Regional Sales Directors (four, one per major geography)**: Occasional use, primarily during the offsite pre-read cycle. Reference the territory-product dependency risk panel to prepare for the offsite discussion. Do not require deep drill-through.
- **Chief Revenue Officer (VP's manager)**: Quarterly use, primarily during the offsite itself and the executive review that follows. References the dashboard as a presentation artifact rather than as a working tool.

### 6. Data Requirements

| Requirement | Detail |
| --- | --- |
| **Data Sources** | (1) CloudRevenue semantic model (already deployed to the workspace; the analyst's own model, refined over six months); (2) Salesforce opportunity pipeline (weekly extract, feeds the sales-cycle metrics); (3) Renewal system extract (monthly, feeds the renewal-at-risk ARR metric); (4) Territory master file (quarterly, feeds the territory-product dependency panel). Metric-definition reconciliation across the eight product families is required *before* deployment (see Success Criterion 2) and applies to the semantic model, not to the source systems. |
| **Refresh Frequency** | Semantic model refreshes nightly at 02:00 Pacific. Salesforce extract refreshes weekly on Sunday evening. Renewal extract refreshes monthly on the second business day. Territory master refreshes quarterly. During the Q3 pre-offsite prep window (September 1–15), refresh cadence steps up to daily on all four sources. |
| **Historical Horizon** | Six quarters of trailing data at minimum (matches the Chapter 2 comparison-frame default for prior-period reference). Full history is retained for the ARR-at-risk metric so multi-year contract patterns are visible. |
| **Data Sensitivity** | Confidential. Customer names appear only in the top-ten-concentration panel and only to the VP, chief of staff, and the relevant product GM; other users see anonymized customer IDs. No PII beyond customer names is present. Renewal-at-risk detail is confidential to the VP, chief of staff, and the specific renewal owner named in the renewal system. |
| **Known Quality Issues** | (a) Cross-product-family metric-definition disputes (see Section 2) — must be resolved via the metric-definition consensus criterion before deployment. (b) NA-region tenants are inconsistently stored as `NA` or `North America` (~12% of NA tenants) — reconcile in the semantic model with a documented mapping table. (c) The last two months of revenue have ~30% nulls because billing close is not yet complete — surface the in-flight state explicitly in the UI rather than averaging over the incomplete window. (d) Twelve mid-window churners exist in the dataset with the churn date recorded — the retention metrics must exclude their post-churn months from the tenant-count denominator to avoid understating churn. |

### 7. Deliverables

| Item | Detail |
| --- | --- |
| **Format** | Power BI workspace with three reports: (1) *Portfolio Overview* (executive glance, five visuals, drives the offsite one-page pre-read); (2) *Product-Family Deep-Dive* (per-family drill, one page per product family, GM-owned); (3) *Territory Risk* (territory-product dependency panel, quarterly-updated). Each report has an associated dataset with row-level security so GMs see their own product family in the deep-dive while retaining portfolio-view access on the overview. |
| **Access Method** | Power BI Service, deployed to the Cloud Sales Operations workspace. VP, chief of staff, and four regional sales directors access via direct workspace membership. Eight product GMs access via a published app; the app hides the source datasets and exposes only the three reports. Mobile access is not required for this deliverable. |
| **Mobile Required** | No. Offsite venue is a leadership meeting room with large screens; monthly review is a conference room with a projector. |
| **Target Go-Live** | 2026-08-25 (three weeks before the 2026-09-15 offsite; the buffer covers the metric-definition sign-off round with the eight GMs and one dry-run pre-offsite walkthrough with the chief of staff). |
| **Review Cadence** | Monthly during the first quarter post-deployment; quarterly thereafter. The chief of staff owns the review calendar. Any GM can request an interim review by emailing the chief of staff; interim reviews are batched monthly unless the GM flags urgency. |

### 8. Constraints & Assumptions

- **Constraint**: The 2026-09-15 offsite date is fixed. Any slip in the metric-definition consensus round pushes the deployment into a post-offsite window, which invalidates Success Criterion 1. The offsite is a hard deadline for the *Portfolio Overview* report; the *Deep-Dive* and *Territory Risk* reports can slip by up to two weeks without breaking the primary use case.
- **Constraint**: All eight product GMs must sign off on the metric definitions before deployment. If any GM refuses, the dashboard cannot ship the disputed metric — it must show either the reconciled version (both agreed) or the specific GM's version (in the *Deep-Dive* only, with a visible disagreement note). "Ship the analyst's definition and hope no one notices" is not an acceptable fallback because it recreates the exact problem this dashboard is meant to eliminate.
- **Constraint**: Customer-name visibility is restricted per the Data Sensitivity note. UI controls must enforce this at the row-level-security layer, not at the visual layer, so screen-sharing or export cannot leak.
- **Assumption**: The CloudRevenue semantic model is trusted as the authoritative source of subscription revenue. The analyst has maintained it for six months and reconciled it against the finance close monthly; the model is treated as ground truth for revenue rather than being re-derived from source systems.
- **Assumption**: The chief of staff will continue in role through at least Q1 2027. The role has been stable for two years; if turnover occurs mid-cycle, the dashboard's daily-driver responsibilities transfer with the role rather than requiring re-training.
- **Assumption**: The Salesforce extract's opportunity-close-date field is treated as authoritative for sales-cycle length; the analyst has spot-checked against manually-tracked cases and the divergence is under 5%.
- **Assumption**: The eight product families named in the dataset represent the portfolio as of the 2026-09-15 offsite. No product-family additions or divestitures are anticipated in the offsite window; if one occurs, the dashboard filter list requires an emergency update but the structure holds.

### Approval

| Role | Name | Date | Signature |
| --- | --- | --- | --- |
| Stakeholder (VP of Cloud Sales Operations) | | 2026-06-24 | |
| Data Owner (CloudRevenue semantic model) | | 2026-06-24 | |
| Chief of Staff (day-to-day operator) | | 2026-06-24 | |
| Analyst (author) | | 2026-06-24 | |

Product-family GM sign-off on metric definitions (Success Criterion 2) is logged as an appendix separate from this BRD; sign-off date for the metric-definition round is 2026-08-11.

---

**Pattern notes.** Read this BRD against the [AIRS exemplar](airs-exemplar.md) to see two very different domains produce the same eight-section shape. Read it against the [CloudRevenue starter](cloudrevenue-starter.md) to see what Sections 4–8 look like before the discipline is applied. The AIRS exemplar's Success Criterion #1 ("Publication-readiness") and this exemplar's Success Criterion #1 ("Offsite readiness") are structurally identical — both name a specific deliverable, a specific audience, and a specific pass/fail condition. Structural identity across domains is what BRD discipline looks like at scale.