# Identifying AI opportunities with a workplace process audit [Skip to content](#lm-inhoud)Network/NL[EN](/en/)[Hubhub.llmnet.nlCompare models by task, language, cost and license.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs robust in software: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlIntroducing AI in an organization, from pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlDevelopments in AI, interpreted for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, for your own tasks.](https://benchmark.llmnet.nl/en/)[Jobsvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, from beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for people who build their own.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fai-kansen-identificeren-met-een-procesaudit-op-de-werkvloer&text=AI-kansen%20identificeren%20met%20een%20procesaudit%20op%20de%20werkvloer)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fai-kansen-identificeren-met-een-procesaudit-op-de-werkvloer)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fai-kansen-identificeren-met-een-procesaudit-op-de-werkvloer&title=AI-kansen%20identificeren%20met%20een%20procesaudit%20op%20de%20werkvloer)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fai-kansen-identificeren-met-een-procesaudit-op-de-werkvloer&text=AI-kansen%20identificeren%20met%20een%20procesaudit%20op%20de%20werkvloer)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fai-kansen-identificeren-met-een-procesaudit-op-de-werkvloer)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fai-kansen-identificeren-met-een-procesaudit-op-de-werkvloer&title=AI-kansen%20identificeren%20met%20een%20procesaudit%20op%20de%20werkvloer)[](#) # Identifying AI opportunities with a workplace process audit By Ivo Donker — compiled with AI assistance (Claude & Gemini) Many artificial intelligence initiatives fail not because of technical shortcomings in algorithms or language models, but because of a fundamental mismatch between the chosen problem and operational reality. Leadership teams and innovation teams regularly select use cases based on an abstract urge to adopt technology or theoretical assumptions about how departments function. When we look at day-to-day practice, however, work processes often turn out to be full of undocumented exceptions, scattered manual corrections, and informal working arrangements. A theoretical design rarely accounts for this. To prevent an organization from investing in solutions for bottlenecks that don't actually exist, a workplace process audit is the appropriate method. Such an audit looks beyond process descriptions in manuals and systematically maps how employees actually perform tasks. Before an organization starts an audit, it's advisable to measure the general readiness of its systems and culture using the [AI maturity scan for organizations](https://consultancy.llmnet.nl/en/ai-volwassenheidsscan), which sharpens the starting position and preconditions in advance. ## The need for observation versus interviews A workplace process audit differs fundamentally from a series of traditional interviews. When employees are asked about their daily work in a meeting room, they almost always give a rationalized version of the process. People describe the process as it was once intended, or how they think it should run. Subtle actions — such as manually retyping fields between systems, looking up missing data in mailboxes, or correcting automatic exports — are often left out because people consider them self-evident routine actions. Observing the workplace itself, also known as 'gemba walking' or shadowing, immediately exposes these hidden steps. By sitting next to an operational employee and watching their screen, frictions and micro-interruptions become visible that never make it into process documentation. It's precisely in these repetitive, time-consuming, and error-prone steps that the most profitable opportunities for automation with language models or machine learning often hide. Observation also prevents automating something that's actually unnecessary. A process step that exists purely to mask a shortcoming in outdated software doesn't necessarily need to be solved with AI; process optimization or a simple API integration is often more effective and cheaper in that case. By physically following the process, a clear distinction emerges between process flaws, classic automation issues, and genuine AI opportunities. ## The process-audit framework: breaking tasks down into five dimensions To objectively assess operational processes for their suitability for AI, we break down every task along five specific dimensions. This prevents a use case from being selected purely on intuition or enthusiasm. We categorize the task characteristics as follows: Dimension | Assessment question | Unsuitable for AI | Promising for AI | 1. Determinism | Is there always exactly one correct answer according to hard rules? | Strict calculation rules, static validations (use regular code). | Text comprehension, interpreting context, summarizing, classification. | 2. Data structure | In what form does the input arrive and leave the task? | Already perfectly structured SQL tables and fixed XML files. | Unstructured text, emails, PDF reports, free-text input fields. | 3. Error tolerance | What is the operational damage of a 2% deviation? | Direct legal or financial damage without human review. | Draft proposals, ticket routing, internal searches. | 4. Frequency & volume | How often is the task performed per day or week? | One-off ad-hoc tasks or very rare exceptions. | Daily recurring work with repeated patterns and recognizable context. | 5. Knowledge intensity | What context is needed to successfully perform the task? | Entirely implicit intuition with no transferable documentation. | Knowledge documented in manuals, guidelines, historical tickets, and policy. | When a task scores high on unstructured data and knowledge intensity, while at the same time having manageable error tolerance (for example through a human validation step), a strong candidate emerges. Tasks that are purely deterministic belong in traditional software development or Robotic Process Automation (RPA), not in a complex, non-deterministic AI project. ## The audit approach in four consecutive phases A thorough process audit follows a fixed sequence to minimize wasted operational hours. In practice, we go through the following four phases: ### Phase 1: Selecting and scoping the department Don't start with an organization-wide inventory; that produces too much noise. Choose one specific department where a lot of textual communication, case-file building, or customer interaction takes place, such as inside sales, accounts receivable, or the support desk. Map out the formal process flow as a reference framework. ### Phase 2: Shadowing at the workplace Observe at least three to five different employees for half a day each during their regular work. Note which applications are open, how often they switch between screens, where data is copied from, and which informal tools (such as personal notes, Excel lists, or scratchpads) are used. ### Phase 3: Bottleneck and data inventory For each process step, analyze where delays arise and what the underlying data sources are. Immediately assess whether this source data is digitally accessible, whether there is data pollution, and whether privacy-sensitive information is involved. A thorough exploration of the legal frameworks is crucial here; consult [AI models and privacy choices for GDPR compliance](https://hub.llmnet.nl/en/ai-modellen-en-privacy-avg-compliance) to verify which legislation the processing of personal data within language models must comply with. ### Phase 4: Synthesis and use case formulation Translate the observed bottlenecks into concrete use cases. For each use case, describe exactly what the input is, which operation the model must perform, what the desired output is, and who checks the output. You can then methodically [prioritize the first AI use case for your organization](https://consultancy.llmnet.nl/en/ai-usecases-prioriteren) based on feasibility, strategic value, and technical complexity. ## Documenting the 'shadow processes' During observations, the auditor almost always encounters so-called 'shadow processes.' These are informal routines that employees have developed themselves to work around formal system limitations. Think of an employee who routinely copies incoming emails into their own draft file to manually summarize them, or a specialist who keeps a local Word document with standard answers because the central CRM system lacks a search function. These informal routines are gold mines for an AI audit. They show exactly where the formal system falls short and which cognitive tasks the employee experiences as burdensome. Documenting these steps clarifies which contextual knowledge is needed to complete the task. Pay attention to: - Where does the employee cut and paste text between different windows? - Which documents are repeatedly opened to make a single decision? - At which moments does an employee ask a direct colleague for verbal advice due to a lack of documentation? - Which exceptions to the standard procedure occur daily, and how are they recorded? ## Data audits in the workplace: theory versus reality A use case may look excellent conceptually, but it hinges on the quality and availability of the data. During the audit, the actual state of the data must be tested directly at the source. Formal documentation may state that customer files are complete, but inspection on the shop floor often reveals that crucial explanations are missing, text fields are full of typos, or information is stored in low-quality scanned PDF files. See also the guide on [data quality for AI and preventing stalled pilots](https://consultancy.llmnet.nl/en/datakwaliteit-voor-ai) to understand how polluted data can derail a pilot prematurely. The audit team should sample at least fifty historical files or transactions. Check whether the input data is consistent enough to provide a model with context. When documents vary strongly in structure, this immediately creates an extra challenge for the extraction layer. The availability of metadata (such as dates, categories, and authors) must also be checked. Without reliable metadata, finding and filtering the right documents within a retrieval system becomes considerably more complex. ## Safeguarding critical tasks and human oversight Not every operational bottleneck lends itself to autonomous handling. Especially for processes with significant financial, medical, or legal risks, an automated final decision is irresponsible. During the audit, it must therefore be documented for each identified task how the human validation step is set up. Read how you can [set up human-in-the-loop processes for critical tasks](https://consultancy.llmnet.nl/en/human-in-the-loop-processen-inrichten-voor-kritieke-taken) to ensure that employees review drafts and flag deviations at the right moment. Setting up such a control layer prevents faulty model output from silently trickling through to customers or external systems. By positioning employees as substantive reviewers rather than manual typists, domain expertise is preserved while operational processing speed increases. ## Measuring time spent and turnaround time To later build a reliable business case, the audit must produce actual time measurements. In practice, employees' estimates of their own time spent often deviate thirty to fifty percent from reality. People overestimate routine tasks they find tedious, and underestimate tasks that occur in small chunks spread throughout the day. During the process audit, the auditor measures the actual 'touch time' (the time an employee is actively working on the file) versus the 'wait time' (the time a file sits idle between two processing steps) using a stopwatch or anonymized time-tracking records. AI primarily speeds up the active processing time of information. However, if the total turnaround time of a process is dominated by wait times for external approvals, automating the processing task ultimately delivers little turnaround-time reduction for the end customer. Then use this measurement data to [calculate the ROI of AI using a practical framework](https://consultancy.llmnet.nl/en/ai-roi-berekenen) so you can weigh investment costs against real time savings in advance. Touch Time vs. Doorlooptijd Meting: ----------------------------------------------------------------- Stap 1: Intake & Classificatie -> Touch: 12 min | Wachttijd: 4 uur Stap 2: Context Verzamelen -> Touch: 25 min | Wachttijd: 1 dag Stap 3: Concept Reactie Maken -> Touch: 18 min | Wachttijd: 2 uur Stap 4: Review & Goedkeuring -> Touch: 5 min | Wachttijd: 3 uur ----------------------------------------------------------------- Totale actieve bewerkingstijd : 60 minuten Totale doorlooptijd dossier : ~28 uur Potentieel bereik AI-ondersteuning: Stap 1, 2 en 3 (55 min bewerking) ## Typical pitfalls during an operational audit Conducting a workplace process audit carries specific risks that can distort the outcome. We identify the following common pitfalls: - The Hawthorne effect: Employees work more precisely and stick more strictly to the rulebook when someone is watching. This can be mitigated by spreading audits across multiple days and creating a relaxed, non-supervisory atmosphere. - Confusing volume with value: A task that occurs very frequently doesn't automatically deliver the most value. Generating simple acknowledgment emails takes little time and resolves little friction, while summarizing complex legal disputes at low volumes actually saves enormous amounts of specialist hours. - Focusing on 100% automation: The goal of deploying AI is rarely to make an employee completely redundant. Use cases that aim for 'copilot' functionality (generating drafts that are validated by a human) have a much higher success rate than 'lights-out' automation without human review. - Not accounting for exceptions: In theory, 80% of the work follows the main path. In practice, the 20% exceptions cause 80% of the operational delay. If an AI solution doesn't know what to do with exceptions, the process gets clogged. ## From observation to a well-defined project Once the audit is complete and the bottlenecks have been analyzed, the selected opportunities must be translated into a concrete assignment. This is the step where vague wishes are definitively converted into measurable goals, technical frameworks, and acceptance criteria. See the guide on [scoping an AI project from a vague question to a well-defined assignment](https://consultancy.llmnet.nl/en/ai-project-scoping) to ensure the technical and functional scope aligns seamlessly with the audit's findings. The output of the audit forms the foundation of the project file. By documenting in advance which source documents are used, what the current manual processing time is, and what margin of error is acceptable, the organization has an objective baseline measurement. Only with such a baseline can it be demonstrated after implementation whether the technology actually delivers the intended time savings and quality improvement. ## Checklist for the process auditor Use the checklist below during the preparation and execution of the workplace audit to ensure all operational aspects are covered: - [ ] Has the department been informed in advance that the audit focuses on process friction and not on individual employee evaluation? - [ ] Have at least three different employees with the same task package been observed? - [ ] Has the actual touch time per file been measured with a stopwatch or a sample? - [ ] Have all informal tools (local files, scratchpads, email folders) been mapped? - [ ] Has the source data been checked for digital readability, consistency, and missing fields? - [ ] Have the exceptions and escalation paths been explicitly documented? - [ ] Has it been determined which validation step is needed before a model's output may be used in production?