# How to measure the real hours in a workflow (without asking anyone to guess)

How-to · By Nolli research, The Nolli team · Published 2026-10-20 · Updated 2026-10-20 · Prices and features checked 2026-10-19

Canonical page: https://withnolli.com/blog/how-to-measure-the-real-hours-in-a-workflow

**Short answer.** Fix the unit first: one workflow, everyone on it, one normal week. Then get the hours from the work. Count cases in system history, time a sample of them with a one-week time sample or a recorded run (with notice), and multiply. Check two sources against each other, then put the result in the Hours column of the prioritization template.

## Key takeaways

1. Hours per week for a workflow is cases per week times minutes per case, added across everyone on it; count the cases from a system and time a sample of them.
2. A one-week time sample of about 200 random moments sizes a 10% share of a team’s time to within 5 points, which is often enough to pick an hours band and sometimes not.
3. Score the average week, write down the method and the range beside the number, and measure again when the work changes.

Hours per week for a workflow come from three things you can count: how many cases there were, how long a case takes, and how many people touch it. Count them from the work. A guess from memory goes wrong once and then feeds every ranking built on top of it.

These notes cover four ways to get the hours, how many observations a time sample needs, what to do about month-end, and the privacy questions to settle first. The Disney paper on activity sampling was read in raw text on October 19, 2026. The other sources were read on October 16 for our earlier posts. We ran none of the tools named here.

## Why not ask the team

People overstate their weekly work hours by 5 to 10 percent when they answer an estimate question, against the time diaries they also filled in. That is from Robinson and colleagues, using the American Time Use Survey and a Belgian diary survey. It is total hours, not tasks. We found no source that sizes the error for one task.

The sharpest case we know is METR’s trial. After 246 real tasks, 16 experienced developers believed AI had made them 20% faster. The clock said 19% slower. That measures AI’s effect, not a task’s length, and METR now calls it out of date. It still shows how far a person’s sense of time can sit from the stopwatch. More in the productivity illusion post.

## Fix the unit before you measure

> **Workflow hours.** The hours per week that every person who touches one workflow spends on it, in a normal week. Count the workflow, not the person.

Four decisions, written down before the first export:

1. Start and end. “Starts when a change request lands in the queue. Ends when the requester has an answer.” If two people would draw the line differently, you will count two different things.
2. Everyone on it. The clerk, the approver who spends four minutes per case, the person who answers “where is mine?” all day. Leave them out and the total comes out low.
3. A normal week. No holiday, no close, no launch. Spikes get their own treatment below.
4. What counts as work. Waiting does not. A case open four days is not four days of effort.

## Four ways to get the hours

They see different things. The grid shows which. The worked example below uses three.

**What each method can see on its own** (none, partly or fully)

| | Timestamps and ticket history | One-week time sample | Observation or recording | Calendar and email metadata |
| --- | --- | --- | --- | --- |
| Cases per week | fully | partly | partly | partly |
| Minutes of real effort per case | partly | partly | fully | none |
| Share of a team’s week on the workflow | none | fully | partly | partly |
| Work outside the system (sheets, chat) | none | fully | fully | none |
| Rework and exceptions | partly | partly | fully | none |
| Spikes and seasons | fully | none | none | partly |
| Cheap to repeat next quarter | fully | none | none | fully |

Our reading from the sources cited on this page, not a measurement. Full: the method shows it by itself. Half: it shows part of it (timestamps give elapsed time, not effort). Empty: it does not show it. Any method can be set up to show more.

### 1. System timestamps and ticket history

Export closed cases for the last 12 weeks: created, assigned, status changes, closed, category, team. Count cases per week. Chart them before you read one. This is the event log that process mining reads, and it lives in the system of record.

It gives you the number of cases and the spikes. It does not give you effort. A case that sat open four days may have taken ten minutes, so never multiply created-to-closed time by anything. If the tool has an “in progress” status, test it against a recorded run before you trust it as handle time. And check how far back the history goes: Salesforce, for one, keeps field history for up to 18 months (24 through the API) unless Field Audit Trail is on, and tracks a field only from the day you switch it on.

Misses: everything done outside the system, such as the spreadsheet next to the CRM. Cost: the lowest effort of the four if you have admin rights. Records carry names and often customer text, so ask the system owner before the export leaves the tool.

### 2. A one-week time sample

