I found where you’re losing people. It wasn’t where I thought.

It’s not the price. It’s not the product. It’s not even the competition.

It’s the little gaps between all your tools.

Here’s the annoying bit that took me ages to see. You don’t lose a customer while they’re talking to you. You lose them in the silence after. When the lead comes in and then just... sits there. When the booking gets made and then everyone quietly forgets to care about it.

Sound familiar yet? It should. Because this is how almost every small business I know actually operates.

We aren’t bad at our jobs. We’re just carrying the whole thing around in our heads.

Here’s what that looks like in a normal week.

You close a deal on Friday. Lovely, well done you. Monday rolls around and the follow-up is still a thought, floating in your skull somewhere between “reply to that email” and “I must renew the insurance.”

Someone books in. You confirm it. They no-show. And you feel mildly annoyed at them, when really it was just a booking with no memory.

A new customer signs up. Everyone’s happy. And then the real work hasn’t even started, because onboarding has become a three-week chain of you chasing documents one polite email at a time.

None of this makes you bad at business. It makes you a person trying to hold fifty open loops at once. And the customers feel it. To them you don’t feel like one coherent business. You feel like a follow-up here, a chasing email there, a “sorry, can you resend that?” later.

The business feels fine to you. The joins are what’s quietly bleeding.

Until you flip it.

What if the follow-up scheduled itself before the deal even closed?

What if the booking nudged the person, repeatedly and without you lifting a finger?

What if the welcome email already had the document and the signature in it, before they could stall?

What if the happy customer got asked for a review at the exact moment they’re buzzing, instead of two weeks later when the feeling’s gone?

Now you’ve got something. Because the work was never the problem. The handovers were. And a handover that runs itself isn’t a job you do, it’s a thing that just happens.

The first Monday you don’t carry Friday’s deal in your head, you’ll feel it. It’s like taking a rucksack off you forgot you were wearing.

If you want to see what that looks like for your own business, drop me a reply and I’ll show you.

Most first AI pilots don’t fail. They just never finish.

Nobody agreed what good looks like. Nobody can switch it off. Six months later it’s still “going quite well”, and nobody can say what it has changed.

Back in September I shared a short checklist for a first AI experiment. It got more replies than anything else I’ve posted, and most of those replies made it better. So here’s the full version, with your additions in it.

To keep it practical, I’ll run one example all the way through. suggested it in the replies: meeting prep. Clear benefits, manageable risks.

Imagine a small team with a weekly client meeting. Before each one, someone spends time pulling together last week’s notes, open actions and recent emails into a one-page brief. The experiment is simple. AI drafts the brief, and a person checks it before the meeting.

Here’s the checklist.

1. Small enough to stop

If switching it off needs a meeting, it’s too big. A good first experiment is one you can stop on a Friday without anyone noticing.

Meeting prep: one team, one recurring meeting, one brief. Not every meeting in the business.

2. Clear enough to measure

You need something you can count without arguing about it. Minutes. Mistakes. Corrections. Whether the thing actually got used.

Meeting prep: how long the brief takes to produce, and how many things the person checking it had to fix.

3. One owner, with the authority to stop it

“The team owns it” means nobody owns it. put it well: when the experiment belongs to a committee, nobody is allowed to call it a failure, so it drifts for two quarters and gets renamed.

added the bit that usually gets watered down. One name means one person who can kill it without a meeting. If stopping needs a committee, it won’t stop.

Meeting prep: the person who runs the meeting owns it. They can pause it on the spot, no sign-off needed.

4. A clear definition of “better”

Faster? Fewer mistakes? Less chasing? Pick one before you start. Otherwise every result looks like it might be progress.

Meeting prep: “better” means the brief is ready the day before, and the meeting lead spends less time on it than they do today, without missing anything that matters.

5. Write the failure down first, and who acts on it

suggested this one. Write down what a wrong answer looks like before you start, so you know when to kill the experiment instead of arguing from vibes.

took it a step further. The same list tells you who has to act when that failure happens. Put a name on the same line as the failure. Teams notice. People act.

