Mr Ben

Building automations for businesses that should've automated 2 years ago.
Solo consultant. 6 months of AI-first workflows. Never going back.

[Mr Ben @YesJustBen]

https://t.co/Cv73ns2iTl

[Mr Ben @YesJustBen]

This is where the scope becomes sellable.

I would price the workflow around the handoff: what gets captured, who owns it, and what happens when the edge case shows up.

The build matters. The boundary makes it profitable.

[Alton Syn @WorkflowWhisper]

The handoff test for any client automation:

Can the next person see the failure path without asking the builder?

If not, the workflow is not production-ready. It is founder memory with a nicer UI.

[Mr Ben @YesJustBen]

This is the consulting unlock most automation builders miss.

The client wasn't buying a faster reply draft. They were buying visible ownership: who holds the ticket, what it's worth, when the clock runs out.

If you sell workflow builds, sell the accountability layer. It's worth more than the speed.

[Alton Syn @WorkflowWhisper]

A founder told me support got calmer after they made ownership visible before asking AI to answer faster.

They added one row above every ticket:

customer value
SLA clock
refund risk
owner
next action
proof it happened

If a £420/month account is 2 hours from SLA breach, the workflow should put Sarah on the ticket before the customer chases.

The reply draft can wait.

Save this for the next time a client asks for an AI support agent.

What field would you add before shipping it?

[Mr Ben @YesJustBen]

Clients don't pay for automation. They pay for the 14 hours a week it gives back.

I quoted a returns-handling build at £4,500 last month and the owner said yes in one call. Not because the workflow is clever. Because I showed him the maths: 2 staff x 90 minutes a day on returns emails, gone.

Price the time saved, not the tech. The tech is the boring part.

[Mr Ben @YesJustBen]

codex sites is interesting, but client work needs a narrower version of this.

i would only sell the autonomous loop after scoping 3 boundaries:

what the app may change
what needs approval
where rollback lives

otherwise you are selling a retainer that can create its own support tickets.

[GREG ISENBERG @gregisenberg]

EVERYTHING YOU NEED TO KNOW ABOUT CHATGPT'S "LOVABLE KILLER" CODEX SITES (in 25 mins):

TLDR; the coolest part is that apps you build can update themselves autonomously

1. Codex Sites is not Replit or Lovable or Bolt. Those are great for one-prompting a full app. Codex Sites is for building apps that the agent keeps improving without you touching them.

2. Your personal website can update its own stats. Your internal dashboard can refresh its own data. Your product can add features while you sleep. The app is alive.

3. Start by invoking at-sites. Use realistic sample data. Always say "save for review, do not deploy." This unlocks building a real product, not a homepage.

4. Add persistent storage so the app remembers everything between visits. Without this it resets every time. Ask Codex to show you the data model before it builds.

5. Create safe actions. These are the specific things the agent is allowed to do to your app: add data, update cards, move things, score things. You define the boundaries. The agent operates within them.

6. Build skills so any future Codex chat knows how to interact with your app. The skill is basically a manual for the agent. Without it, every new chat starts from zero.

7. Save gate like a video game. Codex doesn't auto-save. Create checkpoints before you deploy so you can roll back if something breaks.

8. Close the autonomous loop. This is the magic. Once memory, safe actions, and skills are set up, the agent can update your app from any chat, any context, without you switching tabs.

9. Use the plugins most people are sleeping on. Figma, Canva, HeyGen for avatar videos, Game Studio for interactive experiences, FAL for image generation, Hugging Face for open source models. Worth adding a few.

10. The big picture: we went from building apps to raising apps. You set up the structure, the guardrails, and the skills. The agent does the rest. That's autonomous product building and it's here right now.

Tbh, Codex sites isn't perfect. Still a lot to be desired like domains, db, authentication etc.

But it's a glimpse into this idea that apps can be updated/improved upon automonously.

And Codex Sites is REALLY good if you live in Codex everyday. Which more and more of are.

And that's really cool. Will be interesting to see how Lovable, Bolt, Replit etc react to this.

full tutorial on @startupideaspod where you get your pods

https://t.co/vKRQL70Nds

