General support
AuraScore 81/100

Academic Research Computing Support Triage Framework

Build a tiered support triage and escalation framework for university research computing and high-performance clusters.

Use this template when centralizing support operations for academic computing clusters, lab grants, and multi-department research inquiries. It structures clear escalation pathways between frontline help desks, systems engineers, and research data specialists.

Template

Role: Senior Academic Computing Support Director with 15+ years in higher education research enablement.

Context

  • Host Institution: {{institution_name}}
  • Supported Academic Fields: {{research_disciplines}}
  • Volume and Demand Profile: {{ticket_volume_profile}}
  • Active Support Ingress Channels: {{support_channel_mix}}
  • Available Tier Resources: {{escalation_tier_specs}}
  • Service Level Expectations: {{service_level_targets}}

Task

Design an operational support triage and routing framework that categorizes incoming researcher requests, assigns appropriate severity tiers, and dictates handoff protocols between general support staff, HPC system administrators, and research software consultants to guarantee adherence to academic deadlines.

Method

  1. Review the operational profile across {{institution_name}} and map incoming ticket types across {{research_disciplines}} to baseline technical competencies.
  2. Establish an intake categorization taxonomy dividing queries into infrastructure provisioning, software compilation, data management, and compute allocation.
  3. Define a 4-tier severity matrix pairing urgent research deadlines with cluster health impacts.
  4. Draft intake protocol criteria for {{support_channel_mix}} to capture necessary job IDs, node specifications, and log files at initial touchpoint.
  5. Formalize horizontal and vertical escalation paths across {{escalation_tier_specs}} with explicit routing rules and ownership thresholds.
  6. Align specific response and resolution windows to meet {{service_level_targets}} for each categorized tier.
  7. Formulate a handoff protocol specifying exact diagnostic documentation required before escalation.
  8. Establish exception-handling procedures for urgent grant submission deadlines and catastrophic cluster outages.

Constraints

  • MUST define explicit ownership transfer gates so no ticket remains in unassigned triage limbo.
  • MUST NOT require researcher end-users to provide non-standard system diagnostics without guided self-service scripts.
  • Workflows must balance general desk resolution speed with specialized research software engineering resources.
  • Every escalation tier must specify a maximum allowable queue dwell time.

Output format

  • Section 1: Triage Taxonomy and Severity Matrix (Markdown table: Severity, Trigger Criteria, Scope)
  • Section 2: Tiered Escalation Routing Map (Tier 0 to Tier 3 operational definitions and ownership boundaries)
  • Section 3: Ingress and Diagnostic Protocol (Required intake checklist per channel)
  • Section 4: SLA Targets and Dwell Thresholds (Markdown table: Priority, First Response, Resolution Target)
  • Total length: under 600 words across all sections.

Self-review

  • Confirm all 6 variables are seamlessly integrated into the operational logic.
  • Verify that escalation boundaries between general support and HPC engineering are distinct.
  • Ensure SLA commitments directly map to the defined ticket severity levels.
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
support
research
education