What Is a Process? Definition, Types and Examples for Business

A process is a repeatable set of activities that turns a defined input into a defined output, started by a trigger and owned by someone accountable for the result. That is the whole answer to "what is a process", and every part of it matters. Take away the trigger and nobody knows when to start. Take away the defined output and nobody knows when they have finished. Take away the owner and the process belongs to everyone, which in practice means it belongs to no one.

Most companies between 10 and 500 people run on processes that were never designed. They grew out of whatever the first person to do the job happened to do, then got passed along by word of mouth. That works until the person leaves, the team doubles, or an auditor asks for evidence. Then it becomes obvious that "how we onboard a client" lives in three people's heads and two conflicting spreadsheets.

This guide is for operations, IT, HR and team leads who need to move from that state to processes that are named, documented and run the same way every time. By the end you will be able to tell a process from a procedure, a workflow and a project; classify the processes your team runs; define one properly in seven steps; choose the right format to document it; and judge how mature your process management really is.

What Is a Process? A Working Definition

The dictionary calls a process "a series of actions taken to achieve a result". That is true but not useful, because it describes a shopping trip just as well as a month-end close. A business process needs a tighter definition, and the most practical one has five parts.

Each of those five parts answers a question that someone on your team will otherwise have to guess at.

Trigger: when does it start?

Every process begins with an event. A signed contract triggers client onboarding. A resignation letter triggers offboarding. The first working day of the month triggers month-end close. If you cannot name the trigger, you do not yet have a process; you have a task that somebody does when they remember to. A surprising number of "processes" fail for exactly this reason, and it is why recurring checklists that fire on a schedule outperform documents that wait to be opened.

Inputs: what does it need?

Inputs are the information, materials, approvals and access a process needs before it can run. Employee onboarding needs a signed offer, a start date, a role, a manager and a location. Without a list of inputs, the process starts and immediately stalls while someone chases the missing piece.

Activities: what happens, in what order?

The activities are the steps, including the decision points where the path splits. "Create the email account" is an activity. "If the hire is remote, ship the laptop; otherwise leave it at reception" is a decision. Most process documentation captures the activities and forgets the decisions, which is why it reads well and fails in practice.

Output: what does "done" look like?

The output is the thing the process exists to produce, described specifically enough that two people would agree whether it had been achieved. "New hire onboarded" is not an output. "New hire has working accounts, a configured device, a completed security induction and a first-week plan agreed with their manager" is.

Owner: who is accountable?

The owner is not the person who does every step. They are the person who answers for the process as a whole: whether it runs when it should, whether the steps are still right, and whether the output meets the standard. When a process has no owner, it drifts. Steps get added by whoever hit a problem last, nothing is ever removed, and nobody notices that the output has quietly degraded.

Where the idea comes from: Ford, 1913

The clearest early demonstration of what a designed process can do came from the Ford Motor Company. Before 1913, a Model T was built by teams of craftsmen who moved around a stationary chassis, each fetching parts and doing whatever the car needed next. On 1 December 1913, at the Highland Park plant, Ford switched on a moving assembly line: the chassis travelled past fixed stations, and each worker performed one defined activity with the parts already at hand.

The commonly cited result is that chassis assembly time fell from over twelve hours to around an hour and a half. Nothing about the car changed. What changed was that the work was broken into defined activities, in a defined order, with defined inputs delivered to each station, and someone responsible for the flow of the whole line. That is a process, and it is the same structure that makes a good client onboarding or change management process work today. The lesson is not "build an assembly line". It is that the design of the work matters as much as the skill of the people doing it.

Process vs Procedure vs Workflow vs Task vs Project

These five words get used interchangeably, and the confusion has a real cost: teams document a procedure when they needed a process, or run a repeatable process as if it were a one-off project. Here is how they differ.

The two distinctions that matter most in practice are process versus procedure and process versus project.

Process versus procedure. A process is the "what and why"; a procedure is the "exactly how" for one part of it. Client onboarding is a process. "How to set up a client in the billing system" is a procedure inside it. You need both, but they live at different levels and are written for different readers. The process is read by whoever manages the outcome; the procedure is read by whoever is doing that step at 4pm on a Friday. If you are writing the second kind, how to write an SOP covers it step by step, and writing standard operating procedures covers how to build a whole set of them across a team.

