A flowchart is just a sentence with the "and then" and "unless" made visible instead of buried in paragraph three of a process document. If you can describe a process out loud, you already have everything you need to draw one — the shapes are just a way to keep the description honest.
You need four shapes, not forty
Formal flowchart notation has dozens of symbols for things like "predefined process" and "manual input." For mapping an actual business process, you need a start/end shape, a step (a box), a decision (a diamond), and an arrow. That's it. Adding more shapes than that usually adds ceremony, not clarity — the value of a flowchart is that anyone can read it without a legend.
Every diamond needs every exit labeled
The single most common flowchart mistake is a decision diamond with an unlabeled arrow leaving it. "Approved?" with two lines going out, one of them unmarked, forces the reader to guess which path is yes and which is no — exactly the ambiguity the flowchart was supposed to remove. Label every branch out of every decision, every time, with no exceptions.
Draw the unhappy path, not just the happy one
A flowchart that only shows the process when everything goes right is a wish, not a map. The actual value of mapping a process is seeing what happens when an approval is rejected, a payment fails, or a step times out — those branches are usually where the real confusion and rework live, and they're exactly what gets skipped when someone describes a process verbally.
A flowchart is a conversation starter, not a finished spec
The first version of any process flowchart is wrong in some small way, and that's fine — its job is to surface the disagreement between "how we think the process works" and "how it actually works" fast, in a shared visual, instead of slowly, across several confused meetings. Treat the first draft as a draft, put it in front of the people who actually run the process, and let them correct it.