Updated May 2026. Replaced the diagramming-tool roundup with the actual template we run in client process workshops, the questions that surface waste, and the sections that get skipped (badly).

Most business process analysis templates you find online are diagrams in disguise. A pretty BPMN canvas, a few swimlanes, a place to write the process name at the top. They look professional. They tell you almost nothing about whether the process actually works.

We are Osher Digital, an automation and AI consultancy in Brisbane. We have run process workshops for healthcare admin teams, recruitment agencies, finance teams in mid-market firms, and professional services partners. The template below is what we use. It is not pretty. It is not BPMN. It produces decisions inside one or two workshops, which is its job.

This guide walks through every section of the template, what to write in each section, the questions that get useful answers, and the sections we have learned not to skip. If you would rather skip the framework reading and get our short writeup of the broader picture, see our automation roadmap piece. For automation engagements that follow analysis, see our n8n consulting work.

What this template is actually for

A process analysis template earns its keep when it does three things. It creates a shared description of how work happens today, with enough specificity that two people in the room can agree on the same picture. It surfaces the friction. It points to a redesigned version that is better in measurable ways.

That is it. The template should not produce a 40-page document that nobody reads. It should not aim to capture every edge case. It should not produce a beautiful BPMN diagram that you frame on the wall. The deliverable is a short document that gets you to a decision: automate this part, redesign that step, kill this approval, leave the rest alone.

If your existing template is not producing decisions, the template is probably the problem.

Section 1. Process scope and trigger

The first section sounds trivial and is almost always wrong on the first attempt. You write down the process name, the trigger event that starts it, and the outcome event that ends it. Then you stress-test the boundary.

The trap. People tend to scope processes too small (“invoice approval”) or too large (“accounts payable”). The right scope is usually narrower than people first say. We push for a process that can be drawn in 8 to 15 steps. If you cannot describe the trigger and the outcome in a single sentence each, you have either picked too broad a process or you have not actually understood it.

The fields:

Process name
Trigger event (the specific thing that kicks the process off, with a system or person attached)
Outcome event (what makes it “done”)
What is explicitly out of scope (this matters more than people expect)
Approximate volume per week or month

Out of scope is the field people skip and shouldn’t. A claims-handling process that explicitly notes “we are not redesigning the customer notification step in this round” prevents three workshops worth of scope creep.

Section 2. Stakeholders and roles

List every role that touches the process. Not every individual. Roles. The person doing the work, the person reviewing it, the person whose system the work passes through, the person who gets escalated to when something breaks.

For each role, capture three things:

What they actually do in this process (one line, verbs only)
What systems they use
One thing they would change about the current process

That last field is gold. Run a 20-minute interview with each role-holder before the workshop and capture their grievance verbatim. The pain points section later in the template writes itself.

Section 3. As-is process mapping

This is the part most templates over-engineer. We use a simple table, not a diagram. Each row is one step.

Step | Who | System | Inputs | Action | Outputs | Avg time | Exception rate
-----|-----|--------|--------|--------|---------|----------|----------------
1    | ... | ...    | ...    | ...    | ...     | ...      | ...

Why a table and not a diagram. A diagram makes it easy to draw a beautiful flow that nobody questions. A table forces you to put a number in the time column. It forces you to admit that step 4 is “person checks two systems against each other” when the diagram would have hidden that as a single rounded rectangle.

The discipline of the table is the discipline of the analysis. If you cannot fill in the average time field for a step, you do not understand that step yet.

Exceptions and loops

For each step with an exception rate above 5 percent, capture what the exception path looks like. This is where most processes have their hidden cost. The happy path is 8 steps. The unhappy path is 23 steps and accounts for 40 percent of total handling time.

The single most useful question we ask in workshops: “Show me the last three times this went wrong. Walk me through what happened.” More wisdom comes out of that question than from any structured framework.

Section 4. Pain points and root cause

Pain points are the part everyone wants to write first and shouldn’t. They only have meaning once the as-is map is in place, because then you can attach each pain point to a specific step.

