How to Build a Flowchart Template | Patterns by Process Type and a Five-Step Method
Published:
Last Updated:
Category:
Published:
Last Updated:
Category:
Authors: Shusaku Yosa
You sit down to draw a flowchart and stall in front of the blank page. Knowing what the symbols mean is one thing; knowing where to start and how to structure it is another. In fact, the skeleton of a process flow tends to follow a settled pattern depending on the type of work. This article covers those patterns, a build method, and what to watch for when applying a pattern to your own situation.
Business processes come together faster when you adapt an existing pattern than when you think from zero. Most processes are built from a limited set of combinations: request and approval, receive and respond, order and deliver.
Speed is not the only benefit. Closing off the common gaps in advance matters more. On an approval flow, the route back after a rejection; on enquiry handling, what happens when the first response does not resolve it. These are easy to forget when thinking alone, but a pattern that includes them leaves no room to skip them.
A pattern is only a starting point, though. Wherever it differs from how your organisation actually works, rewrite it. Explaining the work to fit the pattern puts the diagram and reality out of step.
For internal proposals, expense claims, leave requests — anything where a request goes up for approval. The most frequently used pattern, and the simplest in structure.
Prepare the request → check the contents → approval decision → execute if approved, return if rejected → close
The third is the usual gap. Things stalling because an approver is out happens without fail, and it is almost never written into the flow.
For customer enquiries, internal help desks, complaint handling. Because there is an external touchpoint, it carries more branches than an approval flow.
Receive the enquiry → classify it → decide whether a first-line answer is possible → answer if it is, hand to the responsible team if not → confirm resolution → record
In this pattern, stating the definition of done matters especially. Is it complete when the reply is sent, or when the other party confirms the problem is solved? Leave that vague and cases you believed were closed come back later.
The full run from quotation through delivery to invoicing. Many departments are involved, and documents move between them.
Receive the enquiry → prepare the quotation → internal approval → submit the quotation → win or lose decision → if won, place orders and deliver → acceptance → invoice
This flow tends to get long, so splitting it at the quotation stage is practical: one diagram up to submitting the quotation, another from winning onward. Force it onto one page and neither half reads well.
For content production, preparing materials, advertising creative — work where something is made and then put through review.
Receive the brief → confirm the requirements → produce → internal check → revise → requester's review → revise → deliver
The critical question in this pattern is where the revision loop stops. Draw an unlimited return arrow and the diagram is technically accurate but gives the process no brake. Put in a limit, whether a number of rounds or a date.
Once you have chosen a pattern, proceed like this.
The order of the second step matters. Try to include exceptions from the outset and the branches multiply until the overall shape disappears.
Use a pattern as-is and steps your organisation does not actually perform can remain in the diagram. A chart showing work that does not exist only confuses the reader. Check each one against what actually happens.
While adapting a pattern, the way things ought to be tends to creep in. Decide first whether you are mapping the current state or drawing the improved version. A chart that mixes both serves neither purpose.
The shape tools in Excel and PowerPoint will do the job. The flowchart symbols are all there, and you can start without adopting anything new.
The drawback is that adding one symbol means redrawing the lines. They do not suit diagrams you update frequently.
As a guide: if you revise only a few times a year, Excel or PowerPoint is plenty. For processes that change often, a dedicated drawing tool where adding and rearranging symbols is easy is worth considering.
Most cases can be expressed as a combination. Recruitment, for instance, is the enquiry-handling pattern (receiving applications) combined with the approval pattern (pass or fail decisions). Break it down first, then map the pieces.
What fits on a single A4 page or slide is the ceiling. If it does not fit, split by phase. For order-to-invoice, split at the quotation; for production, at the point requirements are settled.
With five or more branches, a flowchart may not be the right form. A decision table, mapping conditions to outcomes in a grid, often organises the same material with fewer gaps.
A diagram with no occasion to be looked at will always be neglected. Use it when explaining the work to a new joiner, when handing over, when considering improvements. Decide the use before you build it and the question of detail also gets easier.
What a flowchart can express is the order of steps and the branches. It cannot express who does what by when, or when the whole thing finishes. Once the sequence is settled, the remaining work is turning it into dates and owners.
Once you move past designing the execution flow of a campaign and into managing schedule against budget and results, a chart alone cannot keep up. Xtrategy manages campaign schedules alongside budget and KPIs on a single screen.
A pattern is a device for saving thinking time, not an answer. Pick the pattern closest to your own process and draw one line through the normal path. Adding branches from there gets you finished far faster than starting from a blank page.
Effort, man-hour, and man-day sit at different levels: effort is the concept, person-hours and person-days are the units...
What a person-day means and how to convert it. Covers why one person-day is not always eight hours, the conversion table...
What a PMO does and how it differs from a PM, organised around who holds responsibility. Covers the supportive, controll...
