Your First Utomat Workflow: What to Build, What to Skip, and How to Actually Finish It

I have a friend who spent three days building an automation to sync her Google Calendar with Notion. She used it twice, then forgot it existed. The automation worked perfectly. It just didn't matter.

That's the trap with workflow tools. The fun part is building. The useful part is picking what to build. And most people never stop to think about the second thing before diving into the first.

So before you open a workflow builder, here's how I think about getting started.

Why Most First Workflows Don't Stick

The most common mistake is picking a workflow that's technically interesting but not actually painful. You automate something you do once a month instead of something you do eight times a day. It works, you feel clever, and then you never think about it again because the underlying task wasn't costing you anything meaningful.

The research backs this up. A McKinsey report on automation adoption found that companies get the most return from automating high-frequency, low-complexity tasks, not the big, dramatic ones. The small, repetitive stuff is where the hours actually live.

So the first question isn't "what can I automate?" It's "what do I do constantly, hate doing, and would be genuinely happy to never think about again?"

The Three Questions I Ask Before Building Anything

I run these three questions for every workflow I'm considering:

1. How often does this happen? (Daily beats weekly beats monthly) 2. How long does it take me each time, honestly? 3. Would I notice if it broke, or would it silently fail for a week?

If something happens daily, takes five minutes each time, and you'd catch a failure quickly, that's a good first workflow. If it happens monthly, takes two minutes, and you might not notice it broke for a fortnight, that's a future-you problem, not a right-now problem.

The Workflows That Actually Deliver

I've built a lot of these over the years, for myself and for other people's businesses. The ones that stick are almost always in one of three categories.

Notification and alerting workflows

Something happens in one system, you need to know about it in another. A new form submission hits your site, a Slack message goes out. A payment clears, you get an email. A support ticket comes in after hours, it gets logged somewhere you'll see it in the morning.

These are fast to build, easy to test, and immediately obvious when they work. You feel the value the first time a notification lands while you're away from your desk.

Data entry elimination

This one is less glamorous but probably more valuable. You fill out a form, and that information has to end up in three other places: your CRM, a spreadsheet, a project management tool. Copying and pasting between systems is exactly the kind of work that looks productive and isn't.

According to Salesforce's State of IT report, employees spend a significant chunk of their week on tasks that could be automated, data entry and manual record-keeping consistently rank near the top of that list. It's not surprising. It's just depressing.

Follow-up sequences

Someone books a call, submits an enquiry, or makes a purchase. You mean to send a follow-up. You forget. Two days later you remember, feel guilty, send something that says "just circling back" and feel bad about it.

An automated follow-up sequence doesn't have to be elaborate. A single email sent 24 hours after an event, triggered automatically, is worth more than the perfect multi-step sequence you've been planning for three months.

How to Actually Build Your First One

Once you've picked the right workflow, the building part is straightforward. Here's the approach that works for me.

Start with paper, not a builder

Before you open any tool, write down the trigger (what starts the workflow), the steps in order, and the outcome (what success looks like). Keep it to one page. If you can't explain the workflow in plain English without the tool in front of you, you don't understand it well enough to build it yet.

This sounds obvious. It isn't. Most people open the builder first and figure it out as they go, which is how you end up with a workflow that technically works but is impossible to debug six weeks later.

Build the smallest version first

Not the version with all the edge cases handled. Not the version with error notifications and fallback paths and conditional logic for seven different scenarios. The version that handles the normal case, works reliably, and takes two hours to build instead of two days.

You can add complexity later, once you know the core thing works and you actually want it. Half the edge cases you plan for never happen anyway.

Test it yourself before it touches real data

This sounds obvious too, but: run your workflow manually through a test scenario before you turn it on for real. Not just one test, three or four, with slightly different inputs. See what breaks. See what the output actually looks like. Make sure the thing that lands in your CRM, or goes out as an email, is what you intended.

I once skipped this step on a lead notification workflow. It worked fine, except the name field was pulling from the wrong form field, so every notification said the lead was named "Your Name". For four days. Not my best work.

The Tooling Question

I built Utomat, AI automation, built in public as my own answer to this problem, which gives me an obvious bias. But the honest version of my view: the tool matters less than the workflow design. A well-designed workflow on a mediocre tool beats a poorly designed workflow on the best tool available.

That said, some tools are genuinely easier to start with than others. If you're doing something simple, a trigger, a couple of steps, a result, almost any no-code automation tool will work fine. If you need logic branching, multiple systems talking to each other, or anything that has to be reliable at volume, you'll want something with better debugging and error handling than the basic tier of most consumer tools.

I've written more about how I think about the tradeoffs on the Blog, Utomat, and if you're curious about the journey of building the thing itself, the About, Utomat page has more context on what I'm actually trying to do here.

What Happens After the First One

Here's the thing nobody tells you: the first workflow is the hardest. Not because it's technically difficult, but because you're still figuring out how you think about automation. What's worth your time. What isn't. How to spot a good candidate.

By the third or fourth workflow, you'll start noticing candidates everywhere. A task you've done manually for two years will suddenly look obviously automatable. That's the shift you're aiming for.

Zapier's automation trends research has found that once people automate one or two workflows, adoption tends to accelerate, partly because the time savings become visible and partly because the mental model clicks into place.

For what it's worth, I've found the same thing. The first workflow I shipped felt like a project. The fifteenth felt like brushing my teeth.

A Note on Not Overcomplicating It

There is a version of automation where you spend more time maintaining your automations than you would have spent doing the tasks manually. I have been that person. It's a real thing.

The antidote is to stay disciplined about what you build and why. Document your workflows, even briefly. Build the simple version before the sophisticated version. And if a workflow breaks and you don't care enough to fix it, that's useful information, it means it probably wasn't worth building in the first place.

I moved my studio site off Firebase partly because the infrastructure was adding complexity I didn't need. The same logic applies to automation: keep the foundation simple, add complexity only when you've earned it.

Getting Started

Pick one task. Make it high-frequency and genuinely annoying. Write it out on paper. Build the smallest version that works. Test it before it goes live.

That's the whole playbook for your first workflow. Everything else is iteration.

If you want to talk through what makes sense to automate first in your specific situation, I'm easy to find. Drop me a note through the About, Utomat page and I'm happy to take a look.

Related reading: Is Utomat Worth It for a Small Business? Here's How I Actually Think About the Price.