For each pain point capture:

Which step or steps
Symptom (what people experience)
Frequency (how often it happens)
Cost or impact when it happens
Best guess at root cause

Use a “5 whys” pass on the top three pain points. Half the time the root cause is not in the process at all. It is upstream (data quality from another system) or downstream (a customer expectation set by sales). Knowing this changes whether automation is the right answer.

Section 5. Metrics and baseline

If you do not capture a baseline, you cannot prove the redesign worked. Five numbers that almost always matter:

Volume per period (per day, week, or month, whichever is natural)
End-to-end cycle time (trigger to outcome, including waits)
Active handling time (time hands-on by humans)
Error or rework rate
Cost per transaction (handling time × loaded hourly rate, plus any system or vendor fees)

If you cannot find data, run a sample. Pick 20 recent transactions, walk through them, time them. A sample of 20 is enough for a workshop-stage estimate. We have used this with healthcare clients to get a defensible baseline in two days when the systems did not log handling time at all.

This baseline becomes the comparison point at month three after launch. Without it, your post-launch claims are just opinions.

Section 6. To-be design

Now you redesign. The to-be section uses the same table format as the as-is section, with two extra columns: change type, and rationale.

Change types we use:

Eliminate: the step is no longer needed. Often the highest-value change.
Automate: the step is run by software (workflow tool, AI agent, RPA bot)
Augment: the step is still done by a human but with better tooling, pre-filled data, or a decision aid
Reorder: the step survives but moves to a different position to remove waits
Simplify: the step survives but with less work in it (fewer fields, fewer approvals, fewer systems)
Keep: explicitly noting which steps are not changing

“Eliminate” should always be considered first. The cheapest, fastest, most reliable step is the one that no longer exists. We have removed entire approval gates that were created for a regulatory requirement that lapsed three years earlier.

The to-be section ends with a forecast of the same five baseline metrics. If the forecast does not show a meaningful improvement against the as-is baseline, the redesign is not worth implementing yet.

Section 7. Risks and dependencies

What could go wrong with the to-be design, and what has to be true for it to work. Five categories we always probe:

Data quality risks (the redesign assumes incoming data is clean enough)
System dependency risks (the redesign assumes a system has an API that actually works)
People risks (the redesign assumes a role-holder will adopt new tooling)
Compliance risks (the redesign changes who sees what, when)
Failure-mode risks (when the new automated step fails, what is the fallback)

For Australian organisations handling personal information, the data and compliance lines should reference Australian Privacy Principles where relevant. For health data, Privacy Act and state-level health record legislation. Most processes will not hit these. The few that do are catastrophic if you miss them.

Section 8. Implementation plan and decisions

The final section is what makes the template a decision tool rather than a documentation exercise. Three subsections.

Decisions made today. The bullets that the workshop concluded with. “We will eliminate the second approval. We will automate steps 4 to 7 with n8n. We will keep step 9 manual for now. We will not redesign the upstream data entry form in this round.”

Owner and timeline. Each decision needs a single accountable name and a date. Without these the document goes in a drawer.

Open questions. The three or four things you could not resolve in the workshop, with named owners and a date for the answer. Open questions are not failures of the workshop. Pretending they are not there is.

The whole template, end to end, fits on 6 to 10 pages for most processes we work with. If yours is longer than that, you have probably scoped too broadly or you are documenting in too much detail. Trim.

When this template is overkill

Not every process needs a formal analysis. Three cases where this template is the wrong tool.

The process is run by one person, twice a year. Just talk to them. Document what they do in a one-pager. Move on.

The process is already well-instrumented and clearly broken in an obvious way. If everyone agrees the data entry form has too many fields and the cycle time is dominated by waiting on legal, you do not need a template to confirm what you already know. Fix the form.

The process is brand new and you are designing from scratch. There is no as-is. Use a different framework: jobs-to-be-done, service blueprint, or just sketch the desired flow on a whiteboard with the team.

Conversely, this template earns its keep when the process is mature, touches several systems, multiple roles, and there is genuine disagreement about what is wrong with it. That is the situation it was designed for.

