# SupportInsights — Completed Exemplar BRD

> **What this is**: A fully authored BRD for the SupportInsights staffing-and-escalation dashboard. Every section is filled in to the level a real Director of Customer Support would sign off on. It is the *finished state* the [SupportInsights starter](supportinsights-starter.md) reaches when the discipline has been applied end to end.
>
> **How to use it**: Read alongside the other exemplars ([AIRS](airs-exemplar.md), [CloudRevenue](cloudrevenue-completed.md), [M365Marketing](m365marketing-completed.md)) to see the same eight-section shape survive across four domains. When you complete the [SupportInsights starter](supportinsights-starter.md) yourself, compare Sections 4–8 against this exemplar for calibration, not imitation. The three validity checks from Chapter 2 (single-sentence, disagreement, reversal) are what matter — a BRD that passes them is defensible even if it differs from this one.

---

## Business Requirements Document

### SupportInsights — Staffing and Escalation Dashboard

- **Project**: Customer-support operations dashboard supporting weekly staffing decisions, escalation-threshold tuning, and knowledge-base prioritization
- **Stakeholder**: Director of Customer Support
- **Date**: 2026-06-10 (draft) / 2026-06-24 (sign-off)
- **Priority**: Medium

### 1. Executive Summary

The Director of Customer Support manages a 47-person front-line support organization across three time-zone-aligned pods (AMER, EMEA, APAC). The dashboard supports three weekly decisions: how many agents to schedule per pod per shift for the coming week, which ticket categories to raise or lower the auto-escalation thresholds for, and which top-five knowledge-base articles to commission or refresh based on recent ticket-volume patterns. The dashboard replaces three separate weekly reports (the scheduling forecast from workforce planning, the escalation-volume report from the support-operations analyst, and the knowledge-base gap analysis from the content team), each of which currently lands on the Director's desk at a different time and uses a different definition of "ticket." The dashboard's primary job is to consolidate the three views into a single reconciled surface so the three weekly decisions are made from the same underlying counts rather than three contradictory ones.

### 2. Business Context

The current state has the Director making the three weekly decisions from three different reports that the support-operations analyst, the workforce-planning analyst, and the content lead each maintain independently. The three reports define "ticket" differently: workforce planning counts every inbound contact (chat, email, phone, in-product), escalation reporting counts only tickets that crossed a severity threshold, and the knowledge-base gap analysis counts only tickets that the agent logged with a "no article found" tag. The Director has three times made staffing decisions that contradicted the escalation-threshold tuning because the underlying ticket counts did not reconcile.

The dashboard consolidates the three views with a single agreed definition of "ticket" at the base and named drill-downs to the three sub-populations each report cares about. The reconciliation itself is the load-bearing work; the visualization on top is straightforward once the counts agree.

### 3. Key Business Questions

***Staffing***

1. What is the forecasted ticket volume per pod per shift for the coming week, broken down by ticket category and severity?
2. Which pods are operating outside their service-level-agreement headroom in the trailing four weeks, and how does that correlate with category mix?
3. What is the expected staffing gap for each pod-shift in the coming week given the current schedule?

***Escalation thresholds***

1. Which ticket categories have escalated to senior-tier support at a rate above their historical baseline in the trailing four weeks?
2. For each category currently auto-escalating to senior tier, what is the resolution rate at the front-line tier for the borderline tickets that fell just below the threshold?
3. Which categories show the largest variance in escalation rate across the three pods (suggesting threshold tuning is needed, not category-level threshold change)?

***Knowledge base***

1. Which ticket categories have the highest volume of "no article found" tags in the trailing four weeks?
2. For categories with high "no article found" volume, what is the front-line resolution rate compared to the rest of the portfolio? (Low resolution rate + high "no article found" = highest content priority.)
3. Which existing knowledge-base articles are referenced in tickets but the article ended up not resolving the ticket (article-quality issue, distinct from article-gap issue)?

### 4. Success Criteria

| Criterion | Measurement |
| --- | --- |
| **Reconciled ticket definition** | The three weekly decisions (staffing, escalation, knowledge-base) are all traceable to a single base "ticket" count with documented drill-down rules to the three sub-populations. Sign-off from the workforce-planning analyst, the support-operations analyst, and the content lead is required before deployment, logged as an appendix to this BRD. |
| **Monday-meeting decisions from one surface** | The Director's Monday operations meeting completes all three weekly decisions from the dashboard alone, without switching to any of the three legacy reports. Measured over the first four consecutive Mondays post-deployment; success = zero cross-reference to legacy reports during the meeting. |
| **Definition-change transparency** | The 2025-09-01 recategorization of two ticket categories (`CAT-FEAT` and `CAT-PROD`) is surfaced with a visible marker on any trailing metric that crosses the boundary; the dashboard does not silently compute averages across the definition change. Tested by walking through the six months either side of 2025-09-01. |
| **APAC staffing-shortage signature detection** | The dashboard flags the known Q2 2026 APAC staffing-shortage signature (elevated resolution-hours penalty concentrated in a specific pod-shift window) as an anomaly rather than treating it as the new baseline. Verified by loading historical data and confirming the callout appears. |
| **PII-safe drill-through** | Ticket-content drill-through masks the customer PII fields (customer name, customer email, and free-text ticket body) at the display layer for all users except the two support-operations administrators who have explicit access. Verified by role-based-access testing against a randomly selected sample of 20 tickets. |

