Decision Chart — What It Is and How to Make One
A decision chart turns a decision that people keep getting wrong into a chart anyone can follow. It lists the questions to ask, the answers available at each question, and the outcome that each path leads to. Nothing is left to interpretation, so two people with the same inputs reach the same conclusion.
→ Make a decision chart now — free, no signup
What Goes Into a Decision Chart
Every decision chart is built from three parts:
- Questions — the things you need to know, expressed so that anyone can answer them without specialist knowledge.
- Answers — the finite set of options at each question. If an answer needs a judgement call, split it into two clearer questions instead.
- Outcomes — the end states. A good outcome tells the reader what to do, not just what category they landed in.
The order of the questions matters more than most people expect. Ask the question that eliminates the most outcomes first, and most readers reach their answer in two or three steps instead of six.
Decision Chart vs Flowchart vs Decision Tree
| Decision chart | Flowchart | Decision tree | |
|---|---|---|---|
| Shape | Branching, one entry point | Can loop and rejoin | Branching, one entry point |
| Best for | Choosing between outcomes | Documenting a process | Choosing between outcomes |
| Reader effort | Follow your own branch | Trace the whole diagram | Follow your own branch |
| Typical use | Policy, triage, eligibility | Workflow, handoffs | Policy, triage, eligibility |
In practice, "decision chart" and "decision tree" describe the same structure. Use a flowchart when steps loop back or run in parallel; use a decision chart when the goal is to land on one outcome. Read the full comparison →
Static Charts Get Stale — Interactive Ones Don't
Most decision charts are drawn once in a slide deck, exported as an image, and pasted into a wiki. Six months later the policy has changed, the image has not, and nobody can find the source file.
An interactive chart avoids that failure mode:
- The source is plain text, so a change is a one-line edit that anybody can review.
- Every place the chart is embedded updates the moment you publish.
- Readers answer questions rather than tracing lines, so they cannot follow the wrong branch by accident.
Build a Decision Chart in Four Steps
- Write the outcomes first. If you cannot list the possible end states, the decision is not ready to chart.
- Work backwards to the questions. For each outcome, ask what has to be true for a reader to land there.
- Order the questions by how much they eliminate. The most discriminating question goes first.
- Walk every path. Run the chart end to end for each outcome and confirm the result is the one you intended.
In DrawDecisionTree the chart is written like this:
Q1: Is the customer on a paid plan?
- Yes -> Q2
- No -> SELF_SERVE
Q2: Is the issue blocking their work?
- Yes -> ESCALATE
- No -> QUEUE
SELF_SERVE: Point them to the help centre.
ESCALATE: Page the on-call engineer now.
QUEUE: Log a normal-priority ticket.
That text becomes a diagram, a path view, and a clickable wizard at the same time. Read the full syntax reference →
Decision Chart Templates
You do not have to start from a blank page. The public directory has ready-made charts for IT troubleshooting, incident severity, HR onboarding, discount approval, and dozens of other recurring decisions — open any of them, copy the text, and edit it for your own team.
→ Browse decision chart templates
Where Teams Use Decision Charts
- Support — triage charts that decide priority and routing without a supervisor.
- HR — leave classification and policy eligibility, answered consistently every time.
- Finance — approval thresholds, so requesters know who signs before they ask.
- Engineering — on-call escalation and severity classification during an incident.
- Sales — discount approval and lead qualification with no back-and-forth.
→ Read: when to use a decision tree · → Read: what is a decision tree?