All right. So, I've sold over 100 AI

automation systems and I've priced a ton

of those wrong. I've undercharged, I've

underscoped, and I've just thrown out

random numbers that were kind of a guess

and I couldn't explain when someone

actually asked me like, "Hey, where'd

you get that number from?" So, in this

video, I'm going to talk about

everything that I know about pricing AI

solutions. I'm going to walk you through

one real build that I sold, every single

number, and by the end of this video,

you'll be able to take any project, turn

the client's own numbers into a price

that you can actually defend, and then

get paid in stages so you're never

carrying much more than, you know, 30

days of unpaid work. And if you don't

know who I am, my name is Nate. I've

been teaching hundreds of thousands of

people how to build AI agents and how to

implement them into businesses as well,

and I scaled my agency to over $100,000

a month and then I sold it. With our

business, we got to the point where the

minimum to work with us was a $20,000 a

month retainer. And I'm assuming that

sort of engagement is where a lot of you

guys want to end up getting to. So,

let's not waste any time and let's just

jump straight into today's video. Okay,

so this example was an appointment

setting agent. The business had

employees manually setting these

meetings, and this was about 20 leads a

week, each one taking roughly an hour of

a human's time. And those employees were

costing the business about 40 bucks an

hour all in. So, 20 hours a week at $40

an hour is about 800 bucks a week. And

if you multiply that by 52, which is 52

weeks in the year, that's $41,600

annualized. And before I said anything

to the client about price, I walked them

through the entire solution, you know,

how the agent would work, what testing

looked like, how it would change their

speed to lead and their lead quality.

But I also had to ask them a ton of

questions through what we call the

discovery phase because some clients

want to talk about price right away. But

the honest answer to them is, you know,

in order for me to give you an accurate

ballpark estimate of what this is going

to cost, I really need to understand

more in depth the complexity of the

system and how it will actually look

once it's fully integrated into your

actual business processes. Then I priced

the build right around 13% of what that

annual number was, which came out to

5,500 bucks. So, the business would

basically be paying $5,500 for a system

that over the course of the year was

going to give them back $41,600,

which comes out to about a 7.5 multiple

on their initial investment. Now,

typically I like to say the golden rule

is that you need to be able to show the

client that their investment is going to

10x over the course of the year because

that math makes it really hard to say no

to. So, in this specific example, where

I accounted for that extra 2.5x that we

were missing that would put us at 10 was

the baseline. So, right now the baseline

was about 20 leads a week, but as the

business earned more time back because

of the system and this whole process

gets more streamlined, that baseline of

leads per week would probably start to

increase, right? It would go to 21 and

then 23 and then 27. And that's where we

are earning them even more money back.

Now, obviously something like that is a

projection and you can't just go in

there and say that you can guarantee

that. So, be careful about making any

guarantees or trying to tie revenue to

those specific results or anything like

that. But, the general idea is that as

the system gets used more, the business

will grow, which in turn utilizes the

system even more. So, you create this

really cool like flywheel. And then on

top of the build, we set up a standard

maintenance plan. So, this was 400 bucks

a month. And I want to be clear what

that actually is because a lot of people

kind of

misinterpret this word maintenance. So,

that $400 a month isn't for me to bolt

on new features every month. It's just

me guaranteeing that the build keeps

doing what we agreed that it would do.

Meaning if something breaks or an API

changes or you know, maybe a new model

releases or some weird edge cases show

up that need a little tweak in order to

keep the system living up to the

functionality of the scope, that would

be on me and that's covered by the

client's retainer fee. But, new

functionality is a completely separate

conversation. So, with maintenance

retainers, I always keep the numbers

super simple and standard across all

projects. And at this point in my

career, our maintenance package was 400

bucks a month. You just do want to be

careful though because if you're

delivering a system that's, you know,

let's say $30,000, if maintenance on

that solution is going to cost you and

your team more than 400 bucks a month,

meaning you would be like losing money

on giving away that package, then

obviously you can't charge that. But I

think that with well-designed

automations and well-built automations,

it really shouldn't be too

time-consuming for you to maintain them.

Because once again, there's a big

difference between maintaining and

adding minor feature enhancements and

adding, you know, more functionality.

Now, a big mistake that I made in this

specific project was that once I was in

production, what I should have done was

gone back and measured how valuable this