### 5. Stakeholder Requirements

#### Primary Users

- **Director of Customer Support**: Weekly use every Monday at the operations meeting; on-demand use throughout the week when a pod lead flags an urgent situation. Uses the dashboard for the three weekly decisions and for the standing conversations with the pod leads. Requires a *decision-mode view* (one weekly-decision surface per tab) and standard-density working views for the mid-week drill-downs.
- **Support-Operations Analyst**: Daily use during business hours. Primary operator for the escalation-threshold surface; responsible for filing the weekly threshold-tuning recommendations against the dashboard's outputs. Requires drill-through to individual ticket-level records (with PII masked at the display layer per Success Criterion 5).
- **Workforce-Planning Analyst**: Daily use during business hours. Primary operator for the staffing-forecast surface; responsible for translating the dashboard's coming-week forecast into the actual per-pod, per-shift schedule in the workforce-planning tool. Requires drill-through to the raw contact-volume data across all four channels.
- **Content Lead**: Weekly use for the Monday review; on-demand throughout the week when the knowledge-base team is prioritizing content. Requires drill-through to the article-referenced fields to distinguish article-gap issues from article-quality issues.
- **Three Pod Leads (AMER, EMEA, APAC)**: Weekly use ahead of the Monday meeting to prepare their pod-specific talking points. Each pod lead primarily views their own pod's slice; requires the enterprise view for context but does not require deep drill-through into other pods.

#### Secondary Users

