Most automation projects can't prove they worked

Twenty-five projects since 2023. Seventeen automations, eight marketing. When I sat down to build this portfolio, I could prove one of them.

Not because the other twenty-four failed. Plenty of them worked. Real clients, real testimonials, some of them five stars. I just had no idea by how much. I knew a business owner had got hours back. I couldn't tell you how many, because nobody had counted them before I started.

That's not a story about me being disorganised. It's the normal condition of this industry, and it's worth understanding why.

The window closes on day one

Every automation project has a moment where the baseline is available, and it's short. It sits between the client describing the problem and you starting to solve it.

In that window you could time the task. Count the messages. Export the last ninety days from their CRM. It takes an afternoon.

Nobody does it, and the reason isn't laziness. It's that the afternoon feels wasted. The client is paying you to build something. Sitting with a stopwatch watching someone assemble a quote by hand looks like the opposite of progress. So you skip it, you build the thing, it works, everyone's pleased.

Then eighteen months later you want to write it up, and the before is gone. Not hard to find. Gone. It never existed as a number. The best you can do is ask the client to estimate something they stopped doing a year and a half ago.

What you say instead

Look at any automation agency's website and you'll find the same vocabulary. Streamlined. Optimised. Transformed their workflow. Reduced manual effort. Saved countless hours.

Countless is doing a lot of work in that last one.

These aren't lies. They're what's left when you have a real result and no measurement of it. The system genuinely does the job. You genuinely made things better. You just can't say by how much, so you reach for a word that sounds like a number without being one.

The problem is that every competitor reaches for the same words, and the buyer has read all of them. Nobody's website says the automation was mediocre. So the adjectives cancel out and the buyer decides on price, or on whoever seemed nicest on the call.

The uncomfortable part

Here's what I think most people in this field would rather not say out loud: if you can't state the before, you don't actually know whether the project worked.

Not "you can't market it well." You don't know.

You know the system runs. You know nobody's complained. You know the client seems happier. All of that is compatible with having moved a task from one place to another without saving anyone meaningful time. That happens more than the industry admits, particularly when automation gets layered onto a process that was broken to begin with.

I've built things that were technically excellent and commercially pointless. The tell, every time, was that I couldn't say what changed.

What measuring first actually does

I now measure the before on every project, and the reason isn't the case study. Three things happen that I didn't expect.

Some projects stop before they start. You count how often the task actually happens, multiply by how long it takes, and discover the prize is four hours a year. That conversation is uncomfortable for ten minutes and saves everyone six weeks.

The real problem moves. Clients ask you to automate the step that annoys them, which is rarely the step that costs them. Watching the work reveals that the quote takes three days not because writing it is slow, but because it waits two days for one approval. No automation fixes that. A conversation does.

The scope shrinks. When you know which number you're moving, everything that doesn't move it becomes visibly optional. Most of what gets built in automation projects is there because nobody could argue against it.

The case study is a by-product. A useful one. But if measuring only produced better marketing, I'd still do it, and I'd do it for the ninety percent of projects that never become a case study at all.

What this costs me to say

I have one case study on this site. I've done twenty-five projects.

The rest is on the about page as a list of names, with no numbers next to it, because I can't prove what those projects did and I'm not going to write "streamlined their operations" and hope you don't notice.

That's an expensive choice. A portfolio with twenty-five entries looks more impressive than one with a single measured result. Most visitors won't read closely enough to notice that twenty-four of them say nothing.

But the ones who do read closely are the ones worth working with. And I'd rather be the person who says "I can't prove that one, so it's not here" than the person who says countless hours.


If you're about to start an automation project, of your own or for someone else: spend the first afternoon measuring what it costs today. Time it, count it, or export it. Write the number down with the date and how you got it.

You'll use that number twice. Once to decide whether to build the thing at all. And once, much later, to find out whether you were right.

→ The one case where I measured first · → Start with the diagnostic: USD 150