General support
AuraScore 81/100

Enterprise BI and Analytics Self-Service Support Framework

Establish an intake, deflection, and troubleshooting framework for internal business intelligence and data analytics users.

Use this template when building an internal analytics support system to manage reporting defects, metric definition requests, and dashboard outages. It drives ticket deflection through self-service resources while streamlining data engineer escalations.

Template

Role: Principal Business Intelligence Support and Enablement Lead specializing in federated analytics operations.

Context

  • Enterprise Environment: {{enterprise_name}}
  • BI and Analytics Technology Stack: {{bi_platform_stack}}
  • End-User Audience Personas: {{user_persona_segments}}
  • Recurring Incident Categories: {{common_incident_patterns}}
  • Data Governance Classification: {{data_governance_tier}}
  • Existing Self-Service Knowledge Assets: {{deflection_resource_library}}

Task

Develop a structured analytics support and deflection framework that guides business users through self-service diagnostics, triages data pipeline and dashboard defects, and routes complex modeling bugs to designated data engineering leads.

Method

  1. Review the tools in {{bi_platform_stack}} to establish failure domains covering ingestion, semantic model, report visualization, and user permissions.
  2. Map {{user_persona_segments}} against technical capability tiers to calibrate intake form complexity and diagnostic guidance.
  3. Design a pre-submission deflection workflow linking {{common_incident_patterns}} to direct assets in {{deflection_resource_library}}.
  4. Define a defect classification matrix separating data quality errors, report rendering bugs, metric calculation discrepancies, and access requests.
  5. Integrate {{data_governance_tier}} protocols to handle access requests for restricted data products.
  6. Formulate clear escalation gates separating Tier 1 BI support, Tier 2 Analytics Engineers, and Tier 3 Data Platform Engineers.
  7. Establish diagnostic data collection requirements (SQL session IDs, report URLs, query execution times) for escalated tickets.
  8. Define closure criteria including user validation sign-off and knowledge base update triggers.

Constraints

  • MUST mandate that all data access tickets pass through formal governance validation before technical fulfillment.
  • MUST NOT escalate dashboard visual anomalies to platform data engineers without verified upstream pipeline failures.
  • The deflection step must require no more than two clicks or 60 seconds from the end user.
  • The framework must maintain separate SLA tracking for business-critical reporting cycles like financial close.

Output format

  • Section 1: Self-Service Deflection Journey (Decision tree from initial issue to recommended self-help link)
  • Section 2: Issue Categorization and Priority Matrix (Markdown table: Issue Type, Severity, SLA Target)
  • Section 3: Tiered Handoff Protocols (Tier 1 Support to Tier 3 Platform routing checklist)
  • Section 4: Governance and Verification Checklist (Steps required before ticket closure)
  • Total length: maximum 550 words.

Self-review

  • Verify that deflection links directly address the listed common incident patterns.
  • Confirm that governance checks are explicitly integrated into data access workflows.
  • Check that handoff criteria between BI analysts and data platform engineers are distinct and measurable.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

support-success
support-general
research-productivity-operations
analytics
business-intelligence
data-support