thing truly was. And I didn't do that.

So, I had no after state. I had no

transformation number. And what ended up

happening is that cost me on the next

conversation when I tried to win more

business. So, make sure you're capturing

the baseline up front, which in this

case was, you know, like 20 leads a

week, and the speed to lead time because

that was taking the humans, you know,

time. And then, you follow up after a

month, and after 2 months, and after 3

months, and you prove to them that those

numbers are moving in the direction that

the business wants because of your

system. And I know that this might kind

of feel like bragging, but it's not, you

know, because if you don't put a

spotlight on those numbers, even if your

automations really, really are helping

the business, the business owner might

not actually feel that and won't

acknowledge that. So, it's really

important that you're the one surfacing

that stuff. Okay. So, the obvious

question is, why not just bill hourly

and be done with it? And I want to give

a quick shout-out here. A pricing guy

named Jonathan Stark came and spoke at

AI's Live, and he made some really

amazing points on this topic. So, I'm

going to talk about some of the things

that he brought up. But really, the

problem with hourly is that it pays you

more to be slow. I mean, picture two

people on your team. You're billing them

the same, 150 bucks an hour. Your best

developer and your slowest one. Some new

feature comes in, and your best guy

knocks that out in a day, so you bill 1

day. But your slow guy takes 3 days, so

you bill 3 days. You just made three

times the money off of a worse, slower

employee. And if your best guy gets

faster, then you're going to make less

money off of him. So, getting good at

the job actually cut your income. It's

all about incentives. Would you want to

hire someone who is incentivized to work

slower in order to get more money out of

you? Probably not. I wouldn't want to.

But now think about that in, you know,

2026. You get really good with cloud

code or whatever tool you're using, and

you can do something in an afternoon

that used to take you a week. And if

you're hourly pricing, then that

afternoon, because you move so fast,

just slashed your income. So, I'm not

saying hourly's never okay. I think for

your first two or three projects, when

you've got, you know, nothing to point

at, not a bunch of proof, then billing

hourly is a safer ask. It's a It's a

easier ask for the business owner, and

it's a good place to start. Maybe just

like 100 bucks an hour. But after that,

quit billing hourly. By the way, guys,

if you want to access this completely

free resource, which is like a 27-page

doc on pricing your AI services, then

you can grab that, like I said, for

completely free by joining my free

school community. The link for that is

down in the description. All you have to

do is jump in here, click on classroom,

go to all YouTube resources, and then

find the resource in there. I promise

you guys it's in there. But let's get

back to the video. So, if you're not

pricing off hours, then what are you

pricing off of? Well, there's three

things to keep straight. So, those three

words are cost, value, and price. So,

your cost is the floor, the number that

you'd walk away if, you know, it was

below that. Their value is the ceiling,

the most that this whole thing is even

worth to them in the business. And the

price is any number between the two of

those that you guys can land on. Now, on

an AI build, that gap is pretty

enormous, because whatever it cost you

to build the thing and harden it, their

ceiling is a higher. They now don't need

to make. And just remember this, cost

doesn't justify price, price justifies

cost. And Jonathan made a really great

example of a landscaper here. So, let's

imagine a landscaper mows your lawn

every single week for 100 bucks. Then

one week he shows up, he does the same

job he's always done on the same exact

lawn he's always mowed, and now he tells

you it's 200 bucks because he bought a

fancy new truck and his costs went up.

That's not how it works. Nobody accepts

that. Cost doesn't justify price. Price

justifies cost.

Okay, so the client's ceiling is the

number you're actually pricing off and

you get one conversation to find it. So

as you're getting to know the business

and getting to know about the

automations that they need, you're

trying to uncover scope just as much as

you're trying to uncover the value to

the business. So you open by letting

them dump everything. You know, tell me

everything you know about this, what

you've tried in the past, what's worked,

where it keeps getting stuck. And your

job is to just listen, repeat, and poke.

And just run that LRP framework to get

as much information as you can. Take a

ton of notes and then you pivot. Ask

them about what happens after we're done

with this project. You know, what is the

best case scenario and what actually

changes for the business once this thing

is successfully up and running.

And then you run three buckets of

questions. Why this? Why now?

And why me? So why this is checking that

what they asked for actually gets them

the outcome that they want because a lot

of the time it doesn't. And because

they, you know, walked in asking for an

