Build a troubleshooting decision tree from your own rules with AI
A troubleshooting tree should tell the person on the help desk when to stop as clearly as what to try. Left to itself, AI will happily fill every gap with "clear the cookies and try again".
Example output
A login troubleshooting tree with real stop points
Fictional help desk procedure: every step carries its rule number, and a locked account stops and escalates.
Read the prompt
Build a troubleshooting decision tree from these approved rules only.
For each node, include the question, allowed action, source rule ID and
stop/escalation boundary. Preserve missing-source and failed-check paths.
Leave unsupported cases unresolved with a focused question.
Do not invent resets, external writes, integrations or account controls.
Provide editable source/file, readable path list and a few cases that
should expose a missing or incorrect branch.What you'll make
a yes/no troubleshooting tree in which every question and action carries the number of the rule it comes from, including the points where the person must stop or escalate.
What you'll need
your current support rules or procedure, numbered, and your work AI account (ChatGPT, Claude, Copilot or Gemini). About 20 minutes.
1. Number the rules, then ask for the tree
Write or paste your rules and give each a number: R1, R2 and so on. Include what the person may do, what they must never do, and when to stop and pass it on. The “never” and “stop” rules matter most, because those are the ones AI tends to smooth away.
Turn these numbered rules into a yes/no troubleshooting tree: [rules]
Each question and each action must show the rule number it comes from.
Use only actions the rules allow. Where the rules say stop or escalate, end that branch there.
If a situation isn't covered by any rule, end the branch with "Not covered: ask [owner]".
Show the tree as an indented text list I can read on a phone.[rules] is your numbered list; [owner] is the person or team who decides cases the rules don’t cover.
Why this works: a rule number on every node makes an invented step easy to spot, because it has no number to show.
What you should see: an indented list of questions with Yes and No branches, each line ending in a rule number, and at least one branch ending in a stop or escalation.
2. Check each branch against the rules
Read every branch from top to bottom. For each action, find its rule. Then pick two awkward cases, such as the one where the rules say stop, and one the rules don’t cover, and ask the AI to walk them through the tree.
Walk [case] through the tree. At each step, name the question, the answer and the rule number.
Point out any action that isn't in the rules, and any branch that carries on after a rule says stop.[case] is a short description, such as “customer’s login page says Account locked”.
Why this works: following a real case exposes the branch where the tree quietly keeps going.
What you should see: a step-by-step path that ends where the rules say it should.
3. Turn it into a diagram if people need one
Once the text tree is right, ask for it as a flowchart. Claude can make a diagram as an artifact beside the chat; ChatGPT and Gemini can produce diagram code or an image you can save. Check the diagram against the text list, branch by branch, because a redraw can drop a line.
Why this works: fixing logic in a text list is quick. Fixing it in a diagram means redrawing.
What you should see: the same questions, branches and rule numbers as the text tree, nothing added.
Check the result
- Every action has a rule number, and that rule really allows the action.
- Every “stop” or “escalate” rule ends a branch. Nothing follows it.
- Anything the rules don’t cover ends with “Not covered”, not a guess.
- The two awkward cases end where your rules say they should.
The usual failure: the AI adds a helpful-sounding step that isn’t in your rules, often on the branch where the rules say stop. “Account locked” becomes “unlock the account and send a reset link”. Spot it by looking for any line without a rule number, or a stop branch that continues.
Branch [branch] continues after a stop, but rule [rule number] says [rule text].
End that branch at the stop or escalation, remove any action not in the rules,
and show me the corrected branch with its rule numbers.[branch] is the question where it went wrong; [rule number] and [rule text] are the rule it broke.
Worked example: a customer who can’t log in
Fictional example. A help desk lead turns the portal login procedure into a tree for new starters.
R1 Check the email is registered. If not, ask for the email used at sign-up.
R2 If registered, send a reset link from the admin console.
R3 No reset email within 10 minutes: ask them to check spam, then resend once.
R4 Login page says "Account locked": stop. Escalate to tier 2. Never unlock it yourself.
R5 Still failing after one resend, or no registered email found: escalate to tier 2
with the email address and the exact error text.First tree (wrong): under “Does the page say Account locked?”, the Yes branch reads “Unlock the account in the admin console, then send a reset link (R2)”. It also adds “Ask them to clear cookies and reinstall the app” with no rule number.
Repair: the repair prompt above, with the Account locked question as the branch and R4 as the rule.
Repaired tree:
Is the email registered? (R1)
No → Ask for the sign-up email. Still not found → escalate to tier 2 (R5)
Yes → Does the page say "Account locked"? (R4)
Yes → STOP. Escalate to tier 2. Don't unlock. (R4)
No → Send a reset link (R2) → Did it arrive within 10 minutes? (R3)
Yes → Done
No → Check spam, resend once (R3) → still nothing → escalate (R5)- The unlock step was the dangerous one. It contradicted the one rule that said “never”, and it sounded the most helpful.
- “Clear cookies and reinstall” had no rule number. That alone was enough to cut it.
- The escalation branches carry the email and the error text (R5), so tier 2 doesn’t have to ask again.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Keep the rule version with the tree
When the procedure changes, a branch may change with it. Put the procedure’s version or date at the top of the tree, and when the procedure is revised, ask the AI which branches use the changed rules. Don’t let a polished old tree quietly stay in use.
These rules changed: [changed rules]. List every branch in the tree that uses them,
and show each one before and after the change.Test the cases nobody wrote down
Ask the AI for five situations your rules don’t cover, such as “the customer has two accounts” or “the reset email goes to an old address”. Each should end at “Not covered”. If you find yourself answering them, you’ve found a missing rule. Add it to the procedure first, then the tree.
Click-through trees are a separate build
A tree people click through, answering each question in turn, is a small tool rather than a document. Get the text tree right first, then see clickable prototypes. Test every button: a diagram can be right while a button goes to the wrong step.