Extract the issue and attempted steps from a support conversation
Build a factual troubleshooting state from a conversation without merging different attempts or inventing results
7 min setupTested with:ChatGPTReviewed: 2026-08-28
1
Add your context
Your text stays in this browser. AILesson Prompts does not send it to a model or server.
2
Your prompt
Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt
Extract the troubleshooting state faithfully from the supplied support conversation.
Full conversation, speakers, timestamps, attachments, corrections, redactions, and channel changes:
[conversation]
Product, version, incidents, prior cases, account facts, scope, and terms:
[context]
Fields, confidence, privacy, escalation signals, and target audience or system:
[schema]
Separate customer report, support statement, system evidence, attachment evidence, and inference. Identify primary symptom, expected versus observed behavior, onset and frequency, business impact, environment, reproduction conditions, error text, affected scope, and current state. List every attempted step chronologically with actor, exact action, prerequisites, timestamp, observed result, whether the result was verified, and whether the step is safe to repeat. Do not collapse similar attempts, assume completion, infer causation, or treat no reply as success. Preserve contradictions and corrections. Mark facts unknown rather than filling standard fields. Redact secrets and unnecessary personal data; flag safety, security, privacy, financial, legal, or accessibility escalation signals. End with duplicate questions to avoid, the smallest necessary clarification set, and a handoff-ready next-action boundary without prescribing an unsupported fix.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.
From input to outcome
A worked example
See how concrete context turns this recipe into a usable result
Actual input
Support conversation
09:02 Nora: Since yesterday, Desktop App sync says Paused after our password changed. Windows 11, app 4.2.1. Internet works. 09:05 Support: Please restart. 09:12 Nora: Restarted; still Paused. 09:18 Support: Clear cache. 09:20 Nora: I have unsynced drafts, so I did not clear it. 09:24 Nora uploads screenshot showing Paused, no error. 09:40 Support: Try Reauthenticate under Settings > Accounts > Workspace. 10:03 Nora: Windows sign-in opened, I completed it, then saw E401. 10:05 Nora: Correction—the app is 4.2.0, not 4.2.1. No password or private draft attached.
Case context
Approved incident INC-882 concerns blank PDF charts, unrelated unless evidence says otherwise. Approved 4.2 procedure warns not to clear cache or reinstall when unsynced drafts exist. E401 after reauthentication requires escalation after one retry, but no retry has yet been requested in this conversation.
Primary symptom — high: sync remains Paused after a company password change (Nora, 09:02); expected state is not explicitly stated, though successful sync is implied and should remain an inference. Onset: “since yesterday,” exact date/time unknown. Impact: unsynced drafts exist; quantity and business consequence unknown.
Environment — high: Windows 11, Desktop App 4.2.0, corrected at 10:05. The earlier 4.2.1 statement is superseded, not silently merged. Internet reported working at 09:02, not independently verified.
Attempts
Restart requested 09:05, completed by Nora before 09:12; observed result: still Paused. Safe to record as failed.
Clear cache suggested 09:18 but explicitly not performed at 09:20 because unsynced drafts exist. Do not record it as attempted or request it again; approved guidance identifies data-loss risk.
Reauthenticate requested 09:40; Nora opened Windows sign-in and completed it before 10:03; observed result: E401. Customer report, not system log.
Evidence: screenshot at 09:24 shows Paused and no visible error; attachment contents beyond that are unknown. INC-882 is not linked to this symptom.
Unknowns: exact onset, workspace identifier, whether all workspaces/users are affected, E401 timestamp precision, and whether an approved single retry has occurred. Next boundary: Tier 2 should preserve drafts, avoid cache clearing/reinstall, confirm affected scope, and decide whether to request the one approved reauthentication retry or escalate. Do not ask again for OS, corrected app version, internet status, restart, screenshot, or whether cache was cleared.
Why this works
1
Chronological attempt records prevent customers from repeating steps that already failed.
2
Evidence-type labels keep diagnostic inference from becoming a false technical fact.
Check the result
Is every attempt tied to an actor, action, time, and observed result?
Are report, evidence, and inference kept separate?
Are known answers protected from duplicate questioning?