My services
Automation That
Runs Itself
I connect your tools and remove the manual busywork, so your team spends its time on the actual job.
Get startedDo more
with less effort
Get started Eliminate busywork
Copy-pasting between apps, chasing approvals, re-keying data - it's slow, error-prone, and it doesn't scale. I map the repetitive tasks eating your team's day and hand them to automations that never miss a step.
Connect every tool
Your CRM, inbox, spreadsheets, and billing should talk to each other. I wire your stack together so information flows automatically. No more silos. No more "I didn't see that update."
Fewer mistakes
Manual re-entry is where details get lost or typed wrong. An automation reads the same fields the same way every time, including at 5pm on a Friday.
Nothing waits on a person
Work moves the moment it arrives, evenings and weekends included, instead of sitting in an inbox until someone has time for it.
Scale without headcount
Growth shouldn't mean hiring just to keep up with admin. Automations absorb the extra volume quietly in the background, so you can take on more work without the overhead, or the burnout.
What actually gets automated
Most of this work falls into a handful of recognisable shapes. Yours will be some combination of them, wired to the tools you already run.
Lead capture and routing
An enquiry arrives by form, inbox or phone. It becomes a structured record in your job system, assigned and ready to action, without anyone retyping it.
Quote follow-up
Quotes that go out and then go quiet are where work leaks away. A workflow can track which ones have had no reply and prompt you at the point it still matters.
Scheduling handoffs
When a job is accepted, the calendar entry, the assignment and the customer confirmation can all follow from that one event rather than three separate tasks.
Documents and photos
Photos, PDFs and attachments can be read on arrival, with the details pulled out and written where they belong. This is the part people assume still needs a human.
Invoicing and reminders
Invoices raised off completed jobs, and reminders sent on a schedule you set, rather than whenever someone remembers to check who has not paid.
Reviews and reporting
A review request after a finished job, and a weekly summary of what came in, what closed, and what is still sitting open.
From manual to
automated in weeks
Map
I shadow how work actually flows today and pinpoint the manual steps costing the most time.
Design
I blueprint the automated workflow end to end - triggers, logic, and handoffs - and agree it with you first.
Build
I connect your tools with reliable, well-documented automations and test every edge case before go-live.
Monitor & refine
I watch the workflows in production, catch exceptions early, and tune them as your processes evolve.
What happens when something breaks
Every automation fails eventually. An API changes, a customer uploads something strange, a service has an outage. The question is not whether that happens, it is what the system does about it.
Nothing fails silently
A step that fails raises an alert instead of swallowing the error. You hear it from the system, not from a customer asking why nobody called back.
Retry, then escalate
Temporary faults retry on their own. Anything that genuinely cannot proceed is put somewhere a person will actually see it.
The manual path still works
Automation sits on top of your process, not in place of it. If a workflow is paused, your team can still do the job by hand.
It comes documented
You get a written description of what runs, what triggers it, and where to look when something seems off. That matters most if I am not the one maintaining it later.
Two examples
View all projectsBoth are real builds for Australian trades businesses running on ServiceM8. The write-ups below link to the full case study for each, with the actual workflow laid out step by step.
How to choose who builds it
Automation is easy to sell and harder to maintain. Whether you are weighing up an agency, a freelancer or me, these are worth asking before you commit to anyone. You are buying something that has to keep running long after it is built.
-
Ask what happens when it breaks
A demo shows the path where everything works. The real engineering is in what the system does with the cases nobody planned for.
-
Ask who owns the accounts
It should run in your accounts, on your subscriptions, with your data. If it lives somewhere only the builder can reach, you are renting your own process back from them.
-
Ask to see it written down
If nobody can explain the workflow without opening the builder and clicking through it, it cannot be handed over or repaired by anyone else.
-
Ask what they will not automate
Some steps need judgement and should stay with a person. Someone willing to tell you that is more useful than someone who says yes to everything.
-
Watch for lock-in
A workflow built on tools you already pay for is cheaper to keep than one that needs a new subscription forever to stay alive.
How a project runs
Scope, timeline and cost are agreed in writing before anything is built. In practice it runs like this.
We map it first
An hour or two on how the work happens now. Sometimes the honest answer is not to automate it.
You get a written scope
What gets built, what it connects to, what it will not do, and what it costs.
I build on real data
Testing uses your actual enquiries and job records, because that is where the awkward cases live.
You approve before go-live
Nothing touches your live system until you have watched it work on the real thing.
Then it gets watched
Early production is where the last edge cases surface. That period is part of the build.
Common questions
Which workflow automation platform should I use?
There isn't one answer. It depends on what you already run. Most of my work connects into ServiceM8. The platform matters less than getting the workflow right, which is why I build around your existing tools rather than moving you onto a new one.
Which businesses benefit most from this?
Service and trades businesses with a steady stream of enquiries: quotes, bookings, calls, job requests. If someone on your team spends part of their day moving information between a form, an inbox, and a job system, that's usually where the time is going.
How do you decide where to start?
I map how the work actually happens first, not how it's supposed to happen. That's the first step in every build, and it's usually where the biggest time cost turns up.
Do we have to change the software we use?
Usually not. The point is to connect what you already run, not to move you onto something new. If a tool genuinely cannot do what you need, I'll say so, but replacing your stack is the last resort rather than the opening move.
How long does it take?
A single workflow is usually a matter of weeks rather than months. The mapping session comes first, and the written scope that follows it gives you a real timeline rather than a guess.
We tried automation before and it didn't stick. Why would this differ?
Most abandoned automations fail for one of two reasons. Either they broke quietly and nobody noticed until the damage was done, or they were built somewhere nobody else could maintain. Both are addressed above, and both are fair things to hold me to.
What do you need from us to get started?
Access to the tools involved, and some time with whoever actually does the work today. That second one matters more. The person doing the task knows the exceptions that never made it into any process document.
Ready when you are
Let's build something
worth talking about
Tell me about your workflows and I'll come back within 24 hours with a plan.
Get started