AI agent, but the real fix might be a

really simple deterministic script and a

Slack notification.

Then you ask why now and this is about

urgency because if a window is closing

or if a competitor's breathing down

their neck, then that's real money to

you.

And then why me is the kind of

uncomfortable one, but you literally ask

them, you know, why wouldn't you just do

this internally? Couldn't you vibe code

this? Couldn't you hand it to an intern?

And the reason you want to do this is

because these questions or that question

specifically surfaces objections that

are already in their head. So either you

can hear it now while you're on the call

with them and you can answer those

objections and handle them or it's going

to kill the deal later down the line

when they're reading your proposal or

talking with their team. And when they

give you a real answer like, yeah, you

know, my nephew probably could build

this, you don't argue. You you yeah, he

probably could get a version of this up

and running, but what I'd want to know

is who's going to watch it at 2:00 in

the morning when the model updates? And,

you know, who's going to help you scale

this when you have way more throughput

than you're expecting? And when it gets

a bit more complex?" And then what you

do is you stop and you just let them

answer, because their answer is the

actual reason that they're looking to

hire someone. And if you find that

you're in a situation where they just

keep pushing you for a number, if they

keep pushing for a price before you can

ask these questions and before you can

really dive in, don't blurt one out. And

honestly, if they keep pushing you for a

price and all they want is to get a

quote out of you so they can compare you

across a few different other vendors,

then I would say that's probably a red

flag and you just want to get out of

that engagement, because

the hard truth is some people are just

looking for the cheapest labor. They're

not really looking for a consultant or

partner, and that's how you want to

position yourself. And there's

unfortunately not much you can do to

change that person's mind, besides

telling them, "Hey, you know, what I

bring to the table is different. I bring

a different level of expertise, and you

know, that's where you really want to

leverage your proof." But ultimately,

some people know that they could go to

Upwork and get much cheaper labor, and

that's just what they're going to do.

So, don't take it personally. Okay. So,

the obvious problem with a lot of this

is that

a lot of clients won't just hand you the

numbers. Like, they don't want to tell

you salaries and exact bottom line

numbers and things like that. And they

don't have to. So, start with three

questions.

How long does this take you today? How

many people touch it? And what happens

when it goes wrong? These are all sizing

questions. They measure the ceiling, not

the build. Then, you keep stacking proxy

questions on top. Like, you know, "Oh,

how many locations do you have? Or how

many of these come in on your busiest

days?" That kind of stuff.

And I know some of you are on a job

marketplace where you have to put a

number in your proposal before you even

get a chance to talk to that person. And

you can still kind of do a version of

this. The job post almost always tells

you things like volume or head count, or

you can figure out some complexity

there, how often the thing happens. You

size it off that, and say your

assumption out loud. Something like, you

know, "Oh, I've priced this assuming

that there's about 200 of these a month,

and

you know, if that's off, let's hop on a

15-minute call and I can adjust the

price and we can rework the scope a

little bit. But that basically just

turns the cold price into a reason for

them to hop on a call and talk to you.

And here's a quick check. If you can't

land on a number, if you feel like you

don't understand the value enough to

accurately give a number, then that's

probably a signal that you're not ready

to write that proposal yet. You need

more information. Okay, so now you've

got that value number. From that total

annualized value number, first year

annualized, what I like to do is pick

somewhere between 10% and 20% of that

number as my starting point. So, you say

your price. You assume the next sentence

out of their mouth is "Can you walk me

through how you got to that price?" And

you basically have to answer that

confidently. You have to say, "Okay,

yeah, this is a customer support

automation. It takes a rep an hour a day

manually and an hour of that rep's time

is about 50 bucks, right? Like that's

how much it's costing the business."

Over a year, that equals about $12,000

to the business. So, 10% of that $12,000

is $1,200. So, the build is 1,200 bucks.

So, conservatively, you will be 10x your

investment of that $1,200 just in the

first year. And when you go to write

this up, don't just send one price. What

I've always done is tiered packages, so

you can have like a starter, a growth,

and a scale, or whatever you want to

call them. And before you get anywhere

near the options, the top of that

proposal is three short paragraphs and

none of them are about you or your

pricing. They're about where the

business is right now in their words

with their numbers in it. Where they

said they wanted to be and why you're

the person that can help them get to

where they want to be because of your AI

expertise and your systems. So, you