Meeting prep: the failures are an action marked as done when it isn’t, or notes pulled in from the wrong client. The meeting lead checks every brief, and if the wrong client shows up even once, they pause it.

6. Measure the human first

’s addition. Make the experiment easy to compare against a human baseline. Otherwise you can’t tell whether AI improved the work or just changed it.

Do the job by hand once or twice. Time it. Write down what went wrong. The AI has to beat the person doing the job today, not an empty page.

Meeting prep: time the next two briefs done by hand, before the AI touches anything. Note the minutes and anything that got missed.

7. Set the stop date and the stop rule up front

Tommaso asked me in September whether I set the stop date up front. I do. I’d rather run a small pilot for 30 days, learn from it, then make a deliberate decision: scale it, change it, or stop it.

added the rule that goes with the date: “if it doesn’t save X hours in 30 days, we pause it”, agreed at the start so the decision isn’t emotional later. Put the date in the diary too, so 30 days doesn’t quietly become 90.

Meeting prep: four weekly meetings, then a decision. The rule is agreed on day one. If the brief isn’t saving the meeting lead time by week four, or the wrong-client failure happens, it stops.

When you stop, write down why

said it in one line: a stop isn’t progress if you never learn what broke. A stopped pilot with a short note on what went wrong is a result. A stopped pilot with no note is just a wasted month.

The whole thing on one page

• Small enough to stop

• Clear enough to measure

• One owner who can stop it

• A clear definition of “better”

• The failure written down first, with a name next to it

• The human measured first

• A stop date and a stop rule agreed up front

None of this needs a big budget or a transformation programme. It needs one task, one person and a date in the diary.

Three of these seven came straight from your replies, and the rest got sharper because of them. So I’m asking again.

If you were switching on your first AI pilot next Monday, what’s the one check you’d add that isn’t on this list?

That still works today. But it's quietly being replaced at the top, and almost no one in our industry is talking about it.

Your next corporate client isn't going to find you by typing your name. They're going to describe a problem.

"Find me a provider who trains mid-level managers on difficult conversations, within budget, with proven outcomes."

And the answer won't come from a friendly recommendation. It'll come from a machine that read the question, scanned a hundred providers, and handed back three names.

If you weren't one of the three, you never found out the opportunity existed.

The filter moved before the handshake

It used to be that the human did the searching. They went looking, they asked around, they compared. That's why networking worked. That's why relationships mattered. The human was the gatekeeper, and you could get to the human.

That's changing, and it's changing faster than most of us want to admit.

By 2030, analysts expect roughly one in five online purchases to be driven by an agent rather than a person. You might think training is different. It's high-touch. It's relational. It can't be bought by a bot.

I'd bet on that comfortable thought being wrong.

The procurement and L&D teams inside your clients' companies are already using AI to research, to compare, to shortlist. The contract still gets signed by a person. But the shortlist, the list of who even gets a meeting, is being built earlier and earlier. And it's being built by something that doesn't go to networking events.

The agent doesn't need to like you

This is the part that upends everything we've been taught about selling.

For twenty years, your job was to get attention. Build a brand. Tell a good story. Make them feel something.

An agent doesn't do any of that.

It doesn't need to be impressed by your website. It needs to be able to read it. To understand, without ambiguity, what you actually do, who you do it for, what outcome you deliver, and whether you fit the brief it was given.

If your offer is vague, it moves on. If your outcomes are fluffy, it moves on. If your methodology lives in a PDF a machine can't parse, it moves on.

It doesn't dislike you. It just has no reason to pick you. And unlike a human buyer, it doesn't fill in the gaps, doesn't give you the benefit of the doubt, doesn't say "I know the founder, let's give them a shot."

It filters. That's all it does.

Your marketing was built to be trickier than a person

Here's where it gets uncomfortable. Most of how we market training and consulting is built to work on human attention. Promises. Urgency. Authority. Scarcity. A compelling case study. A confident founder.

Agents don't respond to any of that the way a person does.

A bold promise isn't proof. An agent can't feel urgency, so a "limited availability" line does nothing. Authority means nothing if the underlying data doesn't back it up.