Process versus project. A project happens once and is planned as a one-off. A process happens every time its trigger fires and is designed to be repeated. The mistake most small companies make is treating repeatable work as a series of projects: every new client gets a fresh plan, every new hire gets an ad hoc set of tasks, and the same lessons are relearned each time. When you notice the same "project" recurring, that is the signal to define it as a process.

Workflows deserve a word too. A workflow is the routing view of a process: who hands what to whom, and where the path branches. Two companies can run the same process with different workflows, one routing everything through a manager and the other letting the technician self-serve. When people say "our workflow is broken", they usually mean the hand-offs, not the steps.

The Three Types of Business Process

Every process in a company falls into one of three categories, and knowing which one you are looking at tells you who should own it, how tightly it should be controlled and how much it is worth investing in.

Operational (core) processes

Operational processes are the ones that deliver value directly to the customer. They are the reason the business exists and the ones customers notice when they go wrong. In a manufacturer that is order fulfilment and production; in an MSP it is ticket resolution, onboarding a new client and running maintenance windows; in a SaaS company it is customer onboarding, support and release management; in a professional services firm it is engagement delivery and invoicing.

Operational processes should be your first priority for definition and standardisation. They run most often, involve the most people and carry the highest cost when a step is missed. A client onboarding process that skips the kick-off call, or a ticket process that never confirms resolution with the user, damages the relationship the company depends on. The client onboarding checklist guide walks through one of these in detail.

Support processes

Support processes do not deliver value to the customer directly, but the operational processes cannot run without them. IT provisioning, employee onboarding and offboarding, procurement, vendor onboarding, facilities maintenance, payroll and recruitment are all support processes. Customers never see them, but a customer-facing engineer without a working laptop cannot resolve tickets, and a supplier that was never properly set up cannot be paid on time.

Support processes are usually the most neglected. They belong to functions that are small in headcount, often one or two people, and they run less visibly than the core. They are also where compliance risk concentrates: access that is never revoked after someone leaves, a vendor onboarded without a data processing agreement, a device that was never encrypted. Defining them costs little and removes a disproportionate amount of risk.

Management processes

Management processes plan, monitor and govern the other two. Budgeting, strategic planning, performance reviews, risk management, internal audit, KPI reporting and the review cadence of the processes themselves all sit here. They tend to run on a calendar rather than on an event, which makes them easy to postpone and easy to forget.

The failure mode of management processes is not a missed step but a missed cycle: the quarterly risk review that quietly stops happening, the process review that never gets scheduled after the first one. Putting them on a fixed schedule, with a named owner and a record of each run, is usually enough to fix that. This category is also where business process management as a discipline lives: the management process of managing processes.

What a Well-Defined Process Looks Like

Before defining or fixing a process, it helps to know what you are aiming for. Use this list to score any process your team runs today. A process that fails three or more of these items is not yet defined, whatever the documentation says.

• It has a name that everyone in the team uses for it, and the name describes the outcome, not the department
• It has a stated purpose: one sentence on why it exists and who the output is for
• The trigger is explicit: a named event or a fixed schedule, not "when needed"
• The boundaries are clear: what counts as the first step and what counts as the last
• The inputs are listed, and the process cannot start until they are present
• The output is described specifically enough to be checked by someone other than the person who produced it
• Every step has a role or a named person responsible for it
• Decision points are written down with their conditions, not left to judgement
• Hand-offs between people or teams are explicit, including what is handed over and how
• It has an owner who is accountable for the process as a whole and who reviews it on a schedule
• At least one measure exists for it: cycle time, error rate, completion rate or cost
• Every run leaves a record of who did what and when

Notice that none of these items say the process must be long, complicated or heavily controlled. A three-step process can pass every one. What they demand is precision about the things people are otherwise left to guess: when to start, what is needed, who does what, and how you know it worked.

Why Processes Matter: Five Things They Buy You

Defining processes is unglamorous work, and it is worth being clear about what the return is. There are five, and each shows up at a different stage of a company's growth.

Consistency

A defined process produces the same output whoever runs it. That is the whole point of the Ford line and of the surgical checklist. In The Checklist Manifesto, Atul Gawande describes the WHO Surgical Safety Checklist trial across eight hospitals: deaths fell by 47% and major complications by 36%, without any change to surgical skill or equipment. The checklist made the defined process happen every time instead of most of the time. The same mechanism works for a server hardening process or a month-end close. Variation is where errors hide, and a defined process removes the variation that is not adding value.

Onboarding

