Recommended resources
The freely available resources this lesson will direct you to.
Hello! In the previous lesson, you broke a manual request-routing workflow into its trigger, inputs, rules, actions, and outputs. You also set a boundary: the work ends when a request has a recorded assignment or follow-up status, not when the customer’s problem is solved.
Today you’ll turn that written account into a flowchart. The aim is to make the work and its choices visible: someone looking at the chart should be able to follow both a routine request and one that needs a reviewer.
Give actions and decisions different shapes
A flowchart is useful because it separates doing something from deciding what to do next. You need only four visual conventions to begin:
| Shape or mark | Use it for | Example label |
|---|---|---|
| Oval or rounded rectangle | The start or end of the work you are mapping | “New form submitted” |
| Rectangle | An action someone performs | “Record assigned queue” |
| Diamond | A question whose answer changes the route | “Description present?” |
| Connecting line with an arrowhead | The direction to follow on the chart | Label each line leaving a diamond, such as “Yes” or “No” |
Put an action in a rectangle and a question in a diamond. “Check description” belongs in a rectangle because it describes work. “Is a description present?” belongs in a diamond because its answers lead to different actions.
Watch the essential symbols and a short example in Cody Baldwin’s Introduction to Process Flow Charts (Lean Six Sigma):
Introduction to Process Flow Charts (Lean Six Sigma)
Cody Baldwin introduces the basic shapes, then uses a shipment process to show how a failed check changes the route.
Watch the core symbols, focusing on how a decision differs from a task. Then watch the shipment example; notice what happens when the accuracy check fails, rather than following only the successful route.
The shapes are a shared reading aid, not a reason to make a chart elaborate. For this lesson, a pen and paper or a simple drawing tool is enough.
Scope the chart before drawing it
The American Society for Quality’s guide, What Is a Flowchart? Process Flow Diagrams & Maps, gives a practical drafting method. It begins with the process boundary, has you arrange activities before connecting them, and ends with a check against how the work is actually done.
What is a Flowchart? Process Flow Diagrams & Maps - ASQ
Read the American Society for Quality’s “Flowchart Basic Procedure” for a method you can use without specialized software.
In “Flowchart Basic Procedure,” begin with the paragraph about choosing whatever charting tools work for your team. Read the drafting guidance through the final review checklist. Pay particular attention to setting start and end boundaries before arranging activities, and to walking through the finished chart with someone who knows the process.
For our request workflow, write the boundary at the top of your page: from one form submission to a recorded routing disposition. A routing disposition tells the next person whether the request has been assigned to a support queue, needs missing information, or needs intake review because its topic is unclear. Do not add investigation or resolution steps; those belong to work beyond this chart.
Before placing shapes, list the actions and questions from the manual rules. Put the missing-information check first. Only a request with both a reply address and a description proceeds to topic-based routing. Within topic-based routing, check for billing, then technical issues; for a technical issue, check whether it is written in French before selecting a technical queue. If the topic is unclear, an intake reviewer receives it.
Study what a decision branch must show
The supplied product-development chart offers a compact visual example. Its diamonds ask whether market research is complete, whether the product aligns with goals, and whether a budget is approved. At each diamond, the Yes and No labels tell the reader which route to follow.
Look closely at the No branch beside budget approval: it returns to “Make a budget.” That loop says the budget is revised and checked again within the pictured process. A branch does not have to loop back, though. In our request-routing workflow, a missing description produces a recorded follow-up disposition. If the customer later supplies more information, that may start further work, but the current routing attempt has already reached its stated end. Drawing an automatic loop here would quietly change the process we described.
Short labels also have limits. A diamond saying “Is the budget approved?” shows where a decision occurs, but not who can approve it or by what criteria. Likewise, our chart can show “Technical topic?” while the written rules still need to explain how staff handle borderline descriptions. A flowchart exposes a decision; it does not settle an ambiguous rule by itself.
Draw the request-routing flowchart
You can build this chart on paper as you read. Allow about ten minutes to place and connect the shapes; neatness matters less than making every branch traceable.
-
Mark the boundary. Put an oval labelled “New form submitted” near the top. Near the bottom, put an oval labelled “Routing disposition recorded.” These are the start and end of this workflow.
-
Place the first action and question. Below the start, put a rectangle labelled “Inspect reply address and description.” Below it, put a diamond labelled “Are both present?” Connect them in that order. The rectangle represents the staff member’s check; the diamond represents the result that changes what happens next.
-
Draw the incomplete-request route. Label one exit from the diamond No. Connect it to a rectangle labelled “Mark needs follow-up; assign intake reviewer.” Connect that rectangle to the end oval. This path must not pass through a support-queue assignment.
-
Draw the complete-request route. Label the other exit Yes. Connect it to a rectangle labelled “Read description; identify topic and language,” then to a diamond labelled “Billing topic?” Its Yes branch leads to a rectangle labelled “Assign billing team.”
-
Continue the non-billing branch. From No at “Billing topic?”, connect to a diamond labelled “Technical topic?” Its No branch leads to a rectangle labelled “Mark needs review; assign intake reviewer.” Its Yes branch leads to a diamond labelled “Written in French?” The French Yes branch leads to “Assign French technical-support queue”; No leads to “Assign general technical-support queue.”
-
Show what gets recorded. After each of the billing and technical-queue assignment rectangles, connect to a rectangle labelled “Save assigned status and queue in request log.” Then connect it to the end oval. Also connect the two reviewer-route rectangles to the end oval: their labels should make clear that a follow-up or review status is recorded, rather than an ordinary support assignment.
You should now be able to enter at the top and reach an end by following either answer at every diamond. You may use separate, identically labelled end ovals if bringing all the lines to one oval makes the page hard to read. What matters is that each route ends with an observable record.
This chart deliberately puts “Technical topic?” before “Written in French?” A French billing request therefore goes to billing, not to technical support. The order makes a business rule visible that might be missed in a loose list of tasks.
Walk the chart as if you were handling real records
A drawing is not finished when all its boxes are connected. Test whether its routes match the process you intended to describe.
First, follow a request with a reply address and a French description of an application that will not open. Both required fields are present; it is not a billing topic; it is technical and written in French. The route should finish with an assigned status and the French technical-support queue saved in the request log.
Next, follow a request with a reply address but no description. It should leave the chart after being marked needs follow-up and assigned to an intake reviewer. If your line takes it through “Technical topic?”, the chart is asking staff to classify information they do not have.
Finally, consider a request with both fields present but a description whose topic staff cannot identify. It should reach the intake reviewer with needs review recorded. This differs from the missing-description route: the information exists, but a routing judgment remains unresolved.
When reviewing a chart of an actual workplace process, ask someone who performs the work to trace examples like these. Check especially for unlabeled exits, routes that stop without a recorded result, and loops that imply work happens again when it does not. If staff disagree about a decision, note the disagreement beside the chart rather than hiding it behind a tidy diamond.
Key takeaways
To draw a useful business-workflow flowchart, set its boundary first, put actions in rectangles and branching questions in diamonds, label every decision exit, and carry every route to a recorded result. The chart should show exceptions as faithfully as the routine path. It represents the current work; it is not yet a proposal to automate every shape on the page.
Next, you’ll use a mapped workflow to judge whether it is a worthwhile automation opportunity, considering how often it occurs, how much time it could save, how clear its rules are, and what could go wrong.