What an agent actually wants from you is the same thing a skeptical, overworked buyer would want, except the agent actually enforces it: a clear answer to a clear question.

What do you train? Who is it for? What changes for them? How do you prove it? What does it cost, roughly? When can you start?

If any of those answers is fuzzy, you're not a candidate. You're noise.

The opportunity is hiding in the trust gap

Now, before this sounds like doom, here's the useful part.

Almost everyone is already using AI to research. Depending on the study, roughly 39 to 44 percent of people use it to discover and compare options. But when it comes to actually letting an AI make the decision and spend the money, almost nobody's ready. Maybe 6 to 11 percent.

There's a massive gap between "I'll let AI help me look" and "I'll let AI choose and buy."

That gap is your opening.

Because right now, the buyers using AI to shortlist training providers are doing it quietly, without telling their vendors. They're not ready to fully trust the machine yet. So they let it suggest, then they check, then they pick.

And when they check, they go looking for the provider who made themselves easy to find. Easy to understand. Easy to verify.

That's the play. Not to surrender to the machine. To be the provider the machine, and the cautious human behind it, both feel safe choosing.

It's architecture, not advertising

Most training companies, when they finally wake up to this, do the same thing. They panic. They bolt on a chatbot. They rewrite their homepage. They think the fix is a marketing problem.

It isn't.

It's an architecture problem.

Being chosen by an agent means being structured so an agent can read you. Your offer in clear, machine-readable terms. Your outcomes stated in a way that can be matched against a brief. Your pricing, your methodology, your proof, all laid out so there's nothing to guess at.

The boring, perfectly structured provider beats the charming, vague one. Every time, in a world where a filter sits between you and the buyer.

That's not a thing most training companies have anyone inside who can do. And they know it.

Where you stand, honestly

This isn't a future problem, exactly. It's a now problem that most of the industry is choosing to ignore because it's uncomfortable to think about.

But the shift is already measurable. The protocols are already being built. The big enterprise platforms are already racing to standardize how a service like yours gets described, compared, and selected.

The providers who structure themselves now get to be the ones the machine learns to trust first. The ones who wait get to explain, later, why their referral network stopped feeding them.

I architect solutions for businesses that want to be selected, not just seen. I look at how your offer, your outcomes, and your proof need to sit so that when a buyer delegates their shortlist to an agent, your company is the one that comes back.

If you want a clear read on where your training business actually stands, and what building it properly would take, let's talk. I'll tell you honestly what's holding you back, and what ready looks like.

No panic. No chatbot band-aid. Just a straight answer on whether you'll be in the room, or filtered out before anyone ever knew you existed.

I went on holiday to Romania with my children this summer and did something I’d been putting off for 2 years. I got blood tests done.

I reviewed the results with ChatGPT and the picture was clear enough that I stopped negotiating with myself. Everything had to take a turn, and health moved to the top of the list.

Then the harder problem showed up. Knowing what to change is easy. Living it every week is the part people quit on.

So I built the scaffolding.

The chef

I created a custom project holding my habits, my goals, and my real availability. Because it was connected to my calendar and my planning tools, it already knew how busy I was and how much time I realistically had for cooking.

Inside that project I set up an assistant called Cheffy. Its only job is to be my chef. I told it what I needed: meals that support lower cholesterol and steady insulin, fitted to the time I actually have.

Cheffy’s first recommendation was a 24-hour fast once a week, plus 18:6 fasting in between. I agreed and started. I’m 4 weeks in. Feeling great already!

The gap nobody talks about

The meals were good. Managing them was not. Thinking through every ingredient, every quantity, every shopping list, every week, is a second job sitting on top of the first one.

So I gave Cheffy a second job. Use the meal plan, build the week’s shopping list, log into my ASDA.com account, add everything to the basket, and place the order for Click & Collect.

That became a recurring task. Every Friday it works out the next few days for me, and I get a notification and an email: shall we place a new order this week?

That question matters. Some weeks I’m travelling. Some weeks I can’t cook anything. The system asks instead of assuming.