When a process exists only in someone's head, a new starter learns it by shadowing that person and absorbing whatever they happen to mention. When the process is defined, the new starter can run it on their first week with supervision and on their second week without. The time to competence drops from months to weeks, and the quality of the output no longer depends on who trained them.

Scaling

Growth breaks undefined processes. At five people, everyone knows how everything is done because everyone does everything. At 25, the founders are the bottleneck because every decision routes through them. At 100, there are three versions of every process and nobody knows which is current. Defined processes let you add people, locations and clients without adding chaos in proportion. This is the practical content of process standardisation: one way of doing the work, followed by everyone, improved deliberately.

Compliance and evidence

Every compliance framework, whether ISO 27001, SOC 2, Cyber Essentials or a customer's own supplier audit, asks two questions: is there a defined process, and can you prove it was followed? An undefined process fails the first question. A defined process with no record of its runs fails the second. Defining the process and running it in a way that leaves a record answers both, and turns audit preparation from a reconstruction exercise into a retrieval exercise.

Handover and resilience

People leave, go on leave and get promoted. A defined process survives that; an undefined one walks out of the door with them. The test is simple: if the person who runs your client onboarding resigned tomorrow, could someone else run it next week to the same standard? If the honest answer is no, the process is a single point of failure, and it is worth treating it with the same seriousness you would treat a server with no backup.

The Hidden Cost of Undocumented Processes

The cost of an undefined process rarely appears as a line item. It appears as small, recurring losses that nobody attributes to the cause. The following examples are illustrative rather than measured, but every operations lead will recognise at least one of them.

The rework tax

An IT team onboards a new hire. Because there is no defined list of inputs, the engineer creates the accounts before finding out the hire is in a different office and needs a different set of group memberships and a different device build. Half the work is undone and redone. At two hours per hire and forty hires a year, that is two working weeks a year spent correcting work that was done correctly the first time against the wrong information.

The chase

Finance closes the month. Because there is no defined hand-off from sales to finance, the accountant spends the first three days of every close chasing sales for signed order forms that should have arrived with the deal. The close takes eight working days instead of five. Nobody calls this a process problem; they call it "sales never sends the paperwork", and it happens every month.

The silent skip

An employee leaves. The manager tells HR, HR updates payroll, and IT finds out three weeks later when the leaver's mailbox fills up. Their VPN access, their SaaS logins and their access to the client file share stayed live for those three weeks. Nothing went wrong this time, which is precisely why the process was never defined, and why it will not be defined until something does.

The founder bottleneck

A 30-person agency has one person who knows how a project is set up: which folders, which naming convention, which tools, which client contacts to add. Every new project waits for that person to have half an hour spare. They are also the managing director. The company's throughput is capped by the calendar of its most expensive employee, on work a junior could do from a checklist.

The audit scramble

A prospective enterprise client sends a 200-question security questionnaire. Question 47 asks how access is reviewed and how often. The honest answer is "when someone thinks of it". The team spends a week building a process that should have existed already, and then has to admit it has run once. The deal slips a quarter.

None of these costs is dramatic on its own. Together they are the reason growing companies feel busier every year without becoming more productive. Defining the processes involved removes most of them permanently, and the definition itself is usually an afternoon's work per process.

How to Define a Process in 7 Steps

Defining a process does not need a workshop, a consultant or diagramming software. It needs the people who do the work, an hour or two, and the seven questions below asked in order. Work through them for one process at a time, starting with the one that runs most often or hurts most when it goes wrong.

When all seven steps are done, you have a defined process on one or two pages. Run it three or four times before changing anything: the first runs will reveal steps you missed and decisions you did not know were there. Then set a review date, usually three to six months out, and put it in the owner's calendar.

Documenting a Process: SOP, Flowchart or Checklist?

A defined process needs to be written down in a form people will use. There are three common formats, and the question is not which is best but which fits the process and the reader. Many processes end up with two: a flowchart for understanding and a checklist for execution.

When the SOP fits

Write an SOP when a step is technical enough that getting it wrong has consequences and the right way is not obvious: configuring a firewall rule, running payroll, handling a data subject access request. The SOP is the reference the checklist points to. Keep it to the one step it covers, keep it short, and give it a version and an owner. Writing standard operating procedures covers how to plan and roll out a set of SOPs across a team without them going stale.

When the flowchart fits