Ping the team at random moments for one week. One question: what are you doing right now? The answer is a tap on a short list of their workflows plus “something else”. The share of taps per workflow estimates the share of time. Share times the team’s paid hours is the workflow’s hours.

This is activity sampling. Disney (2016) calls it relatively inexpensive, usable on long, varied and intermittent work, and less intrusive than a stopwatch. It is not efficient for short, regular, predictable activities. His procedure needs observations at random intervals, a pilot to learn the range of activities first, and a study long enough to cover that range.

It is still self-report, but about this second, not about an average week. Misses: rare events (the month-end close will not land in your week), the reason behind a choice, and precision when pings are few. The next section gives the numbers.

### 3. Observation or recording, with notice

Three forms, cheapest first. A person screen-records one run of the workflow and sends it to you. Task mining software records clicks, keystrokes and sometimes screenshots on employees’ machines. Someone shadows a worker and takes notes. All three give you real minutes per case, the work between apps, and the exceptions.

Record several runs by different people. One run is one story. We found no source for how many timed runs are enough to estimate minutes per case, so report the range as well as the average. Misses: days and people you did not record.

This method has the highest privacy cost. See the notice questions below, and the tools in best task mining software in 2026.

### 4. Calendar and email metadata

Ask IT for meeting and email headers, never bodies, for one team over a quarter. Microsoft’s Viva Insights documentation lists what it uses: for meetings, organizer, invitees, subject line, scheduled time and duration; for email, sender, recipients, subject line and sent time. Not attachments or message text.

Use it only for meeting-heavy workflows. Hours = meetings per week × length in hours × attendees. A weekly status review with eight people for an hour is eight hours of attendance, not the hours AI would save. Metadata cannot tell you what anyone did in the meeting or the thread.

**Effort to collect against how close the evidence is to the real work** (x: Effort to collect, 0 to 100; y: How close the evidence is to the real work, 0 to 100; corners: top-left Close to the work, cheap, top-right Close to the work, costly, bottom-left Far from the work, cheap, bottom-right Far from the work, costly)

- Asking people (for comparison): x 22, y 12
- Calendar and email metadata: x 34, y 36
- Timestamps and ticket history: x 30, y 64
- One-week time sample: x 58, y 76
- Observation or recording: x 86, y 92

Our reading, not a measurement. Left to right: from reading a log you already have to asking a team to change its week or install a recorder. Bottom to top: from what people say to what a system or screen recorded. The order matters more than the exact spot.

Our pick: take the case count from ticket history and the minutes per case from a time sample. Record two or three runs of the biggest workflow to check the sample. Use metadata only for meetings. If you can only do one, do the count first, because it is the cheapest and the least personal.

## How many observations is enough

For a time sample there is a table. Disney’s Appendix C gives the number of random observations needed to know a share of time within a stated margin, at 95% confidence. The margin is in percentage points of the share.

Observations needed at 95% confidence, from Appendix C of Disney (2016). The paper assumes observations at random times and a share that does not change during the study.

| Workflow’s share of time | Within ±10 points | Within ±5 points | Within ±2 points |
| --- | --- | --- | --- |
| 5% | 52 | 142 | 632 |
| 10% | 65 | 202 | 1,027 |
| 20% | 87 | 298 | 1,671 |
| 50% | 104 | 402 | 2,449 |

Read it this way. A team of nine pinged five times a day for five days gives 225 observations. If the workflow takes about 12% of their time, 225 is enough for ±5 points: the true share is probably between 7% and 17%. That is a wide range. On 360 paid hours it spans 25 to 61 hours.

So decide the margin you need from the decision, not from the table. If the range sits inside one hours band, stop. If it straddles a band edge that changes the answer, collect more, or replace the guess with a count from the log times a timed minute figure. Disney’s own procedure works in batches: collect 50, check the interval, collect another 50, and stop when it is tight enough.

> **Treat the table as a floor** The table assumes independent observations. Nine people pinged all week are not fully independent of each other, and one busy afternoon can move a share. That is our reading, not Disney’s finding. If the number matters, use more pings than the table says.

## Month-end, quarter-end and other spikes

