# How to find AI use cases without sending a survey

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

Canonical page: https://withnolli.com/blog/find-ai-use-cases-without-employee-surveys

**Short answer.** Take the evidence from the work instead of asking people to guess. Five sources need no questionnaire: system logs and ticket history, calendar and email metadata, a one-week time sample, existing documents and SOPs, and observation of the work. Each sees a different slice and costs a different amount of effort and privacy. Merge them into one row per workflow, then rank.

## Key takeaways

1. Studies of time estimates and of AI’s benefit found people’s guesses off, sometimes in the wrong direction, and a use case survey rests on exactly those guesses.
2. Logs, calendar and email metadata, a one-week time sample, documents and direct observation each see a different slice; the closer to the work, the more they cost in effort and privacy.
3. Merge the evidence into one row per workflow, add measured hours, rank with the prioritization template, and use conversations afterwards to explain numbers you already hold.

Skip the survey. Pull evidence from the work itself. Five sources do it, none needs a questionnaire, and the cheapest two you can start on today.

These notes say what each source shows, what it misses, and what it costs in effort and privacy. We read the studies and vendor documents cited below on October 16, 2026, and ran none of the tools. We did not find a study that sets a survey’s list of AI use cases against a list built from logs or observation. So the case against surveys below is an argument from nearby evidence, and we mark where it stretches.

## Why a survey gives you a shaky list

A use case survey asks two things: how long does this take you, and where would AI help. Both are estimates. Here is what four bodies of evidence say about estimates like those.

