Structured prompt to document a single operational metric: its calculation, ownership, data sources, and known limitations. Use this to build a metric dictionary and ensure consistent KPI definitions across teams.
You are a metrics documentation specialist. Define the operational metric below with precision and clarity so any operator can calculate it consistently.
Metric Name: {{metricName}}
Business Context: {{businessContext}}
Current Definition (if any): {{currentDefinition}}
Provide the following:
1. **Metric Definition**: One-sentence, unambiguous definition.
2. **Calculation Formula**: Show numerator, denominator, and any filters or exclusions. Use pseudocode or SQL-like syntax.
3. **Data Sources**: List systems, tables, or APIs that feed this metric. Include refresh frequency (real-time, hourly, daily).
4. **Owner & Escalation**: Primary owner name/team, secondary owner, escalation contact for data issues.
5. **Target Range**: Acceptable range or SLA (e.g., 95–99%, <2 hours). Note if this is aspirational or historical baseline.
6. **Known Caveats**: List 3–5 limitations, edge cases, or data quality issues (e.g., "excludes refunded transactions," "lags 24 hours," "does not account for timezone differences").
7. **Calculation Examples**: Show one correct and one incorrect calculation to prevent misuse.
8. **Review Cadence**: How often this definition should be reviewed and by whom.
Format as a structured metric card suitable for a team wiki or metric dictionary.1. Fill in the three input fields with your metric name, business context, and any existing definition. 2. Run the prompt. 3. Review the generated metric card for accuracy—especially the formula and caveats. 4. Assign an owner and add to your metric dictionary or wiki. 5. Share with stakeholders and set a review cadence (quarterly or annual). 6. Use this card as the source of truth when building dashboards, reports, or alerts.
Metric Name: Support Ticket Resolution Time Business Context: Measures how quickly our support team closes customer tickets. Directly impacts customer satisfaction and team efficiency. Current Definition: Average time from ticket creation to closure.
**Metric Card: Support Ticket Resolution Time**
**Definition**: The median number of hours between ticket creation timestamp and closure timestamp, excluding tickets closed as duplicates or invalid.
**Formula**:
Numerator: SUM(closure_time - creation_time) for all closed tickets in period
Denominator: COUNT(closed tickets) in period
Filter: status != 'duplicate' AND status != 'invalid' AND created_date >= {{period_start}}
**Data Sources**:
- Zendesk tickets table (zendesk.tickets)
- Refresh: Daily at 2 AM UTC
- Latency: 4–6 hours
**Owner & Escalation**:
- Primary: Support Operations Manager (support-ops@company.com)
- Secondary: Head of Support
- Data issues: Data Engineering on-call
**Target Range**:
- Current baseline: 18 hours median
- Target (aspirational): <12 hours median
- SLA: No more than 5% of tickets exceed 48 hours
**Known Caveats**:
1. Excludes tickets reassigned >3 times (data quality issue in legacy system).
2. Does not account for time spent in 'on-hold' status; counts wall-clock time only.
3. Lags 6 hours due to ETL pipeline; not suitable for real-time monitoring.
4. Includes only tickets with valid customer_id; ~2% of tickets lack this field.
5. Seasonal spike in Q4; baseline may not apply to holiday periods.
**Calculation Examples**:
- ✓ Correct: Ticket #12345 created 2024-01-15 08:00, closed 2024-01-15 14:30 = 6.5 hours. Include in calculation.
- ✗ Incorrect: Ticket #12346 created 2024-01-15, closed 2024-01-20 (5 days later, but marked 'duplicate'). Exclude from calculation.
**Review Cadence**: Quarterly by Support Operations Manager and Data Engineering. Annual review with Head of Support.