Business process flowchart
Map a bounded business process with explicit actions, decisions, exceptions and return conditions, separating current records from a proposal.
Use a flowchart when roles disagree about how work moves or when a transaction is considered processed. Define boundaries first, then draw actions and decisions with explicit handoff inputs and outputs. Keep current and proposed processes separate.
Process boundaries, roles, supported steps, decision conditions, exceptions, return paths, inputs, outputs and unconfirmed handoffs.
A flowchart with decisions and return conditions, a waiting and handoff list, and a walkthrough plan.
How to use it
- Define the trigger, endpoint and current or proposed status.
- List actions, roles, inputs, outputs and handoff acceptance conditions.
- Write each decision as a checkable question and connect every answer to a path.
- Show waiting, corrections, cancellations and conditions for returning, without unconditional loops.
- Ask actual operators to walk through normal and exception cases, then record unresolved rules.
Keep its limits in mind
A flowchart establishes neither efficiency nor effective controls or service completion. Every branch needs a condition, and waiting is not completion. Split complex processes into bounded subflows. This figure illustrates one decision; additional decisions need their own explicit paths rather than invented steps or authority.
Showing the return path for an incomplete booking request
Fictional teaching example: Pinebridge is preparing a booking-service pilot. Packet F0 records one mature W0 cohort: 100 eligible requests, 60 confirmed bookings and 48 completed services within those 60. The future pilot, staffing and plans are unapproved and unexecuted.
On a small screen, scroll across the diagram to read it.
Draw the boundary: This is a proposed intake subflow, not the whole customer journey. A confirmed booking is not a completed service in the KPI tree.
Keep both answers: The yes path requires both complete details and a verified slot. The no path records missing items and an Ops follow-up; only a resubmission triggers another check. Silence does not imply confirmation.
Result and exceptions: The draft exposes waiting, separate cancellation closure and an unconfirmed response deadline. Four walkthrough cases are proposed; no execution, faster handling or control effectiveness has been demonstrated.
This proposed subflow has one decision. Booking confirmation and KPI service completion are different events. Waiting, cancellation and a planned walkthrough are not successful outcomes.
Next step: The Lead should ask Ops and an applicant representative to walk through all four cases and confirm waiting, handoff and cancellation rules.
Three reasons to pause before connecting the boxes
Use a flowchart when the same request reaches different outcomes because people interpret a step or handoff differently. State the trigger and endpoint, then decide whether you are documenting current records or proposing a future process. A single diagram should not quietly mix both.
Pause when a decision has no checkable condition. Pause when a return arrow says “try again” without a new input or trigger. Pause when waiting is drawn as completion merely to make every path end neatly. Write the unresolved rule beside the process; do not invent a deadline or authority to complete the picture.
Choose a bounded subflow before adding every organizational activity. Label actions with roles and outputs. If a second decision is necessary, give it its own question and explicit paths. The existing figure illustrates one combined decision; the case notes below explain its exceptions without claiming the renderer draws a larger multi-decision system.
Choose mapping, redesign or measurement
Mapping helps people inspect the movement of work. It does not demonstrate why a delay occurs or whether a proposed replacement is better. Those questions require observations or a separate test.
| Method | Material | Output |
|---|---|---|
| Business process flowchart | Trigger, roles, decisions, handoffs and exceptions | A bounded path and unanswered rules |
| ECRS | A current path and required outputs or controls | Redesign candidates to assess |
| Customer journey map | A person’s task and attributed experience records | Touchpoints and experience questions |
| KPI tree | Compatible counts and measurement definitions | A metric breakdown, not process causality |
Worked case: specify four walkthroughs before running them
This continues fictional Pinebridge F0. Its mature W0 cohort contains 100 eligible requests, 60 confirmed bookings and 48 completed services within those 60. Those counts are background, not results from the proposed flow. The pilot and staffing remain unapproved. The subflow starts when Applicant submits and Ops records the request ID and original input. Its endpoint is a confirmed, awaiting-details or explicitly cancelled record, not a completed service.
The combined question is: are details complete AND an available slot verified? Only both true permits the yes path. On the no path, Ops records what is missing or unverified and follows up. Return to the check only when Applicant supplies details or a new slot. A reply does not bypass the decision; a slot must still be verified. No reply remains waiting.
The following four input cards are fictional proposed walkthroughs, not four observed requests or a passed test report. Each card identifies the expected draft path and the rule that participants still need to confirm. Cancellation is an explicit closure distinct from a booking. Response deadlines and handoff acceptance remain unknown; no time limit is supplied by the diagram.
| Input card | Proposed path | Still to check |
|---|---|---|
| Complete details; available slot verified | Ops confirms and records booking; intake ends | What record demonstrates handoff acceptance? |
| Missing details | Record missing items; follow up; wait for resubmission | Which fields are required and how is a reply linked? |
| Details complete; slot unverified | Record slot issue; wait for new slot and recheck | Who verifies availability and records the answer? |
| Applicant cancels | Record explicit cancellation closure | How is cancellation communicated and retained? |
Review the handoff before claiming a better process
The conclusion is a proposed intake path that exposes waiting and an unresolved handoff. It does not demonstrate faster processing or effective controls. The Lead should invite Ops and an applicant representative to walk through all four cards, confirm decision meanings and agree what constitutes acceptance. Attendance, agreement and test execution must be recorded separately.
For each walkthrough, retain the card, participants, version, traced arrows, record expected at the endpoint and any disagreement. If nobody can explain who verifies a slot, leave that rule unresolved and seek the appropriate owner. Do not turn the planned follow-up into an automatic loop. Agree any reminder or expiry policy explicitly before adding it; silence alone does not authorize confirmation or cancellation.
After a real trial is authorized, record requests with their actual status and timestamps using agreed definitions. Keep waiting and cancelled items visible. A confirmed booking belongs to the booking count, while service completion requires separate evidence within the same cohort. Compare processing time or errors only with a suitable baseline and complete observation conditions. At review, append findings and approved changes to the original draft. Completing four walkthroughs would establish that they were performed, not that all exceptions are known or that the service improved.
Check your work
- Boundaries, symbols and arrows are clear and decisions are checkable.
- Normal and exception paths have destinations; waiting is not completion.
- Current and proposed paths remain separate, and an unperformed walkthrough is not recorded as passed.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.