would then take the first year value.

Let's for now just call it 100 grand to

keep numbers even. You could say option

one is 10%, so $10,000. Option two is

25%, so 25,000. And option three is 50%,

50 grand. And I'm just kind of throwing

out rough numbers here. But obviously,

as you move up those tiers, you have to

have different sort of, you know, value.

It still has to make sense. You have to

have more functionality or you have to

have different types of results tied to

it, right? But

the middle one is kind of the one that's

designed to win because the bottom one

looks thin, the top one maybe makes them

wince a little bit, and the middle one

looks more correct. And what this does

psychologically is really interesting

because if you give them one number,

their decision is, "Hmm, should we work

with this person?" But if you give them

three numbers, their decision is more

around, "How should we work with this

person? You know, like which one of

these deals should we take?" Okay.

So, one of the most profitable

automations that I've ever seen was one

of the simplest because all it did was

it took a construction crew's daily

phone orders and converted them into the

text format that the crew already used.

That was it. It was super simple. It

only saved like 45 minutes a day, but it

helped them avoid around $12,000 a month

in scheduling errors. And that second

number isn't freed up hours like the

earlier example was with the appointment

setter. It's hard dollars that they were

losing every single month because of

errors, because of the inconsistency of

humans, which is why the saving 45

minutes a day was worth so much more

here. And the reason I'm telling you

guys this is because typically a good

place to start is by thinking about the

hours you're saving. But as you get a

little bit more comfortable and you have

a little bit more experience behind you,

you start to think about the bottom line

impact of the entire business. If you

think back to the earlier example about

the appointment setting agent, we

basically only attributed the value to

the time we were saving, to the time we

were buying back the business. But what

if we would have thought about how much

does a converted appointment actually

make the business? So, all of these um

appointments that we're helping set with

our system, what if each of those closed

sales was worth $5,000? We could have

valued that system way higher. And if we

would have communicated in that way, we

probably could have charged way more for

that automation.

So, like I said, as you get more

experience, start to think more about

that. But once again, it's your job to

communicate that value because the

business owner isn't just going to see

that like that immediately. Okay. Now, I

want to talk about underscoping. This is

the number one mistake that I made when

I first got started. And then what this

caused was, you know, timelines to get

pushed and

arguing about milestones, right? So,

here's how I structure this kind of

stuff so that that never happens. Now,

this video specifically isn't about

scoping. That's a different topic

entirely, but this is kind of more about

setting up the milestones in the correct

way.

So, what I would do, let's say we have a

$9,000 project and we want to split this

up into major milestones. So, let's say

we have one milestone at the halfway

point and one milestone, you know, once

this thing has been pushed into

production. And I like to think about

those as far as like, what do we think

we could deliver in 30 days? So, each

milestone is 30 days apart and that's

where you're going to get paid is

essentially every 30 days. Then, what

you do is you could split this into

three payments if we have two major

milestones. One to get started, the

second one after the first milestone has

been hit, and the final one after the

final milestone has been hit. But, this

only works if each milestone itself

cannot be argued with. It has to be so

objective. It can't be subjective,

right? Like, there can be no ambiguity

there, which we run into a lot. So, you

know, here's what an objective one could

sound like. At this milestone, there's

an AI system in the business owner's

hands, a POC, a proof of concept, that

they can actually talk to. And when the

owner sends it a question, the agent

pulls from the database and responds

within a minute. All of that stuff is

provable and it's very simple to write

down and the client could go prove it

itself. It's not claiming that the

database is perfectly optimized yet.

It's not even saying that all the

answers are perfect or correct. It's

just saying that it works and it pulls

there and it responds and that's

objective. Now, a subjective milestone

maybe could be something that's

obviously easy to argue like, oh, the

inbox agent is working as expected.

Okay, what's expected? You and the

client could potentially go back and

forth on that for weeks and you're not

going to get paid and it's just going to

get frustrating. And then what else

could happen is they start to ask for

things that weren't on the original list

because it's so ambiguous. And they

might say, you know, can you add this?

Can you add this? That's not, you know,

this is a milestone. I need this

functionality. And so, what you want to

do there is if they do start to try to

scope creep, this is actually a great

sign because it means that they're

excited and it means that they're

already starting to imagine working with

you more. So, the way that I handle

this, I don't say, oh, no, right? Like,

