Workflow Analysis: How to See Where Your Team’s Hours Go
Published · Wendy Kinney
A workflow analysis is a structured look at how work moves through a team: the steps, who does each one, how long each takes, and where work waits or comes back. For an operations leader about to automate, the useful version ends in hours. It tells you how much of the team’s time each activity takes, measured rather than estimated, and it is finished only when those hours add up to the hours you pay for.
Take Dana, a VP of loan servicing at a regional bank. She is an illustrative composite, not a client. Her CFO wants to know how much of her 80-person team’s time an AI document tool could take on.
Dana has a good volume report: payoff quotes, escrow changes, documents indexed, borrower letters. She knows how many of each the team closes every week. What she does not know is how many hours each one costs, or what the rest of the day is spent on.
That gap is where most operations leaders start. The systems we run on were built to count what comes out of the process, not the work it took to get there. So we export the reports, build macros, and count touches to close, and the effort behind the count stays a guess.
This guide walks through a workflow analysis the way an operations team can actually run one: seven steps, what to collect at each, what the finished output looks like, how the same data becomes a workload analysis for staffing, and the mistakes that quietly make the answer wrong. If you already have a volume report and a decision due, book a 30-minute strategy call and bring both.
Quick Answer
To run a workflow analysis, name the decision it supports, set the scope and a window that covers a full month, pull your volume data, name the activities, measure the effort per activity, and reconcile volume times minutes against paid hours. Then read the variation between people and the waiting time before deciding what to automate.
What a Workflow Analysis Is, and Where Workload Analysis Fits
A workflow analysis examines one or more workflows step by step to find out what the work really involves: the sequence, the handoffs, the time each step takes, and the places it stalls. A workload analysis uses the same effort data to answer a different question, which is how many people the work needs. Process mapping is the drawing that usually comes first.
The three get used interchangeably, and they should not be. Each one answers its own question.
| Question it answers | Main output | |
|---|---|---|
| Process mapping | What are the steps, and who owns each one? | A diagram of the intended path |
| Workflow analysis | Where does the time go, and where does work stall or come back? | Hours by activity, the variation between people, the waits |
| Workload analysis | How many people does this volume of work need? | Required hours against available hours, by team and by period |
Most guides to workflow analysis treat it as a way to find bottlenecks and tidy up a process. That is a fine use. Before automation, though, the stakes are higher, because the hours you find become the business case. An AI tool that takes over an activity frees the hours that activity really costs, not the hours someone guessed it costs.
How to Run a Workflow Analysis in Seven Steps
The seven steps below take a team from “we think we know where the time goes” to a set of hours that will stand up in a budget meeting. Each one ends with what to collect, so you can check you have it before moving on.
Step 1: Name the decision the analysis has to support
Start with the decision, not the process. “Which of our workflows could an AI document tool take on, and how many hours would it free?” leads to a different analysis than “Why are escrow changes missing their service level agreement (SLA)?” The first needs effort by activity across the team. The second needs waiting time and handoffs on one workflow.
Writing the decision down also keeps the scope from drifting. A workflow analysis without a decision tends to grow into a documentation project that never finishes.
What to collect: the decision in one sentence, who will make it, the date it is due, and the number they will need (hours, people, or cost).
Step 2: Set the scope and the window
Pick the team, the workflows, and the period you will look at. The window matters more than most guides admit. Two weeks in the middle of a month will miss month-end, quarter-end, and any seasonal peak, and those are often the weeks that set staffing.
Cover at least one full monthly cycle. If the work has a known annual peak, such as escrow analysis season in servicing or open enrollment in benefits administration, note where your window sits against it.
What to collect: headcount in scope by role, the hours each person was paid for in the window (net of leave and holidays), and a calendar of the known peaks.
Step 3: Pull the output data you already have
Your systems already count a lot: items received and closed by work type, cycle times, SLA attainment, items returned for rework. Pull all of it for the same window. This is the volume side of every number you will produce later.
Be clear about what it cannot tell you. A volume report shows what came out of the process. It does not show the minutes of effort behind each item, or the work that produces no countable item at all.
What to collect: weekly volume by work type, cycle time, rework or return rates, and SLA results, all for the same window as Step 2.
Step 4: Name the activities before you time them
Agree on a short list of activity names before anyone measures anything. “Payoff quotes” is a work type. Inside it are activities: pulling the loan record, calculating per diem interest, checking for pending escrow disbursements, drafting the quote, and answering the follow-up. If two people use different names for the same activity, the numbers will never add up.
Aim for 15 to 40 activities for a team, each with a one-line definition and the work type it belongs to. Include the activities that have no work type: the shared mailbox, internal reporting, meetings, training, and rework.
What to collect: an activity list with definitions, mapped to work types, and signed off by the team leads who will read the results.
Step 5: Measure the effort
This is the step that decides whether the analysis is worth anything. There are six common ways to get effort per activity, and they differ a lot in what they can see.
| Method | What it gives you | Where it falls short |
|---|---|---|
| Interviews and workshop estimates | Fast, cheap, and it gets the vocabulary right | Minutes from memory, usually for the typical case |
| Time diaries and self-logging | Each person’s own account, day by day | Logging is extra work, it fades after the first week, and short tasks drop out |
| Work sampling | A statistically sound share of time by category, from many random observations | Needs a large number of observations, and the categories stay broad |
| Time-and-motion study | Precise timing of one task | One task, a handful of people, a few days |
| System logs and process mining | Exact timestamps for every case | Elapsed time between system events, not the minutes someone spent; nothing outside the system |
| Desktop activity capture, classified by activity | Effort per activity for every person, every day, including work outside the mapped process | Needs deployment and a clear agreement with the team; does not see work away from the desk |
Memory is the weak link in the first two. A 1998 Monthly Labor Review article by sociologist Jerry A. Jacobs, Measuring time at work: are self-reports accurate?, quotes time-use researchers John Robinson and Geoffrey Godbey: “People think they know how many hours they work, that is, until they actually try to figure it out.” Jacobs found that a person’s total workweek is reported reasonably well on average. Splitting that week into 30 activities from memory is a much harder question, and it is the one a workflow analysis asks.
We will not repeat the case for measuring at the activity level here; it is laid out in full in our guide to activity-based workforce measurement. If your workflows run mostly inside one system, process mining reads a lot from the logs, and our comparison of process mining and workforce intelligence shows where its view ends.
What to collect: minutes per activity, per person, for the whole window, and the method each number came from.
Step 6: Reconcile against the hours you pay for
This is the check that tells you whether the analysis is complete. Multiply each work type’s volume by its measured minutes per item, add the measured work that has no volume count, and compare the total with the hours the team was paid for in the window. If the two do not meet, you have not found where the time goes yet.
The guides we read for this topic stop before this check, and it is the one we would never skip. It catches estimates that are too low, work nobody listed, and activities counted twice.
Here is how it looks for Dana’s team. The figures are illustrative. Her 80 people had 11,200 hours on the clock across four weeks, after leave and holidays.
| Work type | Volume (4 weeks) | Workshop estimate (min per item) | Hours at the estimate | Measured average (min per item) | Hours measured |
|---|---|---|---|---|---|
| Payoff quotes | 6,000 | 10 | 1,000 | 14 | 1,400 |
| Escrow changes | 3,000 | 30 | 1,500 | 26 | 1,300 |
| Document intake and indexing | 24,000 | 5 | 2,000 | 6 | 2,400 |
| Borrower correspondence | 6,000 | 20 | 2,000 | 23 | 2,300 |
| Volume-driven total | 6,500 (58%) | 7,400 (66%) |
The workshop numbers explained 58% of the hours Dana pays for. That should have stopped the analysis there, because 42% of a team’s time cannot be “everything else.” Measured, the volume-driven work came to 66%.
The measurement then found another 3,000 hours (27%) in work with no volume count: investor reporting spreadsheets, triage of the shared mailbox, and rework on documents returned by the investor. The last 800 hours (7%) were meetings, training, and time away from the desk.
Now the hours reconcile, and every one of them has a name. That is the point at which a number can go to a CFO.
If your volume report and your paid hours are on two different spreadsheets right now, that is the conversation to bring to a strategy session with Wendy.
What to collect: a reconciliation table like the one above, with the unexplained remainder stated as a number.
Step 7: Read the variation and the waiting time, then hand off
An average hides the two findings that change the most decisions. The first is variation between people. In Dana’s illustrative data, payoff quotes average 14 minutes, but the range across the team runs from eight to 22. Before automating the activity, it is worth asking what the eight-minute people do differently, because a method fix may take out more hours than a tool.
The second is waiting time. Cycle time is touch time plus waiting time. If escrow changes take 26 minutes of effort and nine days end to end, the problem is the queue and the handoffs, and automating the 26 minutes will not touch the nine days.
Only now is the work ready to be scored for automation. That is a separate exercise with its own factors (volume, rules against judgment, exceptions, risk), and our workforce automation analysis walks through the scoring model. For the wider question of which work qualifies at all, start with how to know what to automate in operations.
What to collect: the range per activity by person, touch time against cycle time per work type, and a shortlist of activities to score.
What the Output of a Workflow Analysis Looks Like
A finished workflow analysis is a short set of numbers that anyone in the room can trace back to the work. For a team like Dana’s, it has six parts:
- Decision it answers, in one sentence, from Step 1.
- Time allocation by activity, as hours and as a share of paid time, for the whole team and by role.
- Reconciliation table, with the unexplained remainder shown.
- Effort per item by work type, with the range across people, not only the average.
- Touch time against cycle time, so waits and handoffs are visible next to effort.
- Shortlist for scoring: the activities big enough and stable enough to be worth an automation case.
The test of a good output is simple: pick any number in it and ask where it came from. If the answer is “a team lead’s estimate,” label it that way. A budget decision can survive an estimate that is labeled. It does not survive one that is presented as a measurement and later turns out not to be.
The same structure works outside banking. In a utility’s back office, the work types are work orders, meter exceptions, and outage follow-ups, and the activities sit inside work order management and dispatch systems. Our page on workforce intelligence for utilities and field service covers that setting.
Workload Analysis: The Same Data, Turned Into a Staffing Number
A workload analysis compares the hours the work needs with the hours the team has. Once a workflow analysis has produced measured minutes per item, the arithmetic is short:
- Required hours = the sum of (volume × measured minutes per item) for each work type, plus the measured work with no volume count.
- Available hours = people in scope × hours each is paid for in the period, less leave, training, and meetings.
- Load = required hours ÷ available hours, by team and by week, so the peaks show.
The workload guides that rank today mostly come from time-tracking and workforce management vendors, and they start from estimates or a tracker export. The arithmetic is the same either way. What differs is how much you can trust the minutes you put into it.
Dana’s illustrative numbers show why that matters. Her team has 11,200 available hours in four weeks, which is 140 hours per person.
Suppose the AI document tool cuts intake and indexing from six minutes per item to two, an assumption to test in a pilot. On 24,000 items, that frees 1,600 hours, or about 11 people’s worth of time, before exceptions, rework, and ramp-up are counted. With the workshop estimate of five minutes, the same assumption frees 1,200 hours, about nine people. The 400-hour gap, close to three people, came entirely from how the minutes were collected.
If you want to run those numbers on your own team, our workforce capacity planning model takes volumes, minutes per item, and available hours and returns the load by period.
Seven Mistakes That Make a Workflow Analysis Wrong
Most workflow analyses that go wrong were set up wrong, through one of a few choices made early, before anyone looked at the data.
- Starting from the process instead of the decision: The analysis grows to cover everything and answers nothing in time.
- Treating estimates as measurements: A workshop number typed into a spreadsheet looks the same as a measured one. Label the source of every figure.
- Choosing a window that misses the peak: Two quiet weeks produce a staffing number that breaks at month-end.
- Stopping before the hours reconcile: If a large share of paid time is unexplained, the analysis has found the visible work, not all of it.
- Averaging away the variation: The spread between people is often where the first hours come from, and an average erases it.
- Confusing cycle time with effort: A long cycle time is usually waiting. Automating the effort will not shorten the wait.
- Not telling the team what is being measured and why: People who think a study is a performance review change how they work for the duration. Say what is captured, what is not, and what decision it feeds. It improves the data as well as the trust.
Running a Workflow Analysis Across a Whole Operation
For one team and one workflow, interviews, two weeks of work sampling, and a careful reconciliation can be enough. If your team is small or the decision is narrow, start there. It gets harder when the decision spans hundreds of people and dozens of workflows, because the manual methods do not scale, and the estimates multiply.
That is the case Summit Trails is built for. Our approach captures the effort side of Step 5 for everyone in scope, every day, so Steps 6 and 7 run on measured data instead of recall:
- Capture: a lightweight desktop client records the region around each click, not the full screen, and captures no keystrokes. That comes to 500 to 3,000 captures per person per day.
- Classify: Patent Pending AI classifies each capture at the activity level, so the output reads “calculating per diem interest for a payoff quote” rather than “in the servicing system.”
- Insight: the platform produces time allocation by activity, app drill-downs, workflow maps, automation scoring, and day narratives for each person.
You own the data. An engagement runs 90 days, with first findings around weeks three to four and the Ground Truth AI² Report™ at the end.
It needs at least 50 employees in the operations area being assessed and an environment on Azure or AWS. Pricing is a base fee plus a per-employee cost, scoped on a call. You can read more about how Summit AI works or see the Summit AI platform itself.
Back to Dana, still illustrative. With the measured numbers, she goes to her CFO with three findings instead of one. The AI document tool is worth a pilot on intake and indexing, sized at roughly 11 people’s time rather than nine.
Payoff quotes need a method fix first, because the gap between the eight-minute and 22-minute processors points to a method difference worth fixing before any tool is bought for that work. And 3,000 hours of investor reporting and rework had never appeared in any business case, which makes them the next thing to look at. Each of those numbers traces back to the work, so none of them has to be defended as a guess.
Frequently Asked Questions
What is workflow analysis?
Workflow analysis is the structured study of how work moves through a team: the steps, who performs them, how long each takes, and where work waits or is sent back. In operations, it is used to find where a team’s hours go before deciding what to change, automate, or staff differently.
What are the steps in a workflow analysis?
A workflow analysis has seven steps: name the decision it supports, set the scope and a window that covers a full monthly cycle, pull existing volume and cycle-time data, agree on activity names, measure the effort per activity, reconcile volume times minutes against paid hours, and read the variation between people and the waiting time.
What is the difference between workflow analysis and workload analysis?
Workflow analysis finds out where the time goes: which activities take how long, for whom, and where work stalls. Workload analysis uses those effort figures to compare the hours the work needs with the hours the team has. Workflow analysis comes first, because a workload analysis is only as good as the minutes per item it starts from.
What data do you need for a workflow analysis?
You need volume by work type, cycle times, rework rates, headcount, and the hours each person was paid for, all for the same window. You also need effort per activity, which most systems do not record. That comes from estimates, self-logging, work sampling, time studies, system logs, or desktop activity capture.
How long does a workflow analysis take?
For a single workflow using interviews and existing reports, a few weeks. For a measured analysis across a team, plan on at least one full monthly cycle of data so month-end is included, plus time to reconcile and review. Summit Trails engagements produce first findings around weeks three to four and a full report at 90 days.
How often should a workflow analysis be done?
Run one before any decision that rests on the hours: an automation business case, a staffing change, or a new SLA. After a change goes live, measure again against the original baseline, so you can show what the change actually did to the hours.
Bring Your Volume Report to a Strategy Call
If you have a decision due and a volume report that counts the output but not the effort, you already have half of a workflow analysis. The other half is the minutes.
In 30 minutes we will look at the decision, the work types in scope, and how far your current numbers reconcile with the hours your team is paid for. You will leave knowing which of your figures are measured and which are estimates. Book a 30-minute strategy call.