- **20% faster felt, 19% slower measured**: How 16 experienced open-source developers rated their speed with AI after 246 of their own real tasks, against the clock. Before the trial they expected to be 24% faster. The tools were early-2025 ones, and METR now calls the results out of date. (source: METR, July 10, 2025, https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
- **55.7 s predicted, 7.5 s saved**: Average time people predicted an AI chatbot would save on simple tasks, against the time it saved, in Study 2 of three pre-registered studies (2,691 people in all). The same paper found people believed they used AI less than they did. A preprint. (source: Yu and colleagues, arXiv 2605.22687, https://arxiv.org/html/2605.22687)
- **5 to 10% too high**: How far employed people overstate their work hours when asked to estimate them, against the time diaries they also filled in. Data: the American Time Use Survey and a Belgian national weekly-diary survey. The gap is in total work hours, not in tasks. (source: Robinson, Martin, Glorieux and Minnen, Monthly Labor Review, June 2011, https://www.bls.gov/opub/mlr/2011/06/art3full.pdf)
- **52.7%**: Average response rate for surveys of individuals in 490 studies from 17 academic journals, published in 2000 and 2005 (standard deviation 20.4). These are research surveys, not internal company ones. (source: Baruch and Holtom, Human Relations, 2008, https://journals.sagepub.com/doi/abs/10.1177/0018726708094863)

Read these as a pattern, not as proof for your company. Two studies are about AI on coding work or toy tasks. One is about total hours of work. None asks employees where AI should go. What they share is the thing a use case survey depends on: a person’s estimate of time and of benefit, with no clock to check it against. A 2021 meta-analysis of 106 effect sizes found the same gap for something else, digital media use: self-reports correlated only moderately with logged use and were rarely accurate.

Then half the company has to answer. METR’s 2026 survey of 349 technical workers drew about 2% of the people it emailed, and METR warns of selection bias in its own sample. Published research surveys of individuals average about half, per Baruch and Holtom above. We found no response rate for internal AI use-case surveys, so we give none.

> Work-as-disclosed, meanwhile, is partial and often biased.
> — Steven Shorrock, “The Varieties of Human Work”, Humanistic Systems, 2016, https://humanisticsystems.com/2016/12/05/the-varieties-of-human-work/

> **Where a survey still earns its place** METR, whose trial is cited above, calls surveys a flawed but useful complement to other evidence. Our measure-impact guide says the same: self-reports show where people feel helped and where to look next. Use conversations to explain numbers you already hold. Do not use them to produce the numbers.

> **What we looked for and did not find** A head-to-head study of a survey against logs or observation for picking AI use cases. A response rate for internal AI use-case surveys. A checked sample size for a one-week time sample of office work. Where a number is missing below, it is missing on purpose.

## Five sources, no questionnaire

Work leaves evidence in places people do not have to describe. Five of them, listed from reading what already exists to watching the work. Start at the top.

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

| | Logs and tickets | Calendar and email metadata | One-week time sample | Docs, SOPs, wikis | Watching the work |
| --- | --- | --- | --- | --- | --- |
| How often the work happens | fully | partly | partly | none | partly |
| How long a step really takes | partly | partly | fully | none | fully |
| Work between apps and in spreadsheets | none | none | partly | none | fully |
| Who works with whom | partly | fully | none | partly | partly |
| Why a person chose that way | none | none | none | partly | partly |
| Steps nobody wrote down | partly | none | partly | none | fully |
| Cheap to repeat next quarter | fully | fully | none | fully | partly |

Our reading from the sources and documents cited on this page, not a measurement. Full: the source shows it by itself. Half: it shows part of it, or only for some workflows (logs give elapsed time, not effort; shadowing shows why, a silent recording does not). Empty: it does not show it. Any source can be set up to show more than this.

### 1. System logs and ticket history

Open the ticket tool, the CRM or the ERP. Export recent closed cases with created, assigned, status-change and closed times, plus category and team. Count cases per category per week. Look at the time between status changes. This is the event log that process mining reads, and the system of record is where it lives.

It gives you how often each kind of case happens, who touches it, and where it waits. It misses everything outside the system, such as the spreadsheet beside the CRM, and it misses effort. A case that sat open four days may have taken ten minutes. Check how far back the history goes, too. Salesforce, for example, keeps field history for up to 18 months (24 through the API) unless Field Audit Trail is on, tracks a field only from the day you switch it on, and for long text fields records that an edit happened but not what it said.

> **Start** Pick the one queue with the most cases. Export it. Count by category before you read a single case. Cost: the lowest effort of the five if you have admin rights. Records carry names and often customer text, so ask the system owner before the export leaves the tool.

### 2. Calendar and email metadata

Ask IT for meeting and email headers, never bodies, for one team over a quarter. Microsoft’s Viva Insights documentation shows what that looks like. For email it uses sender, recipients, subject line and sent time. For meetings it uses organizer, invitees, subject line, scheduled time and duration. It never uses attachments or message text. It adds up how much time groups spend in meetings, email, calls and chats, and with whom.

That is a cheap, wide view of coordination: recurring status meetings, long threads, two teams that write to each other all day. Each one is a place to look for AI help. It is a lead, not a finding. It cannot say what anyone did in the meeting or the thread.

Metadata is still personal data. It shows who talks to whom, and subject lines can name customers and colleagues. Microsoft’s page treats your company as the data controller and tells it to work with legal, privacy and HR on whether to get employee consent and what to tell employees, and to seek works council approval where one applies. We read only Microsoft’s documents. Another mail system may export different fields.

### 3. A one-week time sample

Ping a team at random moments for one week. Ask one thing: what are you doing right now? The answer is a pick from a short list of their workflows, plus “something else”. After the week, the share of answers per workflow estimates the share of time.

This is activity sampling, also called work sampling, an old industrial engineering method. A 2016 paper in the European Journal of Industrial Engineering calls it relatively inexpensive, usable on long, varied and intermittent work, and more acceptable to the people studied than a stopwatch. The same paper says it is not efficient for short, regular, predictable activities.

It is still self-report. The difference is the recall window. People name what they are doing this second, not what an average week looks like, and nobody adds up hours from memory. The Bureau of Labor Statistics authors make the same case for time diaries, which shorten recall, and they add that diaries can still be distorted. Misses: rare events (the month-end close will not fall in your week), the reason behind a choice, and precision when pings are few. That paper has tables for how many observations a stated precision needs. We did not check them, so we give no number.

> **Start** One team. Three to five workflows you suspect, listed with the team lead. One working week with no holiday in it. One tap per ping. Report shares by team, never by person. Cost: a few seconds of attention, many times a day, and a record of what each person says they were doing.

### 4. Existing documents, SOPs and wikis

Read what already exists: SOPs, onboarding guides, runbooks, wiki pages, templates, the macros people share. Pull out step names, systems, owners, approval rules and the words people use for the work.

You get a list of workflows and a first draft of each. You do not get how often or how long, and you do not get the workarounds. Shorrock separates work as prescribed, the version in procedures, from work as done, and writes that procedures are “often far from reality”. A page last edited two years ago, for a process that changed last spring, shows what the work used to be. Treat every document as a claim to check against a log or a recording.

> **Start** Make a table: workflow, document, last edited, steps in the document. Leave one empty column for steps you later see in the logs. Cost: low effort and the lowest privacy cost of the five, though documents can hold customer data and credentials. Skim for those first.

### 5. Watching the work

Three ways, in rising order of cost: a person screen-records one run of a workflow and sends it to you, task mining software records clicks, keystrokes and sometimes screenshots on employees’ machines, or someone shadows a worker and takes notes. All three give you the order of the steps, the real durations, the work between apps and the exceptions.

They miss the reason, unless a person sits next to the worker and asks. They miss days and people you did not record, and anything done on paper or another device.

This is also where the privacy cost peaks. UiPath’s Task Mining documentation says its recorder captures screenshots, keyboard actions, clicks and movements, and that recording is continuous. Users can pause for up to an hour at a time and see which applications are recorded. The customer is the controller and must tell employees, because UiPath says it has no technical way to identify or take consent from them. The documentation says personal data is masked during processing and that UiPath also uses the data to check its machine learning. Microsoft’s task mining documentation puts cleanup on you: you delete screenshots and edit sensitive text out of a recording yourself before analysis. Compare the tools in best task mining software in 2026, and see what task mining cannot see in process mining vs task mining vs AI discovery.

Shadowing costs the most per hour. A BMJ Open study of administrative work in six English general practices spent 330 hours on ethnographic observation of 65 staff, coded the tasks, then had 156 automation experts rate how automatable they were. That is research grade. Your first pass can be a fraction of it.

> **Start** One workflow. Three to five people who do it. One full cycle of the work. Show them what is captured and how to pause it. Read the first captures yourself before anyone else sees them.

> **This is the source your legal team will care about most** The notice, the consent rules and the exclusions are your company’s decision, under your company’s policy and the law where your people work. This post is not legal advice.

## What each one costs

Effort and privacy cost are our reading of the sources above. “Ask first” is who a sensible company would ask; your policy decides.

| Source | Effort to start | What it exposes about people | Ask first |
| --- | --- | --- | --- |
| Logs and tickets | Lowest if you have admin rights; the data exists already | Names on cases, and often customer text | The system owner |
| Calendar and email metadata | Low with a tool you license; an export needs an admin | Who talks to whom and when, plus subject lines (Microsoft’s tool excludes message text) | Legal, privacy, HR, and a works council where one exists |
| One-week time sample | Medium: people answer a prompt many times a day for a week | What each person says they were doing | The team, before the week starts |
| Documents, SOPs, wikis | Low | Rarely personal; may hold customer data or credentials | The document owners |
| Watching the work | High: install, notice, review, cleanup | Whatever is on the screen, unless excluded or masked | Everyone recorded, in writing, and legal first |

**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)

- Survey (for comparison): x 25, y 12
- Documents and SOPs: x 12, y 26
- Calendar and email metadata: x 30, y 40
- Logs and tickets: x 36, y 66
- One-week time sample: x 60, y 74
- Watching the work: x 88, y 92

Our reading, not a measurement. Left to right: from reading what exists to asking a team to change its week or install a recorder. Bottom to top: from what people say to what systems and screens recorded. The order of the dots matters more than the exact spot. Calendar and email metadata is the odd one: far from the work, close to people.

Our pick: start with documents and logs. They are the cheapest and the least personal, and together they give you a list of workflows and counts. Add a time sample on the top few. Watch one workflow, once, with notice, when a number still looks wrong.

## Before you start collecting

**Notice, scope, who sees what**

- [ ] Name the decision. One line: “which three workflows get an AI pilot.” If a data request does not feed it, drop the request.
- [ ] Choose the workflows and teams. Collect nothing outside them.
- [ ] Write the notice employees will read: what is collected, from whom, for how long, and who sees it. Your company decides the wording and the legal basis. Ask legal and HR, and your worker council if you have one.
- [ ] Decide who sees raw data and who sees only summaries. Show leaders workflows and patterns, not individual people.
- [ ] Say in writing whether the data may be used to judge individuals. If the answer is no, put that in the notice.
- [ ] Exclude sensitive apps, sites and folders before capture: password managers, banking, HR, health.
- [ ] Set a delete date and name one person who can delete.
- [ ] Read a first sample of the raw data yourself, before anyone else does.

## From evidence to a ranked backlog

**Evidence in, ranked list out**

1. **Collect**: Start with documents and logs
2. **One row per workflow**: Named the way the people name it
3. **Add measured hours**: Count from a log, minutes from a sample
4. **Sort the steps**: Delete, code, agent or human
5. **Score**: Hours, ease, risk
6. **Ranked backlog**: One owner per row

Then loop back: Collect again when the work changes

The same chain whichever sources you use. The score step is the prioritization matrix template.

1. **Merge the evidence into one table.** One row per workflow, named the way the people who do it name it. Columns: owner, what each source says, and how each number was measured. Do this today: Do this today: copy the workflow names from your SOP list into a sheet and add a column per source.
2. **Work out hours from the best evidence.** Take the case count from a log and the minutes per case from a time sample or a recording. Multiply, add up everyone on the workflow, and write the arithmetic beside the number. A number that comes from memory or one conversation gets marked ESTIMATE. Do this today: Do this today: take your busiest queue and multiply its weekly cases by minutes per case.
3. **Check two sources against each other.** A log count and a time sample should agree on the order of magnitude. When they do not, you found something: an unlogged step, an exception, or a bad sample. Settle it before you rank. Do this today: Do this today: ask the team lead about your biggest gap.
4. **Sort the steps into the four buckets.** Delete, plain code, agent or human, from the steps you saw, not the steps in the SOP. The free four-bucket sorter does it. Do this today: Do this today: sort one workflow’s observed steps.
5. **Score and rank.** Score hours, ease and risk with the AI use case prioritization matrix template. Do first what scores 4.0 or more. ESTIMATE rows rank below measured ones. Do this today: Do this today: paste your rows into the template sheet.
6. **Run it again.** Work changes, so collect again when a workflow changes and score again each quarter, as the template post advises.

> **Sample data** The rows below are invented to show the arithmetic. They describe no real company.

Sample data. Hours score uses the template’s scale: 3 = 20 to 39 hours a week, 4 = 40 to 79. Meeting hours show where to look. They are not hours AI would save.

| Workflow (sample) | Evidence | Hours a week | Hours score |
| --- | --- | --- | --- |
| Refund requests | Ticket log: 420 a week. Time sample: 6 minutes each. 420 × 6 ÷ 60. | 42 | 4 |
| Weekly status deck | Calendar: 5 recurring 30-minute status meetings, 8 people each, 5 × 0.5 × 8 = 20. Time sample: 3 hours building the deck. | 23 | 3 |
| Contract clause review | Contract tracker: 60 a week. Recording of 4 reviews: 25 minutes each. 60 × 25 ÷ 60. | 25 | 3 |

Talk to people last, with the table in hand. “Why does a refund take six minutes?” is a question about a number you hold. It gets a better answer than “where could AI help?”. For the wider method, see how to find where AI belongs and how to map a process for AI.

## Where Nolli fits, and where it does not

Nolli is the watching-the-work source, built to run on its own. It learns how your company works from people’s work on company devices, from the email and calendar your company connects, and from the logs of the AI agents people use, then shows where AI belongs and what it is worth. It is not a survey. Every finding links back to its evidence. It does not replace your system logs: it is not an ERP event-log process mining suite, so use the logs for exact case counts. It does not write your employee notice or set your policy. Your company decides what Nolli may learn from, and your admin can see, correct, export or delete what it learned. No public price. Request a demo.

## Questions people ask

**How do you find AI use cases without a survey?**

Collect evidence from the work: system logs and ticket history, calendar and email metadata, a one-week time sample, existing documents and SOPs, and observation. Merge it into one row per workflow, add measured hours, and rank the rows with a scoring template.

**Is a one-week time sample just a survey?**

It asks a question, but about this moment, not an estimate of a typical week. People pick what they are doing from a short list, and the share of answers estimates the share of time. It is still self-report, so check it against a log where you can.

**Do we need employee consent to use logs, calendars or recordings?**

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

**Which source should we start with?**

Documents and system logs. They are the cheapest and the least personal, and they give you a list of workflows and counts. Add a time sample on the top few, and watch one workflow only when a number still looks wrong.

**Are surveys ever useful for AI use cases?**

Yes, after the evidence. METR calls surveys a flawed but useful complement to other evidence. Use conversations to explain numbers you already have, and do not use them to produce the numbers.

## Sources

- 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/
- Sunny Yu, Myra Cheng, Ahmad Jabbar, Ilia Sucholutsky, Katherine M. Collins, Dan Jurafsky and Robert D. Hawkins. "The efficiency-gain illusion: People underestimate the rate of AI use and overestimate its benefits on simple tasks." arXiv 2605.22687 (preprint), May 2026; accessed October 16, 2026. https://arxiv.org/html/2605.22687
- Joel Becker. "Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity." METR, May 11, 2026. https://metr.org/blog/2026-05-11-ai-usage-survey/
- 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
- Douglas A. Parry and colleagues. "A systematic review and meta-analysis of discrepancies between logged and self-reported digital media use." Nature Human Behaviour, May 17, 2021. https://www.nature.com/articles/s41562-021-01117-5
- Yehuda Baruch and Brooks C. Holtom. "Survey response rate levels and trends in organizational research." Human Relations, 2008. https://journals.sagepub.com/doi/abs/10.1177/0018726708094863
- Steven Shorrock. "The Varieties of Human Work." Humanistic Systems, December 5, 2016. https://humanisticsystems.com/2016/12/05/the-varieties-of-human-work/
- 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. https://orca.cardiff.ac.uk/id/eprint/91123/1/Revisiting.pdf
- "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
- Matthew Willis, Paul Duckworth, Angela Coulter, Eric T Meyer and Michael Osborne. "Qualitative and quantitative approach to assess the potential for automating administrative tasks in general practice." BMJ Open, 2020. https://bmjopen.bmj.com/content/10/6/e032412
- "Trust and governance." Nolli, accessed October 16, 2026. https://withnolli.com/security