# SupportInsights — Starter BRD > **What this is**: A starter BRD. Sections 1–3 are filled in to the level a real stakeholder might hand to an analyst. Sections 4–8 are intentionally underspecified — they are the exercise. > > **How to use it**: Apply the [eight-section template](brd-template.md) and the transcript-driven elicitation loop (Appendix E § Section 2) to complete it. Compare your completed BRD against the [SupportInsights completed exemplar](supportinsights-completed.md) (same domain, direct comparison of Sections 4–8) or the [AIRS exemplar](airs-exemplar.md) (different domain, shows the eight-section shape holds across contexts). --- ## 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-03 - **Priority**: Medium ### 1. Executive Summary The Director of Customer Support manages a 47-person front-line support organization across three time-zone-aligned pods. 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." ### 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. ### 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 [PLACEHOLDER: Run the elicitation loop. The reconciled "ticket" definition is foundational — the success criterion likely includes "the three weekly decisions can be made from the same dashboard without contradiction." Other criteria need elicitation: turnaround time, audit-trail requirements, how the Director and the three analysts split editing-vs-reading roles.] ### 5. Stakeholder Requirements [PLACEHOLDER: The Director is the request stakeholder. The three analysts whose separate reports this consolidates (workforce-planning, support-operations, content lead) are likely primary users — each of them needs the drill-down to their sub-population. The three pod leads may be primary or secondary users depending on whether they make their own pod-level decisions or simply receive the Director's. Confirm.] ### 6. Data Requirements [PLACEHOLDER: The support-ticket system is the primary source; the workforce-planning system is the secondary source for scheduling data; the knowledge-base system is the third source for article-reference and "no article found" tag data. Refresh frequency is likely daily (weekly decisions are made Monday; data needs to be current through end-of-day Friday). Historical horizon at least 12 months for seasonal-pattern detection. The reconciled "ticket" definition is the most important data-requirement decision — name it explicitly here.] ### 7. Deliverables [PLACEHOLDER: Power BI report most likely. Mobile requirement likely no (the weekly decisions are made in a Monday meeting at desk). Target go-live should account for at least two weeks of trial use against the existing three separate reports before the cutover.] ### 8. Constraints & Assumptions [PLACEHOLDER: The reconciled "ticket" definition is a constraint (must be agreed across all three analyst roles before deployment). The dashboard cannot expose ticket content (customer PII) without redaction. Assumptions include the three analysts will adopt the new consolidated view rather than continuing to maintain their separate reports — name the change-management plan that supports the assumption.] ### Approval | Role | Name | Date | Signature | | --- | --- | --- | --- | | Stakeholder (Director of Customer Support) | | | | | Data Owner (Support Tooling) | | | | | Analyst | | | | --- **Practice prompt**: Compose a realistic transcript (a Director-and-three-analysts working session where the conflicting "ticket" definitions surface) or use a real one. Run the loop. Note where the contradiction-log prompt becomes useful — the three analysts will give different answers to the same question.