1. **Read the spikes from the log, not the sample.** Chart cases per week for at least 12 weeks. The close week shows as a tall bar. A time sample in a normal week will never see it. Do this today: Do this today: chart one queue by week and mark the weeks that look different.
2. **Time the minutes in a normal week.** Minutes per case are usually steadier than volume. Measure them in a quiet week, then multiply by the real count for each week. Do this today: Do this today: pick the week for your time sample and check that no holiday or close falls in it.
3. **Score the average week, and write the peak beside it.** Average weekly hours over the month or quarter go in the template. The peak week goes in the notes, because an agent has to cope with it. Do this today: Do this today: add a “peak week hours” column next to the average.
4. **Spread rare jobs over the weeks.** A quarterly job that takes 130 hours is 10 hours a week on average (130 ÷ 13 weeks). Time it when it runs, with notice, or from its log.

## The measuring loop

**From a named workflow to a number you can score**

1. **Fix the unit**: Start, end, people, normal week
2. **Count cases**: Ticket history, 12 weeks
3. **Time a sample**: Time sample or recorded runs
4. **Multiply and add**: Cases × minutes, all people
5. **Check a second source**: Order of magnitude must agree
6. **Score it**: Hours column of the template

Then loop back: Re-measure when the work changes, and each quarter

When two sources disagree by more than a factor of two, you found an unlogged step, an exception or a bad sample. Settle that before you score.

## One workflow, three sources

> **Sample data** This workflow, team and every number below are invented to show the arithmetic. They describe no real company and are not industry figures.

Purchase order change requests, handled by a procurement team of nine. The team lead says “about 15 hours a week”. Each person has 40 paid hours, 360 in all. A month has three normal weeks and one close week.

Sample data. Hours score uses the template’s bands: 2 = 5 to 19 hours, 3 = 20 to 39, 4 = 40 to 79.

| Step | Source | Arithmetic | Result |
| --- | --- | --- | --- |
| Count | Ticket history, 12 weeks | Normal week 310 requests, close week 465. (3 × 310 + 465) ÷ 4 | 349 a week on average |
| Share of time | Time sample: 9 people, 5 pings a day, 5 days | 27 of 225 taps said “PO changes”. 27 ÷ 225. At 12%, ±5 points needs 224 (Disney) | 12%, so 7% to 17% |
| Hours, from the sample | Same sample | 12% × 360 paid hours. Range: 7% to 17% of 360 | 43 h (25 to 61 h) |
| Minutes per case | Six recorded runs by three people, with notice | 6, 7, 9, 9, 11, 12 minutes. Mean 9; range 6 to 12 | 9 minutes |
| Hours, from count × minutes | Log plus recordings | Normal week 310 × 9 ÷ 60. Average week 349 × 9 ÷ 60. Range at 6 and 12 min: 35 to 70 | 46.5 h normal, 52 h average |
| Cross-check | Sample against log × minutes | 43 against 46.5, one normal week each | Agree within 10% |

Both sources say 43 to 47 hours in a normal week, and 52 in an average one. Score 4. The ranges are wider than the central figures: the sample alone runs from 25 to 61, the recordings from 35 to 70. Both cross the 40-hour edge on the low side, so write the range in the notes and re-measure after the process changes.

The team’s guess of 15 hours would have scored 2. With Ease 4 and Risk 4, the template gives (3 × 4 + 2 × 4 + 2 × 4) ÷ 7 = 4.00 on the measured hours and 3.14 on the guess. One is “do now”. The other is “hold”. The workflow did not change. The number did.

## Put the number in the Hours score

The prioritization matrix template scores Hours from 1 to 5 on measured hours per week for the whole workflow. Its defaults, for a company of 50 to 5,000 people:

The template’s default Hours bands. Change them if you like, then keep them the same for every row.

| Hours score | Measured hours per week |
| --- | --- |
| 1 | Under 5 |
| 2 | 5 to 19 |
| 3 | 20 to 39 |
| 4 | 40 to 79 |
| 5 | 80 or more |

**Before the number goes in the sheet**

- [ ] Write how you measured it in the “How measured” column: Observed, System log, Time sample, or ESTIMATE.
- [ ] Write the range beside the figure. Score the middle. If the range crosses a band edge and the edge changes the decision, measure more first.
- [ ] A row marked ESTIMATE ranks below every measured row, whatever its score. That is the template’s rule 3.
- [ ] Score the average week, not the quiet one and not the close.
- [ ] Add up everyone on the workflow, not the fastest person.

Then the four-bucket sorter sorts the steps, and the guide to measuring AI impact covers the same hours after a change goes live. The hours you measure now are your baseline.

## Notice and privacy: settle these first

