What Is Utomat Used For? A Plain Answer

Utomat isn't a category. It's a loose collection of things I've built to stop doing the same work twice. Here's what that actually means in practice.

A client emailed me last Tuesday asking if I could send them a summary of their project status. I had already sent it automatically that morning. They just hadn't noticed. That's the whole pitch, really.

People ask me "what is Utomat used for?" and I understand why the question is tricky. It doesn't fit neatly into a box. It's not a CRM. It's not a helpdesk. It's not even a single tool. It's the thing I built, and keep building, to handle the work that would otherwise eat my Tuesdays.

Let me try to answer it properly.

The Honest Answer: It's for Automating the Repetitive Stuff

When I say repetitive, I mean the things that follow a predictable pattern every single time. Status updates. Follow-up emails. Data entry. Scheduling. Moving information from one place to another.

None of that work requires a human. It just requires someone to have done the thinking once, upfront, to set up the rules. That's the trade. You spend an afternoon building the automation, and then it runs without you indefinitely.

According to McKinsey's 2024 State of AI report, roughly 60 to 70 percent of current work tasks could be automated with existing technology. That number has been creeping up as AI gets better at handling unstructured inputs, emails, voice, documents, not just structured data.

I have experienced this personally. The admin that used to take me a Friday afternoon now takes about twelve minutes, because most of it runs on its own.

The Tasks I Actually Automated First

The honest starting list looked like this:

Lead qualification emails that went out after someone filled in a form
Weekly project status reports pulled from the tracker and sent to clients
Invoice reminders that triggered when a due date was approaching
Onboarding sequences for new clients that I was writing by hand every time

None of these were clever. They were just things I was doing by hand, repeatedly, badly. The kind of work where you make mistakes not because it's hard but because you're bored and distracted.

What Utomat Is Not For

This matters as much as the other part.

If you want to fully replace a human relationship, automation won't do it. The part where you actually listen to a client's problem, make a judgment call, or say something that makes them feel heard, that part stays yours.

I also wouldn't use it for anything where the stakes of a mistake are catastrophic. If a misconfigured automation sends one extra reminder email, that's annoying. If it triggers a financial transaction at the wrong time, that's a real problem. Design your automations so that the failure mode is embarrassing, not destructive.

And it's not magic. You still have to think clearly about the process before you can automate it. I've written about this in the build log, the times I tried to automate a messy process and ended up with a messy automated process, just running faster.

A Note on AI vs. Rules-Based Automation

There are two types of automation doing very different jobs here.

Rules-based automation is the older kind: if X happens, do Y. Reliable, fast, predictable. No surprises. Good for processes where you know exactly what should happen.

AI-assisted automation handles the fuzzier cases. Categorising an incoming email. Summarising a transcript. Deciding whether a lead is worth escalating. The 2024 Work Trend Index from Microsoft found that 75 percent of knowledge workers were already using AI at work, and most of them were doing it informally, without any real system behind it.

That gap between "people using AI ad hoc" and "AI running reliably in the background" is basically what I've been trying to close.

The Things People Actually Use It For

Here's a more practical breakdown, based on the work I've done and the problems people bring to me.

Client communication. Automated status updates, follow-ups after meetings, responses to common questions. The goal isn't to fake a human conversation, it's to make sure the routine touchpoints actually happen, every time, without relying on memory.

Lead handling. Getting a new inquiry? There's no reason a human should be the first thing that responds. A well-designed automation can qualify the lead, send relevant info, book a call, and alert the right person, all before anyone's read the email. I built something like this for CallCrewHQ and the response time dropped from hours to under two minutes.

Internal operations. Things like syncing data between tools, generating reports, sending internal alerts when something needs attention. Dull work that falls through the cracks when everyone assumes someone else is handling it.

Document handling. Generating proposals, contracts, or invoices from a template based on inputs from a form or CRM. I used to do this by hand. Never doing it by hand again.

Zapier's automation report noted that small businesses that automate even a handful of processes report significant time savings within the first month. I'd add that the other benefit, consistency, is equally valuable. The automation doesn't forget. It doesn't have a bad week. It just does the thing.

How I Decide What to Build Next

The filter I use is simple. I look for work that meets three criteria:

1. I've done it more than three times in the same way. 2. The output is predictable enough that I could write instructions for someone else to do it. 3. Getting it wrong isn't catastrophic, just fixable.

If all three are true, it's a candidate for automation. If the task involves judgment calls that depend on context I can't reliably encode, it stays manual.

I document this thinking on the blog as I go. Not because I have everything figured out, but because I find the honest working-through-it more useful than polished case studies that skip the wrong turns.

The Bigger Picture

There's a version of this where I tell you automation will transform your business overnight and you'll reclaim dozens of hours a week by Thursday. That version is a lie.

The real version: you identify the most painful repetitive work, you build something that handles it, you fix it when it breaks, and then you do it again. Over time, the boring stuff starts to disappear. You spend more of your week on the work that actually needs a person.

According to Deloitte's 2024 automation survey, organisations that had been running automation programs for more than three years reported the highest satisfaction, not because the technology improved, but because they had learned what was actually worth automating. The learning curve isn't the tools. It's the thinking.

I've been writing about this, and building in the open, at Utomat. If you want to follow the mess and the wins, the build log has the unfiltered version. And if you want some context on where this is all coming from, the about page is probably the right place to start.

If you've got a specific process eating your week and you're not sure whether it's automatable, drop me a line. I don't do demos or discovery calls with a deck. I just talk through the problem with you and tell you honestly what I think.