I say, yeah, it's a great idea and I

could could see how this would add value

to the system. Let's go ahead and throw

this on the backlog for our version two

of the project. And as you get more

ideas, you can just add more stuff to

the backlog. Because I just want to make

sure that we're hitting the milestones

that we've already set as quick as

possible for you guys, so that we can

deliver as much value to the business as

possible.

Okay. Now, let's talk about what you do

if they see the numbers that you've

presented, your price, and they don't

like them. And they're saying, "Oh, you

know, this is way more expensive than I

thought it was going to be. I didn't

really have a good gauge. This is not in

our budget."

So, what you want to do is say something

like, "Okay, it sounds like 20 grand

isn't in the budget right now. Why don't

we just like reduce the scope a little

bit and start with a smaller project?

And once this is working and winning you

guys back some time and some more

business, then we can move on to the

next piece together cuz we've kind of

already got it scoped out." And that's

how you can avoid teaching them that

your price has moved down every time

that they frown. And you're also not

devaluing the work that you would be

doing. You're just reducing the scope,

and that keeps it pretty fair. And the

last thing that I wanted to address here

was the other costs that typically go

along with these systems, which are API

costs or cloud subscriptions and, you

know, token usage, things like that.

Now, I have always said client's

account, client's card every single

time. Your fee is for design,

consulting, building, testing. Now, the

tokens are a utility bill, and utility

bills go in the client's name. I used to

start off by running everything under my

own billing and invoicing them each

month, and it just got super messy. I

was babysitting the billing. I had to

follow up with clients. Obviously, I

built agencies to do that, but still it

wasn't fun. And it also left them with

no idea what they were paying for and

potentially misaligned, you know, some

trust.

And what else you should do is probably

give them an expected monthly run cost

in the proposal with the volume

assumption next to it. Now, obviously

not a guarantee, but an estimate of how

much this thing will typically cost per

month when it's fully in production and

how ideally the system starts to get

used more and more over time, like month

over month. So, the costs are probably

going to scale up a little bit month

over month as well. Now, one thing that

you do want to think about in your

pricing is that there are typically a

decent amount of testing costs that go

into the system. At least if you're

doing it right, you're spending a lot of

money testing before you push anything

into production for a client.

And these testing costs could genuinely

be anywhere from 100 bucks to a few

thousand dollars based on how rigorous

your Evals and your QA process is, which

I think should be pretty, pretty

rigorous. So, I would usually just

factor that in to our final price by

just bumping it up by like a thousand or

two or three thousand dollars, depending

on the size of the automation and how

much testing you think is going to go

into it. Obviously, the more AI that's

in there, the more autonomy, the more

testing you're going to have to do. And

the whole thing, the way I feel about

pricing right now is that even the

biggest firms, McKinsey, Salesforce,

everyone's trying to figure out this AI

pricing thing and no one has the right

golden answer. And I think that a lot of

people might disagree with some of the

things that I'm saying here, and that's

okay. But, I didn't feel like it was a

great feeling to say, "Hey, you know,

Mr. and Mrs. Client, can you please go

ahead and give us this API key and this

one and this one and this one?" And then

before we're even giving them any sort

of POC or showing them any value, we're

already spending a few hundred of their

dollars just testing the system. I just

don't think that's a very good way to

kick off a partnership. So, basically

what I meant by that is in the testing,

we paid for everything, and then when we

moved everything into production, we

swapped out their API keys for, you

know, compute and whatever else it was

that was

costing us. Okay, so if you take one

single thing out of this into your next

discovery or sales call, make it this

one.

Before you say any number at all, get

the client to tell you what the problem

is costing them. In their own words,

just have them say it out loud. And then

once that number is on the table in

their language, your price is just a

fraction of a number that they have

already stated. So, what you're selling

is the result, and the bill is just how

it gets delivered. Okay, so I just did a

ton of talking, and um what I'm going to

do is I've wrapped everything up that I

talked about and some more into a full

pricing masterclass document in my free

school community. So, if you guys want

to access that, once once completely

free, just use the link in the

description to join that community and

grab the resource. But anyways, that is

going to do it for this one. If you guys

enjoyed, you learned something new,

please give it a like. It helps me out a

ton. And always, I appreciate you guys

making it to the end of the video. So,

I'll see you on the next one. Thanks,

everyone.