Troubleshooting Decision Tree Template â€” Oneâ€‘Shot Prompt

A single-copy prompt that produces production-ready, stepwise troubleshooting trees with exact commands, expected results, and clear escalation criteria for SaaS/ecommerce suppo...

What You'll Get

A single, copy-paste prompt template with named input slots (high_level_symptom, platform_environment, product details, known failure modes, logs/screenshots, allowed remediation actions).

Output spec: numbered decision tree (1.0, 1.1...), concise customer-facing â€˜collect these detailsâ€™ intake script, exact commands/API calls/SQL queries, expected outputs, interpretation guidance, and an escalation matrix with severity mapping.

Safety and process guardrails: steps marked for data-risk or service impact, minimum privilege notes, explicit assumptions block, and clarifying-question behavior when inputs are missing.

Appendix-ready commands section and ready-to-distribute messaging templates for resolved/partial resolution customer communications.

How to Use

1Paste the prompt into ChatGPT and populate required slots: high_level_symptom, platform_environment, audience, document_type, tone, required_sections, and technical inputs (product/system, known failure modes, recent logs/screenshots text, allowed remediation actions).

2If any technical inputs are missing, answer the promptâ€™s clarifying questions first; the template will not proceed until critical details are provided.

3Use the generated decision tree as: (a) an agent runbook for live diagnosis, (b) a KB article (copy the â€˜collect these detailsâ€™ and numbered nodes), or (c) a chatbot canonical responseâ€”remove any client-specific secrets before publishing.

4For automation: extract the appendix commands into scripts or monitoring runbooks, and map escalation triggers to your paging/alerting tooling according to the severity mapping provided.

Make the first checks ultra-fast and non-invasive

Design the top-level nodes to surface reproducible, customer-provided evidence (timestamps, request IDs, curl output) before any host-level or restart steps. This reduces unnecessary escalations and preserves logs for later forensic analysis.

Works Best With

Best used when you can supply targeted technical inputs and allowed remediation scope

Provide a precise high-level symptom (e.g., 'API returns 502 for checkout path during peak traffic')

Include platform/environment details (Kubernetes cluster, namespace, ingress type) and service names

Attach or paste a sample request ID with ingress and pod logs around the failure timestamp

State clearly which remediation actions support may perform (restart/scale/DB queries) to avoid delays

If a deploy or config change occurred near the incident, include its timestamp and CI/CD run ID

Prompt Template


## Goal
- Produce a production-ready, stepwise troubleshooting decision tree that diagnoses and resolves the issue. The artifact will be a clear operational deliverable used by support engineers and on-call teams to reproduce checks, run prioritized diagnostics, execute exact commands/steps, interpret expected results, and apply escalation criteria with mapped severities.

## Inputs
- Context: {{meeting_context}}
- Stakeholders / audience: {{audience}}
- Document type: {{document_type}}
- Desired tone: {{tone}}
- Required sections to include in the final artifact: {{required_sections}}
- Technical inputs the generator should assume or request during clarification: high-level symptom ({{high_level_symptom}}), platform/environment ({{platform_environment}}), product/system details, known failure modes, recent logs/screenshots text, and allowed remediation actions.

If any of the technical inputs above are missing, the prompt in the next section must ask targeted clarifying questions before producing the decision tree.

## Prompt
You are a senior support engineer and troubleshooting author. Using the inputs below, produce a single, copy-paste troubleshooting decision tree deliverable that support agents can use verbatim.

- Target audience: {{audience}}
- Deliverable type: {{document_type}}
- Tone: {{tone}}
- Meeting/context: {{meeting_context}}
- Required sections: {{required_sections}}
- Issue to diagnose: "{{high_level_symptom}}"
- Platform / environment: "{{platform_environment}}"