Draw a flowchart when you need to see the process rather than read it: when there are more than two or three decision points, when several teams are involved and the hand-offs are the problem, or when you are redesigning the process and need everyone to agree on the current state before changing it. A swimlane flowchart, with one lane per role, is the fastest way to expose the hand-off that nobody owns. Process flowcharts explains the symbols and how to draw one that people will actually understand.

When the checklist fits

Use a checklist for anything that runs more than a few times a year and where you need to know, afterwards, that every step happened. A checklist is the only one of the three formats that is executed rather than consulted. In checklist software, each run assigns the steps to people, records who completed each one and when, and shows the owner what is outstanding. That record is what a flowchart and an SOP cannot give you, and it is the difference between a process that is documented and a process that is demonstrably followed.

Process Maturity: From Ad Hoc to Optimised

Not every process needs to be at the same level of maturity, and trying to take every process to the top level at once is the fastest way to abandon the effort. The four-stage model below is a simplified version of the capability maturity models used in software and quality management. Use it to judge where each process is now and decide where it needs to be.

Most small and mid-sized companies have almost every process at level 1, with a few at level 2 that were written down for an audit and never updated. Getting the core operational processes to level 3 is a realistic goal for a year, and it delivers most of the value. Level 4 is worth pursuing only for the handful of processes that run often enough for small improvements to compound: onboarding, ticket handling, month-end close, maintenance windows.

The jump from level 2 to level 3 is the important one, and it is mostly a tooling decision. A process documented in a wiki cannot measure itself. A process run from a template in business process management software records every run without anyone doing extra work, which is what makes measurement free rather than a chore that stops after a month.

Common Process Mistakes

The same handful of mistakes account for most failed attempts to define processes. Each one is easy to avoid once named.

Free Process Templates to Start With

The fastest way to define a process is to start from one that has already been defined and adapt it. The three templates below cover the most common support and operational processes in a growing company. Each one has a trigger, assigned roles and a clear output, and each can be edited to match how your team works before you run it. The full library is at checkflow.io/templates.

Simple Employee Onboarding Checklist

A support process triggered by a confirmed start date, covering accounts, equipment, induction and the first-week plan with a role assigned to every step.

Simple Customer Onboarding Checklist

An operational process that runs from signed contract to go-live, with the kick-off, setup, training and hand-over to the account manager tracked in order.

Vendor Onboarding Checklist

A support process for bringing on a new supplier: due diligence, contracts and data agreements, finance setup and system access, each step assigned and recorded.

How CheckFlow Fits

CheckFlow is built around the definition of a process given at the top of this guide. A process in CheckFlow is a template: the steps, the decisions, the roles and the output, defined once. Every time the trigger fires, the template is run as a checklist, and that run is the process happening, with a record of it left behind. The definition and the execution are the same object, which is what closes the gap between level 2 and level 3 on the maturity scale.

Templates. Start from the template library or build your own in the template designer. Each step can carry instructions, links to your SOPs, required fields and file uploads, so the "exactly how" sits next to the step without cluttering the process.

Task assignment. Every step is assigned to a user or a role in the template, and the assignment is made automatically each time the process runs. The account manager gets the kick-off call, the engineer gets the provisioning steps, finance gets the billing setup, without anyone forwarding an email.

Dynamic due dates. Due dates are set relative to the trigger or to another step: device ordered within two days of the offer, accounts created the day before the start date. Overdue steps notify the assignee and the owner, so the process escalates itself instead of waiting to be chased.

Conditional logic. The decision points from step 4 of the definition become if-then rules. If the hire is remote, the shipping steps appear; if not, they stay hidden. One template handles every variation of the process without a separate checklist for each.

Recurring schedules. Processes with a calendar trigger, such as month-end close, maintenance windows or quarterly access reviews, run automatically on the schedule you set. Nobody has to remember to start them. See recurring checklist software for how that works in practice.

Real-time dashboard. The real-time dashboard shows every running process, who is on which step and what is overdue. The owner sees the state of the process without a status meeting, and analytics give the cycle times and completion rates that level 3 depends on.

Audit trail. Every run records who completed each step, when, and what they entered. When an auditor or a customer asks for evidence that the process was followed, the record already exists.

Zapier and API. Triggers can come from other systems: a deal marked won in your CRM can start client onboarding, and a completed step can push data back out. The Zapier integration and REST API connect CheckFlow to the tools your team already uses, and automations handle the hand-offs where a human adds no value.

CheckFlow starts from $10 per user per month, with a 14-day free trial and no credit card required. The business process management software page covers the full feature set.