- **VP of Customer Experience (Director's manager)**: Monthly use for the standing operations review; quarterly deeper use for the customer-experience quarterly business review.
- **Product Team Liaisons (three roles, one per major product area)**: Occasional use when a spike in a specific product-area category triggers a product-engineering conversation. References the category-level volume trend and the "no article found" pattern for their product area.

### 6. Data Requirements

| Requirement | Detail |
| --- | --- |
| **Data Sources** | (1) Support-ticket system (primary; ticket create/resolve, category, severity, channel, pod, agent, tier, resolution, CSAT, article-referenced, no-article-found tag; nightly refresh); (2) Workforce-planning system (agent schedules and headcount targets per pod-shift; daily refresh); (3) Knowledge-base system (article catalog, categories, last-reviewed date, word count; weekly refresh); (4) Contact-volume system (raw inbound contacts across chat, email, phone, in-product before deduplication; nightly refresh, feeds only the workforce-planning surface's contact-versus-ticket reconciliation). |
| **Refresh Frequency** | Ticket + workforce-planning + contact-volume systems refresh nightly at 02:00 pod-local time; the semantic model is fully consistent by 06:00 in each pod's timezone. Knowledge-base refreshes weekly on Sunday night. The dashboard is fully consistent by 06:00 Pacific every Monday for the Director's operations meeting. |
| **Historical Horizon** | 24 months for the ticket-volume surfaces (needed for year-over-year seasonal-pattern detection). 12 months for the schedule-versus-actual staffing surfaces (workforce-planning system does not retain older records at the required granularity). Full history for the CAT-FEAT / CAT-PROD categories with the 2025-09-01 definition-change marker preserved so any trailing average that crosses the boundary is flagged. |
| **Data Sensitivity** | Confidential. Ticket free-text (customer email body, in-product feedback verbatim) contains PII including customer names, email addresses, and occasionally free-text about the customer's business situation. PII fields are masked at the display layer for all users except the two support-operations administrators. Drill-through to raw ticket content requires the administrator role; the audit trail logs every drill-through access. |
| **Known Quality Issues** | (a) Ticket-definition inconsistency across the three legacy reports (Section 2) — resolved via the reconciled definition per Success Criterion 1. (b) The 2025-09-01 recategorization of `CAT-FEAT` and `CAT-PROD` — pre-change tickets have been retroactively recategorized in the source system, but the dashboard must preserve the definition-change marker per Success Criterion 3 to prevent misleading trailing averages. (c) ~6% null CSAT scores on resolved tickets (customer did not respond to the CSAT survey) — the dashboard reports CSAT as *available-response rate* alongside the score to avoid overstating the response universe. (d) ~5% of article-referenced tickets are tagged with `article_resolved_ticket = false` (article quality issue) — this is the source signal for the article-quality-versus-article-gap distinction in the knowledge-base surface. |

### 7. Deliverables

| Item | Detail |
| --- | --- |
| **Format** | Power BI workspace with four reports: (1) *Monday Operations* (the Director's decision view; three tabs, one per weekly decision, tuned for the 60-minute Monday meeting); (2) *Pod View* (per-pod drill; one page per pod, filter-persistent for each pod lead); (3) *Escalation & Category* (support-operations analyst's daily working surface); (4) *Knowledge-Base Priority* (content lead's daily working surface). Each report has row-level security scoped to the user's role. |
| **Access Method** | Power BI Service, deployed to the Customer Support Operations workspace. Director, three analysts, and content lead access via direct workspace membership. Three pod leads access via a published app; the app hides source datasets and exposes only the two reports they need. Product team liaisons access via a separate read-only app scoped to their product area. Mobile access is not a hard requirement — the Monday meeting happens at desk with a projector — but a phone-friendly view of the top-line staffing forecast is nice-to-have. |
| **Mobile Required** | No (phone-friendly view of the staffing forecast is a nice-to-have, not a blocker). |
| **Target Go-Live** | 2026-09-07 (a Monday). The two Mondays prior (2026-08-24 and 2026-08-31) run the dashboard in trial alongside the three legacy reports; cutover on 2026-09-07 requires that both trial weeks pass all five success criteria. If the reconciled-definition sign-off (Success Criterion 1) is not complete by 2026-08-17, go-live slips one week. |
| **Review Cadence** | Weekly cadence review during the first month post-deployment (with the Director and the three analyst-primary users). Monthly thereafter, aligned to the operations monthly review meeting. |

### 8. Constraints & Assumptions

- **Constraint**: The reconciled ticket definition (Success Criterion 1) must be signed off by the workforce-planning analyst, the support-operations analyst, and the content lead *before* deployment. If any of the three refuses, the dashboard cannot ship a consolidated view — it must either fall back to the three legacy surfaces or omit the disputed drill-down entirely with a visible note. Recreating the three-different-definitions problem is not an acceptable fallback.
- **Constraint**: The 2025-09-01 CAT-FEAT / CAT-PROD recategorization is a permanent feature of the historical data. Any trailing metric that crosses the boundary must display the definition-change marker; hiding the marker for cosmetic simplicity is out of scope.
- **Constraint**: PII drill-through is restricted to two named support-operations administrators. Row-level security must enforce this at the dataset layer, not at the visual layer, so screen-sharing or export cannot leak PII. Audit logging is mandatory on drill-through access.
- **Constraint**: The Director's Monday meeting runs on a fixed 60-minute schedule. Report load time on the *Monday Operations* view must be under 5 seconds per tab; slow tabs push decisions past the meeting boundary, which is a hard failure of the dashboard's primary job.
- **Assumption**: The three analyst-primary users will adopt the consolidated view rather than continuing to maintain their separate legacy reports. The change-management plan (four weekly office hours during the first month, plus the two trial Mondays before cutover) supports the assumption; if adoption stalls, the assumption is falsified and the Director's operations meeting will need a re-planning conversation.
- **Assumption**: The support-ticket system's category taxonomy will remain stable through at least Q2 2027 (no further recategorizations on the scale of the 2025-09-01 CAT-FEAT / CAT-PROD change). Category schema changes below that scale can be absorbed via the semantic-model layer without dashboard rework.
- **Assumption**: The 47-person front-line headcount is stable within ±5 agents through the dashboard's planned 24-month lifetime. Headcount growth beyond that band would surface as a data-model dimension change (new pods, new tiers) rather than a maintenance update.

### Approval

| Role | Name | Date | Signature |
| --- | --- | --- | --- |
| Stakeholder (Director of Customer Support) | | 2026-06-24 | |
| Data Owner (Support Tooling) | | 2026-06-24 | |
| Support-Operations Analyst | | 2026-06-24 | |
| Workforce-Planning Analyst | | 2026-06-24 | |
| Content Lead | | 2026-06-24 | |
| Analyst (author) | | 2026-06-24 | |

Reconciled-ticket-definition sign-off (Success Criterion 1) is logged as an appendix separate from this BRD; sign-off date for the reconciliation round is 2026-08-17.

---

**Pattern notes.** Compare this BRD's stakeholder-requirements section against the other three completed exemplars. SupportInsights has the most primary users (five: Director + three analysts + content lead) because the dashboard is displacing three separate legacy reports whose owners must all be brought along; AIRS has four (PI + senior investigators + statistician + data-governance officer) because the research context has more oversight roles; CloudRevenue has three (VP + chief of staff + GMs) because the sales-ops decision has a clearer single-decision-maker structure; M365Marketing has three (Director + analyst + campaign leads) similarly. The number of primary users is a good proxy for how much change-management effort the deployment requires. If your completed starter has *one* primary user, revisit — you have probably conflated the decision-owner with the day-to-day operator, which is a common Section 5 failure mode.