Before You Automate Anything: The Setup Work Nobody Talks About

My laptop had seventeen browser tabs open. A sticky note on the monitor said "FIX ONBOARDING" in all caps, underlined twice. A spreadsheet I'd been updating by hand every Friday sat open in one of those tabs, its last entry three weeks old.

That was the day I decided to automate things properly. Not poke at a tool until something worked. Actually set it up so it would run without me.

What I didn't expect: the setup itself would take longer than any individual workflow. Not because the tools are hard. Because I hadn't done the thinking first.

If you're here because you want a step-by-step walkthrough of a specific automation platform, I write about that elsewhere on the Blog, Utomat. But this post is about what comes before that. The part most guides skip.

Map What You Actually Do Before You Automate It

Here's the trap. You open an automation tool, you see the words "connect your apps," and you immediately start connecting apps. Three hours later you've built something that technically works and practically doesn't, because you automated a process you didn't fully understand.

A 2024 report from McKinsey found that companies which documented their processes before automating them were significantly more likely to see lasting productivity gains than those who automated ad-hoc. The documentation step felt like overhead. It wasn't.

Before I touch any tool, I write out the process in plain language. Not a flowchart. Just sentences. "When someone fills out the contact form, I copy their details into the CRM, then send them a welcome email, then add a task to follow up in three days." That's it. Write it down.

This matters because:

• You'll spot the steps you do differently each time (automation hates inconsistency)
• You'll find the steps that only exist because of a legacy constraint that no longer applies
• You'll know what the output actually needs to look like

The question to ask for every step

For each step in your written process, ask: does this need a human judgment call, or is it mechanical?

Mechanical means the same input always produces the same output. That's automatable. "Send a confirmation email when someone books" is mechanical. "Decide whether this lead is worth following up" is not. At least not yet.

Be honest about which is which. Automating a judgment call usually means you've just hidden the decision inside a rule that breaks every third time.

Get Your Tools Talking to Each Other First

Before you build any workflow, check that your tools can actually connect. This sounds obvious. It is not.

I once spent four hours building a beautiful multi-step automation only to discover that the CRM I was using didn't expose the field I needed via its API. The automation was right. The foundation wasn't.

Authentication and permissions

Every connection between tools requires credentials. Usually an API key, sometimes OAuth, occasionally both. Write them down somewhere secure before you start. Not in a browser tab. Not in Slack. In a password manager or a locked note.

Also check permission scopes. A lot of tools let you generate an API key with read-only access or full access. Read-only keys break write operations in ways that can be confusing to debug later. Get the permissions right at the start.

Webhooks vs. polling

If you're connecting two tools and one of them doesn't offer a webhook (a real-time push notification when something happens), you're polling. Polling means your automation checks for new data on a schedule. That's fine for many use cases and it's how a lot of no-code tools work. Just know which one you're doing, because it affects how quickly your workflows respond.

Zapier has a decent overview of the difference if you want to go deeper on that.

Structure Your Data Before You Move It

This is the one that gets skipped the most.

Automation moves data between systems. If the data going in is messy, the data coming out is messier. Garbage in, garbage out, but now at speed and scale.

Spend time on:

Naming conventions. If your CRM has a field called "Company" and your email tool has one called "Organization," decide now which label is canonical and stick to it. Mismatches create duplicates and mapping errors.

Required vs. optional fields. Know which fields an automation must have to run correctly. If a record comes through missing a required field, the automation should fail loudly, not silently skip or write junk.

Date formats. This is a small thing that causes enormous pain. One system stores dates as `2025-07-14`, another as `14/07/2025`. Pick a format and normalize everything to it before it hits your workflows.

A 2025 survey by Zapier on small business automation found that data quality issues were among the top reasons automations got abandoned after launch. Not tool complexity. Dirty data.

Build One Workflow, Let It Run, Then Build the Next One

Everyone wants to automate everything at once. I understand. The list of repetitive tasks is long and the impatience is real. But building five workflows in a week means you won't notice when one of them silently breaks.

Build one workflow. Run it for a week. Watch it. Check that the output is what you expected. Then build the next one.

This sounds slow. It is slower. It also means that six months from now you'll have ten workflows that work, instead of twenty that sort-of-work-unless-the-edge-case-happens.

How to know when a workflow is actually stable

I consider a workflow stable when:

1. It has run at least twenty times without manual intervention 2. I've seen it handle an edge case (a missing field, an unexpected input) and recover gracefully 3. I know what happens if a step fails, either it retries, or it sends me an alert, or both

That last point matters. Every automation will fail eventually. The question is whether you know about it before your customer does.

I wrote a bit more about my own process for deciding what to build first over on Utomat, AI automation, built in public.

Set Up Monitoring Before You Walk Away

The worst version of automation is the kind that breaks quietly. The form-to-CRM workflow that stopped firing two weeks ago. The invoice reminder that hasn't sent since someone changed the email template. The lead notification that's been routing to a deleted Slack channel.

Before you consider a workflow "done," decide how you'll know if it stops working.

For most tools, this means:

• Error notifications sent to an email or Slack channel you actually check
• A simple audit log you can scan weekly (even a five-minute check is enough)
• For anything business-critical, a secondary check, like a daily count of records processed vs. records expected

The n8n documentation on error handling is worth reading if you're using that tool. Most platforms have equivalent docs.

This is the unglamorous part of automation. It's also the part that separates automations that save you time from automations that create new, confusing problems six weeks after you've forgotten they exist.

The Part I Skipped (And Regretted)

I'll be honest about one thing I got wrong early on.

I didn't document my automations as I built them. I knew how each one worked because I'd just built it. Then six months passed, a tool updated its API, a workflow broke, and I spent two hours reverse-engineering something I'd written in an afternoon.

Now I keep a simple doc for each workflow. One paragraph: what it does, what triggers it, what it outputs, and where to look if it breaks. That's all. It takes five minutes to write and it has saved me hours.

You can find more about how I've been thinking through this stuff over time in the About, Utomat page, and I go deeper on specific tools and decisions throughout the Blog, Utomat.

If you want to talk through what setup actually makes sense for your situation, get in touch. I'm not going to give you a canned process. I'll ask you what you actually do, and we'll figure out what's worth automating and what isn't.

Related reading: Utomat vs. the Field: What the Pricing Comparison Actually Tells You.