I simplified it yesterday

For a while this ran on two assistants. Cheffy did the food, and a separate coding agent handled the ordering. It worked. It was also more machinery than the job needed.

Yesterday I consolidated everything into one assistant running on Grok Bot. Cheffy now handles the planning, the list, and the order in a single thread, which means one place to correct it and one place to check it.

That’s the pattern I keep landing on. The first version of anything you automate should be a bit too complicated, because that’s how you learn which parts actually earn their place. Then you cut.

The part I actually feel

I placed the order, drove to the collection point, and was back home 25 minutes later. Start to finish, that’s the entire physical cost of eating properly for a week.

No aisles. No decision fatigue. No standing in a supermarket at 7pm trying to remember whether I already have olive oil.

When the shops are properly integrated with AI agents, and payment protocols like Google’s AP2 are live at scale, this stops being a setup one person hacked together and becomes how everyone eats. The upside isn’t efficiency. It’s the hours that go back to your family.

Why this works, and why willpower doesn’t

A health decision that lives only in your intentions is just a wish. You promise yourself on Sunday that this week will be different. By Wednesday evening, work gets heavy, decision fatigue sets in, and you default to convenience.

Willpower is finite. It dies by week three. What survives is the scaffolding you build around your daily routines. If your plan depends on you making heroic choices every single evening, you’ve already lost.

The same logic applies to the logistics. The hardest part of eating well isn’t eating. It’s the recipe research, the manual shopping lists, the meal planning, the standing in the aisle at 7pm wondering if there’s still olive oil at home. Remove the mental load and healthy choices become the default instead of a daily fight.

And this is where most people are still missing the point of AI. They use it to generate generic text faster. The real leverage is automating the friction out of your physical life, so ordinary chores become standing systems that run whether or not you’re tired or busy.

What I’ll report

Four weeks tells you nothing about cholesterol or insulin, and I’m not going to dress it up as a result. What I can say is that I haven’t skipped a single plan yet, which is more than I managed doing this manually.

The part I’ll defend today is the mechanism. A health decision that lives in your intentions dies by week three. One that lives in a weekly system, with a standing order and an assistant that asks permission before spending your money, is a different thing entirely.

When I have something honest to report, I’ll write it up.

If you need something similar set up, let me know.

When people talk about starting with AI, the conversation usually jumps to the exciting part.

An agent. A company-wide copilot. A new customer experience. A system that connects everything to everything else.

Maybe some of those things will be useful one day. I’m not against them. But they are usually a strange place to begin.

I would start somewhere much less exciting: with the work people quietly hate doing.

The weekly report that is assembled by hand. The same customer question answered from memory. The email that has to be forwarded because one system does not talk to another. The document that exists somewhere, but nobody can find when they need it.

This is where the opportunity is often easier to see. People are already paying for the problem through wasted time, delays, mistakes, frustration, or constant interruptions. You do not have to invent a benefit. You have to understand the cost that is already there.

There is an important qualification, though.

Not every task people dislike should be automated.

Some tasks involve sensitive information. Some look repetitive but actually depend on judgment. Some are symptoms of a badly designed process, and automation would only make the mess harder to see. Some are human interactions that should become easier, not disappear.

The aim is not to automate every complaint. It is to find one real piece of work where a sensible, bounded improvement might be possible.

Start by looking at the work

Before choosing a tool, I would ask three fairly ordinary questions.

What actually happens today?

This does not need to become a large process-mapping exercise. Start by asking someone to talk you through the work from beginning to end.

What starts it? What information is needed? Where does it go next? Where does somebody have to copy and paste something? What happens when the normal case is not the actual case? Who makes the final decision?

Even a rough description can expose things that are easy to miss when the conversation stays at the level of “we need to do something with AI”.

The problem may not be a lack of AI at all. It may be unclear ownership, missing information, duplicate approval, or a document nobody trusts. A tool can make a clear process faster. It can also make an unclear process even harder to understand.

What would better actually mean?

“Save time” is a useful starting point, but it is not enough on its own.