Running the workshop

The template is the artefact. The workshop is where it gets filled in. A few things we have learned the hard way.

Pre-fill what you can. Walk in with the scope, stakeholder list, and a draft as-is mapping based on pre-workshop interviews. Asking a room to invent the as-is map from scratch is the fastest way to lose them.

Have one role per pain point. When the AP team and the procurement team start describing pain points together, every disagreement becomes the workshop. Capture each role’s pain points separately, then surface the conflicts as their own discussion item.

Cap the to-be design at three hours. Past that, you are designing in too much detail for the information available. The to-be is a sketch good enough to commit to a build. The build phase will refine it.

End every workshop with the implementation section filled in. No exceptions. If the workshop runs out of time, drop content elsewhere, but keep the decisions section. The decisions are the deliverable.

If you would like to run this template against a process and would value an external facilitator, that is exactly what our discovery engagements look like. Book a call and we can talk through the shape.

From analysis to automation

The output of a good analysis is a decision: which steps to eliminate, automate, augment, reorder, or simplify. The next stage is delivery. For workflow-style automation we usually reach for n8n. For document-heavy work we reach for AI extraction agents on Claude or GPT-4.1. For high-volume back-office work the calculation might still favour classical RPA. The right answer depends on what the to-be section says, which is why analysis comes first and tooling comes second.

For more on the delivery side, see our pieces on building AI workflows in n8n and n8n for RPA.

If you would like a pair of experienced eyes on a process before you build, get in touch. We do this work most weeks. The cheapest mistake to avoid is automating a bad process. The template is how we make sure we are not about to do that.

Frequently Asked Questions

Should I use BPMN for the as-is and to-be sections?

Only if the audience reads BPMN fluently. Most don’t. We use a step-by-step table because it forces specificity and is readable by every stakeholder. BPMN is fine as a final-state artefact for technical handover. As a workshop tool it is usually overkill.

What is the difference between as-is and to-be in process analysis?

As-is is how the process actually runs today, including the messy bits, exceptions, and undocumented workarounds. To-be is the redesigned version after the analysis. The point of the template is to make the gap between them concrete and quantifiable. A to-be that does not reference specific changes from the as-is is just a wish list.

How long should a process analysis document be?

Six to ten pages for most processes we work with. If you are heading toward 20 to 30 pages, you have probably scoped too broadly or are documenting at a level of detail that nobody will read. Split into multiple processes or trim back to decision-relevant content.

How much does a business process analysis cost in Australia?

For a single mid-complexity process, a structured discovery engagement runs $5,000 to $15,000 AUD depending on number of stakeholders and depth of metrics work. Larger programs that cover multiple processes and produce a roadmap run $20,000 to $60,000. Internal teams can absolutely run this with no consultant; the template above is what you use.

What tools do you use to fill in this template?

Whatever is in front of the room. We have used Notion, Confluence, Google Docs, and a printed worksheet on butcher’s paper. The template is structural; the tooling is incidental. We avoid dedicated process modelling tools at workshop stage because they push too quickly into pretty diagrams and away from the questions that matter.

How many stakeholders should be in the workshop?

Six to nine in the room is the sweet spot. Below four you miss perspectives. Above ten the workshop becomes a status meeting. Pre-interview the people who would be in the room beyond ten and feed their input through one nominated representative.

What happens after the template is filled in?

The implementation section drives the next two weeks: each decision has an owner and a date. Build work starts on the highest-impact “automate” item. The baseline metrics from the analysis become the comparison point at month three after the redesigned process goes live.

Can I skip the as-is map and go straight to the to-be design?

Almost never a good idea. The to-be design is only as good as the understanding of the as-is. Skipping the as-is is the most common failure mode in process work; the redesigned process inherits hidden assumptions that turn into production failures. The exception is a brand-new process with no current state, in which case use a service blueprint or a jobs-to-be-done framework instead.

Business Process Analysis Template: Scope, As-Is, To-Be