watch

share with a friend

i'm rooting for you

What do you think of Codex and Codex sites?

[Mr Ben @YesJustBen]

I would rather sell one boring failed-payment follow-up workflow for £1,500 than pitch a vague AI ops retainer.

The buyer gets it in 30 seconds.

Stripe fails. Customer gets a payment link. Account owner gets pinged after 24 hours. Consultant owns the workflow, not the client's whole billing process.

That last line is the margin.

What boring workflow would you package first?

[Mr Ben @YesJustBen]

exactly this. the three checkpoints you're describing are what i use as my scoping questions before i ever quote a project. where do they see it working tells you if they have realistic expectations. who decides if it is good enough tells you if there is a hidden approver. what counts as alive tells you if they will declare it dead the first time it does not match their mental model. three questions that change every project scope.

[Alton Syn @WorkflowWhisper]

Greg Isenberg keeps saying AI businesses fail on client setup, not AI quality.

Most builders will miss the actual opportunity.

The money is not in the AI agent. It is in everything that gets the client to first value before they declare the project dead.

Three onboarding checkpoints I use before the AI step:

1. Where does the client go to see it working?
2. Who decides if the first run is good enough?
3. What counts as the project being alive?

A workflow that answers those three before it touches a single AI node is the product most builders are not building.

What onboarding step do most builders skip first?

[Mr Ben @YesJustBen]

the same logic applies to retainer handoffs. what i built was a shared notion page the client can see: every workflow step, every owner, every failure point. they know what they're paying for before the first automation runs. that's the part most consultants skip.

[Mr Ben @YesJustBen]

i rebuilt my client onboarding workflow three times.

version one: too much automation. clients didn't know what was happening or who to reply to.

version two: barely any automation. i was still chasing everyone manually.

version three: the right amount of automation plus one human touchpoint nobody could automate. a 15-minute video each client watches before their first kickoff call.

that video alone cut my back-and-forth by 60%. no pitch in it, just a walkthrough of what actually happens next.

[Mr Ben @YesJustBen]

the fix costs $0 if you scope it in discovery

who gets pinged when this form fires? if they cannot answer, add a notification node to the build spec

add it after go-live and you are in change-order territory with a client who will push back

[Alton Syn @WorkflowWhisper]

A form that submits into a void is not a lead capture tool.

It is a lead storage problem with a 90-day expiry.

What actually happens: the form goes to your DB, nobody gets pinged, and 90 days later the contact is stale while your CRM fills with ghosts.

The fix: before you build the form, ask who gets a notification when it submits. If you cannot answer that, you are not capturing leads. You are building a spreadsheet with a timeout.

[Mr Ben @YesJustBen]

i stopped doing free discovery calls when i realised the scope document does more selling than the conversation.

send a client a clean one-page scope before the call: here's what i understand, here's what i would do, here's roughly what it costs.

they come to the call already sold. the conversation becomes a confirmation, not a pitch.

the call used to do the selling. now it just closes.

[Mr Ben @YesJustBen]

i stopped doing free discovery calls when i realised the scope document does more selling than the conversation.

send a client a clean one-page scope before the call: here's what i understand, here's what i would do, here's roughly what it costs.

they come to the call already sold. the conversation becomes a confirmation, not a pitch.

the call used to do the selling. now it just closes.

[Mr Ben @YesJustBen]

boring missed-call cleanup runs 6 months without me. owner sees recovered revenue on a monthly digest.

agent demo wins the call, breaks on a tuesday, 9pm whatsapp.

price accordingly.

[Mr Ben @YesJustBen]

I charge per workflow now, not per hour. Here's how I got there.

First year I tracked hours. Bad move. Clients optimize the thing you're measuring.

So I started scoping by the receipt the client needs when it works, not the nodes it takes to build it.

The price is based on:
what breaks if it doesn't run
what the client does with the time it saves
what a failure costs them to fix manually

When a client asks why is it GBPX for this, I tell them what they're buying: the receipt, not the wiring.

[Mr Ben @YesJustBen]

I stopped showing clients the canvas first.

I show 3 lines:

proof it worked
who owns the stall
what gets rolled back if it writes the wrong thing

Smaller build.
Cleaner handoff.
Easier invoice.

That scoping check closes better than another demo.

[Mr Ben @YesJustBen]

I stopped pricing automations by build time.

Now I price the client risk it removes.

750 for a tidy internal handoff.
1.5k-3k when money or bookings can go missing.
4k+ when failure creates a client-facing mess.

Ask: what breaks if nobody owns this on Friday?

[Mr Ben @YesJustBen]

missed-call recovery sells better than AI receptionist demos because the buyer can already feel the leak.

i wouldn't scope it as:
"bot answers calls"

i'd scope it as:
- which leads got missed
- how fast they need a response
- who owns the callback
- what counts as booked, lost, or unqualified
- where proof gets logged
- when a human gets pulled in

the workflow is boring, but the offer is clearer:

"we recover missed enquiries before they turn cold, and show you which ones became revenue."

that's much easier to buy than a generic automation demo.

if you're building this for a client, start with the lost-reason field.

without it, you only built faster follow-up.
with it, you built a sales ops loop.

what missed-call or quote-follow-up leak would you scope first?

[Mr Ben @YesJustBen]

i ask about the failure path before i ask about the tool.

usually the client wants to start with:

"can this work in n8n?"
"can we add AI?"
"can it talk to Stripe, HubSpot, Gmail?"

fine questions, but they are too early.

the first useful questions are:

when this fails, who sees it?
what does failed mean?
how long can it sit?
what proof would make you trust the result?
what should never be retried automatically?

a quote follow-up flow is a good example.

happy path:
lead asks for quote
AI drafts reply
CRM updates
owner gets notified

real path:
lead replies with half the info
quote needs manual pricing
email bounces
owner is on holiday
customer goes quiet
two quotes need different margins

that is where the workflow either becomes useful or becomes another demo.

my build rule now:

map the exception before the automation.

owner
retry limit
stuck state
proof of completion
manual override
friday review of what broke

if those boxes are empty, i am not ready to build yet.

what failure path do most automation builds ignore?

[Mr Ben @YesJustBen]

i stopped selling "ai automations" when i realised clients were not buying the tool.

they were buying the leak getting fixed.

missed quotes.
stale leads.
failed payment follow-up.
client onboarding chaos.

same stack.
different offer.

bad pitch:

"i can build an ai workflow for your business"

better pitch:

"you are losing warm quotes because nobody owns follow-up after the first reply. i can fix that."

the filter i use now:

1. name the leak

what is disappearing?

money, time, leads, approvals, renewals, booked jobs, client trust.

if you cannot name the leak, you do not have an offer yet.

2. name the owner

who currently notices when it breaks?

if the answer is "whoever checks the inbox", that is the problem.

3. name the failure path

what happens when the customer does not reply?
what happens when the payment fails twice?
what happens when the form is missing one field?
what happens when the AI is unsure?

the failure path is where the client feels the value.

4. price against the leak

a £3k workflow is expensive if you sell nodes.

it is cheap if it recovers £1k/month in missed bookings or saves 10 hours/week of admin drag.

5. prove the outcome

not "the AI replied."

proof is:

quote sent
owner assigned
payment recovered
client onboarded
lost reason logged
friday report shows what changed

most builders open n8n too early.

the better move is boring:

pick one leak,
define the owner rule,
map the retry path,
then build.

what workflow leak are you seeing most often right now?

[Mr Ben @YesJustBen]

https://t.co/nzGtuWvlZg

[Mr Ben @YesJustBen]

quick way to tell if an automation idea is worth building:

price the leak first.

ask:

1. what repeats?
2. what happens if nobody does it?
3. how many minutes does it burn each week?
4. what money gets delayed, lost, or put at risk?
5. who gets pinged if it fails?
6. what proves it worked?

if the answer is just “it saves time,” i usually keep digging.

better answer:

“this takes 90 minutes/week, delays $2k in invoices, and nobody sees the failure until friday.”

now you have a workflow worth building.

i made a 15-minute worksheet for this.

comment `CHECK` and i’ll send it.