Building AI automation that actually gets used (and keeps working)

Most people don’t need “AI strategy”. They need Tuesday morning to be less chaotic.

That’s the work I do at GrokoryAI. I sit with real business owners, map the messy bits of the day-to-day, and build small automation modules that remove friction fast. The only rule is simple: if it doesn’t save time, reduce stress, or help revenue land sooner, it’s not worth building.

I like building with users, not for them

The best ideas don’t come from whiteboards. They come from watching how someone actually works:

• The bookkeeper who lives in Gmail and loses track of follow-ups.

• The tradie who forgets to send quotes because they’re on the tools

• The admin team that copies the same data into three places because “that’s just how it’s done”.

I enjoy that part - asking the awkward questions, finding the bottleneck, and then building a fix alongside the person who’ll use it. I want them involved early, because if it doesn’t fit their habits, it won’t stick.

I’m hands-on with AI + automation, end to end

I don’t just talk about automations, I build them.

That usually means connecting the tools SMEs already use (Google Workspace, forms, spreadsheets, Xero-style workflows, CRMs) into a simple flow that runs in the background. Typical jobs include:

• Form submissions that trigger instant summaries, task creation, and follow-ups

• Quote requests that generate a draft response and log a lead

• Invoice or document data that gets extracted and pushed into a sheet or system

• Inbox triage that sorts, labels, and escalates what actually needs a human

The goal is always the same: fewer clicks, less double-handling, and better visibility.

I build mostly with Jotform, Make and Zapier, because they’re fast to deploy and easy for a solo operator to maintain. Where needed, I’ll add light scripting in Python or JavaScript to bridge gaps, things like cleaning messy data, transforming a payload or applying business rules that no-code steps can’t express cleanly.

I’m not chasing complexity. I’m chasing reliability.

If a system only I can understand, it’s a liability. So I explain everything in normal terms, like:

• “When a form comes in, it checks what’s missing.”

• “If it’s complete, it saves the info and sends the next step.”

• “If it’s not complete, it nudges the person automatically.”

That way, the client can trust it, maintain it, and spot issues without feeling like they need an IT department.

I’m naturally curious: if there’s a faster or cleaner way to do something, I’ll test it. But curiosity without responsibility is just tinkering.

So I build with a “boring” mindset:

• clear naming and documentation

• error handling and alerts

• simple handover notes

• privacy and data minimisation where it matters

  
  

Because if an automation breaks silently, the business pays for it. I take that personally.

If you want AI that looks impressive, I’m not your guy. If you want AI that quietly removes pain from operations (and keeps doing it), then we’ll get along.