InsightsProcess
Process

How to Do a Workflow Audit

What to log, what to look for, and what the patterns mean.

Savannah O'Byrne·April 2025·10 min read

A workflow audit is not a time-tracking exercise. It is not a productivity review. It is not a task manager setup or a process documentation session. Those are all useful things — but they are not this.

A workflow audit is three days of deliberate observation. You are not trying to optimize anything yet. You are not trying to identify solutions. You are watching where your work actually goes — and specifically, where you are the one making the handoff between steps that a system should be handling.

What you are looking for

Before you start logging, it helps to know what signal you are looking for. There are five patterns that matter in a workflow audit. You will see all of them. The question is: how often, and where.

  • Bottlenecks — work that only moves when you touch it. Tasks that are sitting, waiting, paused — not because they are blocked externally, but because you are the step that is missing.
  • Re-entry — the same information typed or copied into two different systems. A client name in the CRM and again in the project tool and again in the invoice. Every instance of re-entry is a place the workflow is not actually connected.
  • Decision weight — choices you make repeatedly that follow the same logic every time. Which template to use. Which client gets priority. Which deliverable ships first when two are due on the same day. If you are making the same decision more than twice a week, it can probably be encoded.
  • Memory dependency — knowledge that only exists in your head. The context about a client that is not in any field. The fact about a project that you know but have never written down. Every time you rely on memory instead of a record, that memory is a single point of failure.
  • False automation — tools that appear to be handling something but still require you to intervene regularly. A Zapier flow that works most of the time but needs babysitting for edge cases. An automation that runs but produces outputs in the wrong format. The presence of automation does not mean the bottleneck is closed.

What to log

For three working days, keep a running log of your actual work. Not a to-do list. Not a summary of what went well. A log of what actually happened, as it happened — or as close to real-time as you can manage.

For each thing that happens, capture: what you did, what triggered you to do it, what tool or place you did it in, what you had to know or remember to do it, and what happened next. You do not need a fancy format. A running document works fine. Voice memos that you transcribe later work fine. Whatever keeps you logging without making the logging itself become the work.

Pay particular attention to anything that required you to open something, copy something, translate something, or remember something. Those are almost always a re-entry or a memory dependency in disguise.

What to pay attention to

There are specific moments that are worth flagging in your log as you go:

  • Any moment where you thought 'I need to remember to...' — this is a memory dependency.
  • Any moment where you opened more than two tabs to do a single task — this is usually a re-entry or a bottleneck.
  • Any moment where you waited for yourself — where you were the reason something had not moved — this is a bottleneck.
  • Any moment where you made a decision that felt like it should have been obvious — where you wondered why there was no rule for this — this is a decision weight candidate.
  • Any moment where a tool produced an output you then had to manually process before it was usable — this is often false automation.

What the patterns mean

After three days, you will have a log. The next step is to look at it as a whole — not task by task, but pattern by pattern. You are asking: where is this actually concentrated?

Most founders discover that the friction is not evenly distributed. There are two or three workflow areas that account for the majority of the manual effort. Client intake, project delivery, and knowledge management are the most common. The audit shows you which areas are yours.

Once you can see the patterns, you can start asking what should change. The options are not all the same:

  • Automate — some handoffs are simple enough that a trigger-action rule can close the gap. These are usually re-entry problems with stable inputs.
  • Replace — some tools are doing more harm than good. They are creating handoff points without solving the underlying problem. These are candidates for rebuilding.
  • Protect — some manual steps should stay manual, because the judgment involved is too context-specific to encode. Not everything should be automated.
  • Connect — some tools just need better bridges. Not a full rebuild, but a defined integration that reduces the gap.
  • Keep — some things that feel like friction are actually fine. The audit reveals both problems and non-problems.

The free version of this

The Workflow Automation Audit that Prymetheus offers is a structured version of exactly what is described in this article. The same three days of intentional logging, the same five pattern types, the same interpretive framework. The difference is the Audit Review Call — 30 to 45 minutes where Savannah interprets what the audit produced and makes a specific recommendation for what to do with it.

If you want to run the audit yourself and sit with the findings, everything in this article is enough to start. If you want a second pair of eyes on what you find, the free Audit is the place to start.

Start Here

The first step is free.

The Workflow Automation Audit is a free three-day intentional logging process. No passive tracking. No background monitoring. Just three days of watching where your work actually goes — and a 30–45 minute call to interpret what it shows.

Start the Audit →
Tell us where the work is getting stuck

Start your project.

You don't need to know whether your problem is software, automation, integration, or AI — that's our job to figure out. Describe the bottleneck in plain terms, and we'll tell you what could be built and what it would take.