Maybe better means fewer errors. Maybe it means faster responses, more consistent service, easier access to information, or better visibility for the person making a decision.

If a process saves twenty minutes but creates more checking and rework, the work has not really disappeared. It has just moved somewhere else.

Before testing anything, write down what happens today and what you would like to improve. The measure does not need to be perfect. It does need to be meaningful enough to stop you confusing activity with progress.

What still needs a person?

This is the question that often gets added too late.

Some parts of a workflow should not be delegated completely. That might include sensitive information, unusual circumstances, customer empathy, professional judgment, or accountability for an important outcome.

“Human in the loop” is not a magic phrase that makes a system responsible. The person reviewing the result needs enough context to judge it, enough authority to change or reject it, and enough time to do the job properly.

If someone is expected to approve a stream of AI-generated outputs in a few seconds, without the information needed to assess them, the human review is probably theatre.

Try one small part first

Once you understand the workflow, the temptation is to rebuild everything. Try not to.

Choose one bounded slice: one type of document, one internal request, one recurring report, or one category of customer question.

Use representative examples, not only the clean cases that make a demo look good. Give one person responsibility for the outcome. Keep a simple baseline. Decide what better means and what would make you stop.

The purpose of the first experiment is not to prove that AI is transformative.

It is to learn whether this workflow, with this information, for these people, can be improved without creating a bigger problem.

That is useful learning even when the answer is no.

Maybe the data is not ready. Maybe the exceptions are too important. Maybe the process is too ambiguous. Maybe reviewing the output costs more than doing the original work. Or maybe the task was never a good candidate in the first place.

Those are all useful findings. They are also much cheaper to discover with a small experiment than after a large implementation programme.

A demo is not the same as a result

A demo asks, “Can the system produce an impressive output?”

A useful experiment asks different questions:

- Did the workflow improve?

- Did the people doing the work benefit?

- Did quality stay the same or improve?

- Did new risks or failure modes appear?

- Is the result worth the cost of operating and reviewing the system?

The second set of questions is less exciting. It is also much closer to the truth.

AI is not valuable simply because it is available. It is valuable when it helps people do meaningful work better, while the risks are understood and accountability is still visible.

So, if your team is discussing a large AI initiative, look for the smaller task underneath it.

What work do people quietly hate?

What would better mean?

What is the smallest safe experiment that could teach you something?

That is probably where the useful work begins.

If you already have a workflow in mind, reply and tell me about the process, not the tool you think you need. I’m more interested in where the friction actually lives.

I discovered Fedora and remember being amazed by how fast it felt compared with everything else I was using at the time.

When I started my first company at 18, Linux became a big part of it. I used it to manage my servers and share internet access across the neighbourhood.

Back then in Romania, having internet through a local LAN was a big thing. The speeds were incredible for the time, and neighbourhood networks were everywhere.

For about four years, I used Linux heavily.

Then I sold the company and moved away from it. I didn't really need Linux anymore and, if I'm honest, I wasn't ready to use it as my main operating system. There were still too many compromises, particularly when it came to software from Adobe and Microsoft.

Fast-forward many years and I found myself coming back to Linux.

Ubuntu started appearing on more and more of my servers. Even before the AI boom, I was already running virtual private servers for websites, WordPress installations, email hosting and various projects.

Then AI changed everything for me.

From around 2022 onwards, I started running more of my own servers again because I wanted to experiment, build things and understand this new technology properly.

And eventually I did something I probably wouldn't have imagined doing years ago:

I replaced Windows with Linux.

Today, another chapter starts.

I've discovered Omarchy.

And I jumped on it straight away. 😄

If you're even remotely considering moving away from Windows or macOS and trying Linux as your main operating system, take a look at it.

What impressed me is how much is already there. It's built with modern development and AI workflows in mind, with many of the tools I'd normally spend quite a bit of time installing and configuring myself.

For someone like me who actually enjoys configuring systems, that's saying something. 😂

So here we are.

Today starts a new journey for me.

The Omarchy journey.

Let's see where this one takes me. 🚀I