AI automation consulting for forward-thinking businesses
I spent sixteen years in telecom watching good automation die while still in planning, due to change control and vendor restrictions. Now I build it for businesses small enough that a good idea can still ship in weeks.
The analogy
Every automation worth having has the same four parts. Miss one and the machine either never turns, or tears itself apart within a year. Scroll through and watch each part light up.
Copper windings turn current into a magnetic field. Nothing moves until they carry power. That is your team: until they genuinely understand what these tools do and quietly do badly, every automation conversation is just opinions.
Training & SeminarsThe gap between stator and rotor is under a millimeter. Too wide and you lose power; too tight and it seizes. That precision is the workflow audit; knowing exactly where automation belongs, and where it would do damage.
Audit & PlanningThis is the part that does the work. A system built against your real data, wired into the tools you already use, running on frontier or open-weight models depending on what your business and your data can allow.
Custom BuildsMotors fail from heat, not effort. Models get deprecated, APIs change shape, teams grow and use things differently. Ongoing support is the housing and cooling that keeps a working system working.
Ongoing SupportFour levels
You do not have to take all four, and you do not have to start at the beginning. Most people start with a session or an audit, then decide what is worth building.
Get everyone speaking the same language before anyone buys anything
A practical, hands-on session for your team on what these tools genuinely do, what they quietly do badly, and where the real opportunities sit in your own workflows.
Leads on to Audit & Planning
Know exactly what to build, in what order, and what it is worth
A structured look at how work actually moves through your business, ending in a costed, sequenced plan you can act on (with me or without me).
Leads on to Custom Builds
Systems wired into the tools you already use, and owned by you
Custom automation built against your real data and your real processes, deployed into production, documented, and handed over as something you own rather than something you rent.
Leads on to Ongoing Support
Motors fail from heat, not effort
Continuous monitoring, tuning and extension of the systems running your business, so automation keeps earning its place rather than quietly degrading.
Why now, why here
I know exactly what stops automation inside a large organization, because I spent sixteen years on the other side of it. Almost none of it applies to you.
How I work
Most failed AI projects were lost at the planning stage, not the building stage. So the plan comes first, it is written down, and it is yours whether or not I build anything.
I sit with the people actually doing the job. The person rebuilding the same report every Monday knows more about your bottleneck than any process document does.
Every opportunity scored the same way on value against effort, so the order we build in is defensible rather than a matter of taste. Including an explicit list of what should not be automated.
One workflow, finished and in production, before the second one starts. Working software early, so surprises surface while they are still cheap to fix.
Code, prompts, configuration and documentation, plus a session teaching your team to run and change it. You should be able to fire me and keep everything working. You own the automation.
What you get either way
Code, prompts, configuration, data. No platform that becomes expensive to leave, because there is nothing to leave.
Where sensitivity or cost demands it, we run open-weight models on hardware you control instead of sending anything to a third party.
I will tell you when a workflow should not be automated, and when a spreadsheet formula would beat a language model. That advice is free.
Built around the CRM, inbox and spreadsheets your team already uses, rather than asking everyone to move somewhere new.
Evaluated against real historical cases so you can see how it behaves before it touches anything live.
You work with me directly. No account manager relaying questions to a delivery team you never meet.
PDF checklist
The same structured checklist I use on paid audits: how to map what your team really does, how to score an opportunity on value against effort, and how to spot the processes that should never be automated. Run it yourself, or use it to judge whoever you hire.
Insights
Onboardle started as an intake form for an AI website builder. It became a product when I realized the intake form, the new-client...
Read
Every workflow audit I run ends with a list of processes that should stay manual. Clients are often surprised by how much money th...
Read
The choice between a hosted frontier model and an open-weight model you run yourself is an engineering decision. Making it once, f...
Read
No — it is closer to an advantage. The hardest part of this work is understanding how the business actually operates, and you already do. My job is to translate that into something a machine can help with, and to explain every decision in language you can push back on.
If you ever leave a conversation with me feeling like you nodded along without understanding, that is my failure and I want to know about it.
You work with me directly. There is no account manager relaying your questions to a delivery team you never meet, and no incentive to stretch a six week build into six months.
The trade-off is honest: I am one person, so I take fewer clients and I will tell you if your timeline does not fit. What you get in exchange is someone who remembers every decision made on your systems.
Not necessarily. For a lot of workflows a frontier model is the right call and the data involved is unremarkable. For others — anything involving customer records, health information, or contract terms you are not free to share — running an open-weight model on hardware you control is the better answer.
That decision gets made per workflow, and the reasoning gets written down so you can take it to a client, an auditor or an insurer.
That is a completely normal outcome and the audit is priced on that basis. The plan is a standalone document you own outright — take it to an internal team, another consultant, or leave it on a shelf until the timing is better.
I would rather you have a good plan you act on later than a rushed build you regret now.
A training session can happen within a couple of weeks. An audit runs two to three weeks. A first custom build is typically six to ten weeks from scope to production.
If someone promises you a production system in days, ask them what happens when it is wrong about something that matters.
It will, occasionally — that is true of your people too. The question is what the system does about it. Every build has explicit boundaries: what it decides alone, what it escalates to a human, and what it does when it is uncertain.
Before anything goes live it is evaluated against real historical cases, so you can see the error rate rather than guess at it.
No. Every audit includes an explicit do-not-automate list, and it is usually one of the most valuable pages in the document. Some processes are too low volume to justify the effort, some carry risk that automation multiplies, and some are the part of the job people actually enjoy.
Roughly five to two hundred people. Below that there is often not enough repeated process to justify a build; above that you start acquiring the procurement and policy layers that made this work so frustrating in my previous career.
If you are outside that range, get in touch anyway and I will be straight with you about fit.
Start here
The most useful thing you can send me is the boring part of your week — the report someone rebuilds by hand, the inbox nobody keeps up with, the handoff that always drops. That is where this work starts.