Task requirements (must be followed exactly):
1. If any of the technical inputs (product/system, known failure modes, recent logs/screenshots text, allowed actions) are not provided, first output a concise list of clarifying questions to collect those details, then stop. Do not proceed until answers are supplied.
2. When inputs are complete, output a stepwise decision tree that includes:
   - A short summary of the symptom and environment (1-2 sentences).
   - "Collect these details" script: a compact customer-facing checklist of required data points to reproduce the problem (exact fields to capture, e.g., timestamps, full log snippets, config values, browser/OS versions, commands run, screenshots with filenames).
   - A numbered decision tree with nodes formatted as: Condition â†’ Exact actionable check (including exact CLI commands, UI steps, API calls, or SQL queries where applicable) â†’ Expected result/output â†’ If expected result differs, next node reference or corrective action.
   - Prioritize checks from fastest/least intrusive to slowest/more invasive; mark steps that require customer permission or elevated privileges.
   - For each actionable step include: Estimated time to run, required privileges, and any data risk (e.g., may restart service, may clear cache).
   - Interpretation guidance: For each possible observed output, include concise diagnostic inference (1 line) and the next recommended action.
   - A clear escalation matrix with severity mapping (e.g., Sev-1/Critical â†’ criteria, SLAs, who to page, communication template), and explicit escalation triggers (e.g., failed recovery after X steps, data loss, security indicators).
   - "When to escalate" decision rule: after which step(s), with counters/timeouts and exact evidence required to escalate.
   - A minimal post-resolution checklist: verification steps and customer message templates for successful resolution and for partial mitigations.
3. Format the decision tree so it is machine- and human-readable: use numbered nodes, consistent node IDs (e.g., 1.0, 1.1, 2.0), and short labels. Include a one-line summary at the top and an appendix listing exact commands/queries used.
4. Keep assumptions explicit: list which facts you assumed about the environment and which must be confirmed.
5. Produce outputs ready for direct distribution to stakeholders and on-call engineers (no placeholders left in the final output).

Return only the finished troubleshooting decision tree and ancillary sections specified above. Use concise, crisp language and avoid unnecessary prose.

## Output Format
Support: Diagnosis questions â†’ Response draft â†’ Next steps

- Diagnosis questions: compact "collect these details" script designed for support intake.
- Response draft: the decision tree and interpretation guidance, including exact commands/steps and expected results.
- Next steps: prioritized corrective actions, escalation criteria with severity mapping, and post-resolution checklist.

## Guardrails
- Separate facts vs assumptions: include an explicit "Assumptions" block listing any assumed versions, configs, permissions, or missing inputs.
- Do not claim policy or security conclusions without citing the exact evidence from logs or config lines provided in input.
- Mark any step that risks data loss or service interruption and require explicit customer consent before proceeding.
- If commands require elevated privileges, state the minimum required role.
- Do not include credentials, secrets, or personal data in outputs.

## Examples
Mini excerpt (decision â†’ check â†’ expected â†’ next):
1.0 Symptom: Service returns 502 on API calls
- Collect: timestamp, full request ID header, curl -v output
- 1.1 Check: curl --header "x-request-id: <id>" -i https://api.example.com/health
  - Expected: HTTP/1.1 200 OK with JSON {"status":"ok"}
  - If 502 observed â†’ 1.2
- 1.2 Check: On app host run sudo journalctl -u api.service -n 200 | grep -i error
  - Expected: no repeated "connection refused" errors
  - If repeated connection refused â†’ infer: upstream dependency down â†’ escalate to backend team (Sev-2) after 3 failed attempts within 10 minutes.

Variables

Usage Notes

Not for

â€¢ Legal/regulatory determinations or final compliance judgments (e.g., HIPAA/PCI certification).

â€¢ Automated destructive remediation without documented customer consent (data-deleting scripts, DB restores).

â€¢ Replacing architecture/security reviewsâ€”use only for operational troubleshooting and escalation guidance.

Do not include

â€¢ Credentials, secrets, or any PII from customers; the template will request log excerpts or redacted snippets only.

â€¢ Unverifiable claims about past incident outcomes or productivity gains (do not assert metrics).

â€¢ Vague instructionsâ€”every step must include exact commands/steps, expected output, and next-node references.

Troubleshooting Decision Tree Template â€” Oneâ€‘Shot Prompt

One-shot prompt template that generates machine- and human-readable decision trees: reproducible checks, prioritized diagnostics, exact CLI/UI/API steps, interpretation guidance, and an explicit escalation matrix for support managers and senior agents.

Turn this into a working asset in minutes.

Import into Workspace to auto-fill variables, adapt output style, and iterate with OctiAI's prompt editor.

Auto-fill & personalize from your inputs

AI-assisted edits: tone, structure, constraints

Attach context so outputs stay consistent

Iterate and save versions

What you'll get

Output format

Markdown

Best used when

When working on template or detailed.

Avoid when

Legal/regulatory determinations or final compliance judgments (e.g., HIPAA/PCI certification).

Made for

What to fill in

Use the guidance below to complete each placeholder with the right level of detail.

Meeting Context