Counting cases from a log is the least personal method. A time sample, a recording and calendar data all say something about named people. Your company decides the notice, the legal basis and the exclusions, under its own policy and the law where your people work. This is not legal advice.

- [ ] Name the decision. “Which three workflows get an AI pilot.” If a data request does not feed it, drop the request.
- [ ] Write the notice employees will read. What is collected, from whom, for how long, who sees it. UiPath’s Task Mining documentation says the customer must notify employees, because UiPath has no technical way to identify or take consent from them. Microsoft’s Viva Insights page treats your company as the data controller and tells it to work with legal, privacy and HR, and to seek works council approval where one applies.
- [ ] Report by workflow and team, never by person. Say in writing whether the data may be used to judge individuals. If the answer is no, put that in the notice.
- [ ] Exclude before you capture. Password managers, banking, HR, health. Microsoft’s task mining documentation puts cleanup on you: delete screenshots and edit sensitive text out of a recording before analysis.
- [ ] Recording is continuous in at least one tool. UiPath’s lets users pause for up to an hour at a time and see which applications are recorded. Show people that before day one.
- [ ] Set a delete date and name one person who can delete. Read a first sample of raw data yourself before anyone else does.

## Where Nolli fits, and where it does not

Nolli is the watching-the-work method, built to run on its own. It learns how your company works from people’s work on company devices, the email and calendar your company connects, and the logs of the AI agents people use, then shows each opportunity’s value in hours and dollars with the evidence behind it. That replaces the one-week sample with continuous evidence. It is not a timesheet or a stopwatch, and it does not replace your system logs for exact case counts. Your company sets what Nolli may learn from and writes the employee notice, and your admin can see, correct, exclude, export or delete what it learned. No public price. Request a demo.

## Questions people ask

**How do you measure time spent per task in a workflow?**

Count the cases per week from system history, time a sample of them with a one-week time sample or recorded runs, and multiply. Add up everyone on the workflow. Check the result against a second source before you use it.

**How many observations does a time sample need?**

It depends on the share of time and the margin you want. At 95% confidence, Disney’s tables give about 200 random observations to know a 10% share within ±5 points, and about 400 for a 50% share. We found no source for how many timed runs estimate minutes per case.

**How do I handle month-end or seasonal peaks?**

Chart cases per week from the log for at least 12 weeks. Time the minutes per case in a normal week, multiply by the real weekly counts, score the average week, and note the peak week beside it.

**Do we need employee consent to record or sample work?**

That depends on your company’s policy and the law where your people work, so ask legal and HR, and a works council if you have one. UiPath’s documentation says the customer must notify employees, and Microsoft’s tells the data controller to decide on consent and notice. This is not legal advice.

**Can I use calendar and email data to measure hours?**

Only for meeting-heavy workflows, as meetings per week × length × attendees. It shows time spent in coordination, not what was done, and it is not the time AI would save.

## Sources

- Stephen M. Disney. "Revisiting activity sampling: a fresh look at binomial proportion confidence intervals (author’s version)." European Journal of Industrial Engineering, via Cardiff University ORCA, 2016; accessed October 19, 2026. https://orca.cardiff.ac.uk/id/eprint/91123/1/Revisiting.pdf
- John P. Robinson, Steven Martin, Ignace Glorieux and Joeri Minnen. "The overestimated workweek revisited." Monthly Labor Review, U.S. Bureau of Labor Statistics, June 2011. https://www.bls.gov/opub/mlr/2011/06/art3full.pdf
- Joel Becker, Nate Rush, Beth Barnes and David Rein. "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." METR, July 10, 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- "Advanced analysis privacy." Microsoft Learn (Viva Insights), accessed October 16, 2026. https://learn.microsoft.com/en-us/viva/insights/advanced/privacy/privacy
- "Protection of personal data and privacy of the users." UiPath Documentation (Task Mining), accessed October 16, 2026. https://docs.uipath.com/task-mining/automation-cloud/latest/user-guide/protection-of-personal-data-and-privacy-of-the-users
- "Protect your data." Microsoft Learn (Power Automate), accessed October 16, 2026. https://learn.microsoft.com/en-us/power-automate/process-advisor-protect
- "Field History Tracking Overview." Salesforce Help, accessed October 16, 2026. https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&language=en_US
- "Trust and governance." Nolli, accessed October 19, 2026. https://withnolli.com/security