Task management · Taskending editorial team
How to map a business process: steps and example
A business process map shows how a request becomes an outcome. Instead of listing departments, it connects a trigger, inputs, decisions, owners and outputs. Start with one real workflow rather than trying to model the whole organization.
Updated: · 2 min read
Set clear start and finish boundaries
“Improve customer support” is too broad for a first map. “Start when a new request arrives and finish when the customer receives the outcome” provides a workable boundary. Record the trigger and the evidence of completion. If the output becomes another process’s input, show that boundary explicitly. Avoid trying to resolve sales, engineering and billing procedures in the same exercise.
Learn how the work actually happens
Ask someone doing the work to walk through a recent harmless example. Record reality before designing the ideal process: who received it, what information was missing, which decision was awaited and where the result went. Separate waiting from active work. Use roles rather than personal names to make the map resilient to staff changes. Private customer details are unnecessary for understanding the workflow.
Describe actions, decisions and return paths
Name each action with a verb: classify the request, ask for missing information, verify the solution. Express decisions as questions, such as “Are reproduction steps sufficient?” Show where the work returns when the answer is no. Mapping only the successful path hides exceptions that often create delays. In the example, an incomplete request waits for information before entering investigation.
Observe bottlenecks before choosing a fix
Compare arrival, handover and completion times for five or ten example records. If most elapsed time is spent waiting for another team’s approval, faster issue creation is unlikely to solve the main problem. Clarifying decision authority or collecting the right information earlier may help. Treat this sample as investigation, not a permanent company performance standard. Check whether unusual cases distorted the picture.
Translate the map into a task workflow
In Taskending, map issue states to meaningful waiting and working stages. Do not create a separate state for every box; choose stages people need to see to make decisions. Add entry conditions and expected outputs to descriptions. Use linked, owned issues for cross-team work. A status change alone is not evidence that the receiving team accepted a handoff.
Start with one improvement
Pick one bottleneck and one change. For example, add reproduction steps to the intake template when missing information causes repeated returns. Compare return reasons in the next sample. Update the map if the new control creates waiting elsewhere. A useful process map is a maintainable description of current work, not a diagram created once and forgotten.
Example support process map
| Step | Role | Input / decision | Output |
|---|---|---|---|
| Receive request | Support | New customer message | Single record |
| Check information | Support | Enough reproduction detail? | Ready or awaiting information |
| Investigate | Resolution owner | Ready request | Proposed solution |
| Verify outcome | Reviewer | Does it meet expectations? | Approval or rework |
| Notify customer | Support | Verified outcome | Reply and completion evidence |
Add your trigger, finish condition, exception path and acceptance condition for each handoff.
Download template (.md) ↓Free. No registration needed. Use it in a text editor or an issue description.
Try it in your own workflow.
Create a company workspace and your first issue. Taskending is currently free.
Start for free