Recommended resources
The freely available resources this lesson will direct you to.
Hello! This course begins by finding work that is worth automating. Before choosing a tool, you need to know what unit of work you are looking at: one task, a business process, or an automated workflow. Those terms overlap in everyday conversation, but they answer different questions.
In this lesson, you’ll follow an incoming customer request from a single action to a broader business goal, then see what changes when software takes over some of the work. That distinction will help you describe an automation opportunity without accidentally promising to automate an entire operation when you mean to automate one handoff.
Start with the scope of the work
Imagine someone receives a customer request and assigns it to the right support team. “Assign the request” is a task: a bounded piece of work with a result. “Handle customer requests” is a business process: a set of activities undertaken to achieve a broader goal, such as resolving requests appropriately. Between those two sits a workflow: the defined path a particular request follows through the work.
The short video below introduces the difference between a process and a workflow. Listen for the distinction in scope, rather than treating the two as completely separate kinds of activity.
Watch “Workflows vs Processes” from Levity for a quick way to distinguish the broader goal from the path used to complete particular work.
Watch scope and outcomes for the definitions, then the onboarding example. Notice that the same activity can be described as a process or a workflow depending on how much of it you are examining.
That last point matters. These are lenses, not rigid boxes. Employee onboarding can be the business process when you mean the whole effort to prepare a new employee for work. Within it, arranging access to software can be a workflow with several handoffs. Sending one access notification can be a task. Someone discussing only the access request might reasonably call that their process. To avoid confusion, state the start, end, and goal of the work you mean.
IBM’s introduction supplies a useful definition of a business process and distinguishes automating a single task from automating a connected workflow. Read only the indicated portions; the later automation categories are not needed yet.
What Is Business Process Automation?
Read the opening definition and the relevant part of “Different types of business process automation” from IBM Think. Together, they show how tasks fit inside processes and what it means to automate work at different scales.
In “What is business process automation (BPA)?”, read the process definition, beginning with “A business process is a series of activities” and ending with the sentence about tasks being fully or partially automated. Then, in “Different types of business process automation,” read the three levels: the entries for task, workflow, and process automation. Stop after the “Process automation” entry. Focus on what is being automated at each level, not on memorizing the labels.
Here is the practical distinction to carry forward:
| Term | Question it answers | Customer-support example |
|---|---|---|
| Task | What is one piece of work to be done? | Check which language the customer uses. |
| Business process | What broader business result are these activities meant to achieve? | Receive, address, and close customer requests. |
| Workflow | What path does a particular item follow, and who handles each stage? | A new request is reviewed, assigned, answered, and marked complete. |
A task need not be effortless or instantaneous; it is simply the unit you have chosen to treat as one piece of work. A business process need not involve software. A workflow, likewise, can be carried out entirely by people.
Follow one request through the three lenses
Suppose a customer submits a technical question in French. In a manual arrangement, a staff member reads the request, checks what it concerns and what language it uses, passes it to an appropriate colleague, and later records that it was handled. Each activity can be named as a task. The repeatable path for that request is a workflow. The broader customer-support process also has to account for other requests, follow-up, and the goal of resolving issues.
Now suppose the support team uses software to detect the request’s language and category, place it in the French technical-support queue, and notify that team. People still investigate the technical problem and decide what to tell the customer. This is an automated workflow because software carries out defined steps and a handoff when a request arrives. It is not the same as automating the whole customer-support process.
This example reveals two useful boundaries. First, automation describes how work is performed, not why the work exists. The business goal of helping the customer remains the same in the manual and automated versions. Second, automating a workflow does not require removing people from it. Software can route a request reliably while a person makes the substantive decision.
You can also automate less than a workflow. If software only sends a standard receipt for every request, it has automated a task. Many software tools may still label that small arrangement a “workflow” or “flow,” because it has a starting event and an action. For discussing a business opportunity, the more informative description is: the receipt task is automated, while the request still has to be routed and resolved. This states the scope without getting caught in a naming convention.
What makes a workflow automated?
The difference is not whether the steps are written down. A manual workflow can be carefully documented: “When a request arrives, an employee checks it and forwards it.” Automation begins when a system performs at least some of those steps or handoffs according to its configuration.
The following comparison makes that change visible. Treat it as a comparison of how work may be carried out, not as a guarantee that software will make every request faster or error-free.
What is Workflow? Definition, Types & Examples in 2026
Read the “Manual workflows vs Automated workflows” comparison from Kissflow to see what changes when a system, rather than a person, coordinates parts of a workflow.
Find the subsection “Manual workflows vs Automated workflows.” Read its table from “Handoffs” through “Cycle Time,” especially the handoff comparison. The table ends with the row comparing wait times and items moving when conditions are met. Focus on who moves the work and what tells them where it should go; treat the listed benefits as possibilities that depend on a sound design.
The image below shows three support situations framed as conditions and automated responses. It is a useful illustration of a workflow rule, but each row depicts only part of the work needed to serve the customer.
Notice the difference between the responses. Routing a request to a specified team can be governed by a defined rule. Suggesting a billing reply introduces generated content that a person may need to check before it is sent. Neither response, on its own, proves that the customer’s issue has been resolved. An automated handoff is not the same thing as a completed business outcome.
This distinction protects against an easy planning mistake. “Automate customer support” sounds like a single project, but it leaves unanswered which tasks the system will perform, where people will remain involved, and what counts as a resolved request. “Automatically route incoming French-language technical requests to the appropriate queue” names a narrower, inspectable piece of the support process.
A reliable way to name what you see
When describing work, look first at its end point. If the end point is one completed action—such as recording a request’s language—you are probably naming a task. If it is a broader operational result—such as consistently handling incoming requests—you are probably naming a business process. If you are describing how an individual request travels between activities or owners, you are describing a workflow. If a system performs some of those activities or handoffs under defined conditions, you are describing an automated workflow.
The categories can nest. One business process may contain several workflows, and each workflow contains tasks. A workflow may cover almost the entire process, or only a narrow portion of it. What makes your description useful is not insisting on one universal label; it is making the scope and degree of automation clear.
Key takeaways
A task is a bounded piece of work. A business process organizes activities around a broader goal. A workflow specifies the path work follows; an automated workflow has software perform some of that work or coordinate its handoffs. Automating one task or workflow does not necessarily automate the entire process, and people can remain responsible for judgment and completion.
In the next lesson, you’ll take a manual process apart more precisely: what starts it, what information it needs, what rules guide it, what actions occur, and what comes out.