How to Price AI Workflows (Without Losing Clients)

Everyone's been asking how to actually price AI workflows. What's too cheap? What's too expensive? And how do you charge enough without losing clients? So, in this video, I'll break down exactly how to price your workflows step by step. And at the end of the video, I'll give you guys a practical breakdown of a real example of how I priced one of my workflows. So, let's get into it. Before we get into numbers or frameworks, you need the right mindset around pricing. Most beginners price their workflows based on the time it takes or the amount of effort that they put in. But businesses don't pay for your time. They pay for outcomes. When you build an AI workflow, automation system, infrastructure, whatever you want to call it, you're usually doing at least one of three things for a business. Saving them money, saving them time, or reducing human error. That's where the real value is, and that's what your price needs to be tied to. This is called valuebased pricing. You're not charging for the inputs. You're charging for the return on their investment. And when you start thinking this way, everything changes. Instead of asking yourself, how long will this build take me? You start asking, how much time or money will this save the business every week? How much more can they generate because of this system? Now, I know it can feel awkward when you're new. There's always that weird dance of like, who's going to throw out a number first. And realistically, a lot of clients right now genuinely have no idea what this kind of stuff should cost. But here's the part that you need to nail. Whatever number that you say, you should be able to show them exactly how you got there. You should almost assume that after you tell them your price that they're going to say, "Can you tell me exactly how you got to that number?" You need to be able to confidently walk them through that math. Because when you can explain the ROI, not only do you build trust, but you come across as a long-term AI thought partner, which is what businesses desperately need right now. And when you explain that clearly and you anchor that price on real metrics, suddenly the price doesn't feel like an expense anymore. It feels like an investment that will pay for itself because it will. So once you've got that mindset locked in, the next step is learning the actual pricing models that you can use. So before we dive deeper, I want to be clear about something. I've tried almost every pricing model that you can think of. I've charged a fixed fee and delivered a JSON file. I've built hourly. I've sold bundles of hours. I've done monthly retainers with no set scope. I've done retainers with strict scopes. I've literally experimented with tons of different models. And the reason I'm telling you this is because I don't believe that there's currently an industry standard way to price AI automation and implementation services yet. Nobody has agreed on the right way to price workflows. Everyone's still trying to figure it out. But after trying all of these different models, there are definitely two that I think work the best and they work together. So, let me explain what I mean by that. They're simple, they build trust, and they're the easiest to scale. So, the first model is valuebased pricing. If I were starting from scratch today, this is the model that I would start with. Valuebased pricing is where you charge based on the business impact like we talked about, not the hours that you spend building, anchoring your price around time save, money save, or efficiency gain. This is the easiest way to get your foot in the door with a new client because the math is simple and it builds trust. What's interesting about valuebased pricing is that you can build the exact same system for two different businesses and you can charge them completely different prices because value is not universal. If you tried to sell me a bottle of water right after I've run 5 miles in the desert, I would pay you a lot more than someone who's been sitting inside air conditioned office all day. It's the same product, but it's different value. And that's kind of the idea behind this value based pricing. So, you price based on what the solution is worth to that business. Now, once you deliver one or two projects, you build some trust, and you show that your systems work. This is where you start moving into longerterm engagements, which is the next model, monthly retainers. A monthly retainer is when a client pays you a predictable monthly fee in exchange for ongoing access to your expertise and a defined level of service. In the consulting world, these can range anywhere from 1,500 to 15,000 or more per month. And it's usually within a 3, 6, or 12 month term. And here's why retainers matter. Clients get predictable costs and priority access and consistent improvement. You get stable income and a long-term partnership instead of chasing one-off builds. And honestly, you'd much rather work with one $15,000 per month client than five $3,000 per month clients. Even though the total revenue is the same, you'll have less chaos, less stress, and you get to build a real relationship. You get to put all of your time and energy towards that one business. You get to overd deliver, drive real results, which is going to increase the chances that you're able to win more business in that organization. So, that will lead to higher CLV or LTV, customer lifetime value, and potentially more referrals, which is more business that is also warm, and there's more trust, and they're easier to close. Now, retainers do come in different styles. They could be based on hours, based on deliverables, or hybrid. Personally, I would recommend sort of a milestone-based retainer. Hours make you look like a freelancer. Milestones position you as a consultant, an AI partner. But a big question I get when I kind of talk about this is, how do I keep using valuebased pricing inside a retainer? At this stage, your goal kind of shifts because you're not trying to squeeze maximum value and money out of each individual project. Your priority becomes building trust, stacking wins, and increasing the retainer over time as your impact scales, almost like you're trying to work your way into sort of a chief AI officer type of role. Plus, as these systems get complex, it's harder to deliver, test, and refine everything in a single month. In fact, that's actually just really unrealistic, especially if you want the system to be fully QA before production and then in production, taking time to iterate and constantly refine. So, what you'll probably find is that you're naturally going to be making more total revenue on this model anyways. And it's a lot more predictable. So, the less time and energy that you spend on worrying about where your next dollar is coming from, the more time you spend making a real impact. And that opens the door for higher retainers or even performance bonuses tied to key business metrics. And don't forget, you'll also be maintaining the previous systems, updating things when new models come out, fixing bugs, making sure that you're, you know, staying on top of any updates, and just keeping everything aligned with the original scope. That alone justifies ongoing fees. So, the last thing I'll say is this. We're still early. Businesses need enablement, audits, education more than ever. They don't know what's possible, and they don't know where AI fits into their operations even though they know they need to start using it. So, if you're already that person who's been wrapped up in their ecosystem, delivered real value for them, they'll happily trust you to guide them through that process, too. And if you guys want, I can make a full breakdown video on audits, enablement, and actually structuring sort of like educational offers. Just let me know in the comments down below. But anyways, after you've picked the right model, the question becomes, how do you actually figure out what exact number to charge? So, this part always goes back to your discovery phase because you can't really give a real price if you don't understand the current manual process in its entirety. That's your job during discovery. Before you think about pricing anything, you need to map out the process from start to finish. So that means you need to understand things like how often does the process happen, what triggers it, who the key stakeholders are, how long it takes each time, what each hour of that work is worth in dollars based on salary, number of employees involved, or even software costs, and other things of that nature. And then once you know all of that, you can start comparing the manual version to what the automated version of that system would look like. But the key here is you just can't overpromise results. You have to be realistic about it. So maybe you're building a system that only automates half of the process. And make sure you're factoring in that half, not automating that full process into your ROI. But the idea is the second the workflow goes live, the business instantly starts getting back time, money, and focus. And it's your job to translate that into numbers that the client can understand. So here's a simple example. Let's say the process you're automating is a customer support process, and it takes the rep one hour every single day. Let's say 1 hour of their time is worth $50 over the course of a year. That's roughly $12,000 worth of time that they're spending on that task. So that means that the workflow you're building is saving the business $12,000 annually. And this is where valuebased pricing kicks in because as a good rule of thumb, you want the client to be able to see a 10 times return on what they invest in that first year. So if the workflow is going to save them $12,000, 10% of that would be $1,200. And that's your starting point for pricing. You see how easy it was for me to explain that to you? That's exactly how you would just want to explain it to a client. When someone asks, "How did you come up with that number?" You walk them through the math step by step. It's going to build instant trust. And this doesn't even include opportunity cost because freeing up an hour of that employees time every single day doesn't just save the business money. It's also enabling that employee to shift their time into higher value work. Real revenue generating opportunities. Answering fewer repetitive customer support tickets might mean that they can support new hires, talk to high-v value customers, or help improve systems, things that actually push the business forward. That's why the ROI often compounds. Maybe month one they save $1,000, but maybe month two it's 1,500. Month three it could be $2,000. So over a full year, it could end up being far more than just that $12,000 that you originally projected. And when the value grows, so does your pricing power. Now, once you do a couple of these projects and you've built some trust, that's when you can start to talk about retainers. And this is where the math does shift a little bit because now you're not pricing for one workflow. You're pricing your time, your team, if you have one, and your ongoing support. So with a retainer, you want to protect your margins. Think about what does it cost for you to operate and for you to deliver. What is your time worth? What does it cost if you bring on a developer? What does it cost if you maintain the systems that you've already built? Even if you're not selling hours, you still need to understand how much time things are taking because this helps you think about staffing for milestones. Here are the questions I would ask myself. Is this just me working full-time inside the client's business? Does this require a part-time engineer? Does it require a full-time engineer? Does this also require an account manager or a project manager? Once you know those things, you can start to estimate what it costs you as a business to run every month. So, let's say you figure out that servicing this particular client properly would cost you $5,000 per month. In the consulting and agency world, the general target margin for this type of work is 50 to 70%. 50% is a good baseline to shoot for. 70% is great and it gives you room to scale. But just remember that we're in a service-based business where the work is very custom and bespoke. So you have to make sure you're protecting at least 50% margin. Otherwise, you may struggle to pay your employees and it could just get messy. So in this case, if it costs you $5,000 per month to deliver, you might want to price the retainer at $10,000 per month. That gives you a 50% margin and a lot of breathing room to bring on help or expand the scope later. And this is why I always tell people to start solo or with one developer because the second that you start juggling multiple clients and multiple engineers, your margins can shrink fast if you're not careful and doing projections like this. If you've got a developer on salary, you never want them sitting idle because you overestimated workload or promised unrealistic timelines because that's how agencies burn cash. If you've got some developers kind of on the bench as hourly contractors, it's not as damaging to the business, but still not the ideal situation. So when you think it through and you protect your margins and you build a repeatable way of delivering, that's when you get predictable profit. And predictable profit is what actually lets you scale, make more hires, bring on new team members without tons of stress. Now, even if your price is perfect and you have all the ROI calculations to back it up, how you present it makes all the difference in whether a client says yes or no. And here's the key. You never start with the price. You want to start with that transformation before you ever say a number. You want the client imagining what the business looks like once that system is live, what their team's day-to-day looks like, what problems disappear, what becomes easier, and once they're bought into that outcome, the price starts to make more sense. When you walk them through the proposed solution, you want to explain exactly everything that's actually included in that total cost. So that usually looks like setup, hosting, testing and quality checks, optimization, their involvement in what you need from them, documentation, enablement, and training, and if the conversation goes there, maintenance. And when the client understands everything that's included, it will also be much easier for them to see your price as an investment instead of just some random expense. This is also where visuals help a lot. So simple screenshots, a small wireframe, or even a rough diagram of the workflow can make the process feel real and tangible. If you've got a working demo or past case studies, this is the perfect moment to use them as well. Even in discovery, I talk about how important it is to be writing down all the steps while you're sharing your screen so the client can see exactly, you know, what you think of the process and make sure you guys are aligned. Same thing with a wireframe. and then you guys are fully aligned before you ever talk about money. Because one of the biggest mistakes that I made early on was having scopes that were way too vague, way too ambiguous. I would deliver something and the client thought that it needed more. And we ended up going back and forth debating what done actually meant. When you present your proposal, be very clear about what the final outcome actually looks like. Spell it out, what's included, what isn't, what counts as completion. You should have a very clear, bulleted list of the exact functionality requirements of the system in this scope of work. This will save you frustration. It protects your time. It sets the relationship off on the right foot and it prevents scope creep because naturally as you start building and the client starts to get updates and give you feedback, you guys are both going to realize that there's different features you'd want to add into the system. And in that case, you just have to say, "Hey, I'll add these to the backlog, all of these feature requests, and when we do a V2, we can add them all in." And also, what you're doing there is you're planting a seed that there will be future work between you two. Something else that you need to make clear is the QA process, the quality assurance process. Even the best workflows need a real testing period before they go into full production. And even then, you want to consider constantly monitoring them and evaluating them. That means you first have internal QA, internal testing. Then you have the client do testing and feedback and you fix bugs and you add small adjustments and then you do another round of internal QA, client QA. Finally, you're able to evaluate it with live data and then consider pushing it into full production. And you need to make sure that they understand their role in the process because they're going to have to give you access to tools, provide test data, answer questions quickly, give you feedback, and if they're slow and unresponsive, then everything kind of slows down and that is not on you. So once again, setting these expectations up front makes the project smoother for both sides. Now, of course, not every client will instantly agree. So you do need to know how to handle objections without lowering your value. If they push back, adjust the scope, not the price. Reduce complexity, remove a feature, break it into phases, but don't discount the value that it's actually providing. And as you talk to more clients who start to notice these patterns in their objections, and once you see those patterns, you can start to address those concerns before the client even ever brings them up. This is how you remove those hidden costs and it builds a lot more trust. When someone is budget sensitive, bring the conversation back to the long-term value instead of the short-term expense. You can remind them that the goal is to save time, money every single month, not just to have something built. It's also super important to understand when to walk away. Just because someone is willing to pay you $10,000 upfront, that does not mean you want them as a client. If they undervalue your work, question every step, or they show early signs of being a difficult partner, walking away is often the best decision. Protects your energy and your reputation. A lot of times, it just might be a feeling that you get in your gut. One of the most common questions I get is about intellectual property though, so I thought I'd address that here for you guys real quick. Clients want to know if they will own what you build. Now, the simple answer is yes. It's just the best way to handle it. All IP that we build for them is theirs. I usually handle this by saying, "Yeah, we build on open infrastructure. We use internal components or templates to speed up development. But the real IP in the system is the prompts, your data, your workflows, and how everything is combined in this ecosystem. So that's very specific to your business and provides no value to anyone else. You're not losing anything by giving them ownership. Just make sure you're protecting your own reusable components, though. So, that's only one example of an objection. In the free resource guide that will come with this video, I'll add like six more common objections and exactly how you can handle them. You can download it for free inside my school community. The link for that will be down in the description. So, once you've closed a few clients, the next step is turning those one-time projects into consistent recurring income. Even if you're not on a full monthly retainer, you can still introduce simple recurring services that can benefit both sides. These are small add-ons that create stability for you and peace of mind for the client. and they're easy for clients to say yes to because they're tied directly to maintaining the system that you already built. So, here are a few examples. The first one you could do is a maintenance fee. This is one of the simplest add-ons. You can charge a small monthly fee to make sure that their workflow stays healthy if an API changes, if a model updates, if something breaks, or if the client needs minor feature enhancements. You're there to keep everything running smoothly. It's a light retainer that covers reliability and support. Now, this could be a flat monthly fee, something like 200 to 1,500 bucks per month per system. Second option is kind of optimization and monitoring. This is another option that is ongoing optimization. You can check the systems weekly or monthly, review logs, look at outputs, and tighten things up so the workflow keeps improving over time. This is really good for AI heavy systems because the prompt tuning, the new models, the quality checks, and the retrieval steps often get better the more that you iterate and the more feedback you get from the real world. And then the third one is expansion projects. This one's big. Like we talked about earlier, whenever you sell a valuebased project, you and the client almost always uncover a backlog of improvements, new ideas, or version two upgrades. and that's completely normal. It's also a perfect opportunity to turn a one-off project into a longerterm partnership. Now, the beauty of these different retainers is that you could sell just one of them or all three of them as a package. You can think about pricing all of these different retainers as a monthly fee, maybe somewhere from 200 to upwards of 1,500 per month, but you could also do it as an hourly maintenance package where you would give them maybe 5 to 20 hours per month and assign a dollar amount to those hours. Or the last way, which is probably the best way to do it, would be a percentage of the original project cost, anywhere from 10 to 25% of the price that they paid. So, recurring revenue makes your income more predictable. It makes your month-to-month more stable. But the real purpose of these add-ons is relationship building. Because every time that you handle maintenance, optimize something, or help them launch a V2 or a V3, you're reinforcing that you understand their business, their workflows, their processes, and their goals better than anyone else does. And that's how you become the partner that they trust, the person that they can call when something important needs to get built. And the deeper that they become integrated with you, the harder it is for them to switch vendors. You're embedded. You're the one who knows how everything works under the hood. And that's leverage. The more value you provide, the more expansion work you will likely unlock. And that's how you build a business that grows consistently instead of constantly trying to find new clients. So to make all of this easier to repeat, it helps to have a simple internal framework that you can follow every single time that you price a workflow. That's why I came up with the price framework. It's a five-step process that takes all of the guesswork out of pricing and makes sure that you can stay strategic, consistent, and grounded in value. So the P is for prepare. We started off this video talking about the mindset. So before you even think about numbers, make sure you're grounding everything in value based pricing. Just remember, you're not charging for hours. You're charging for outcomes, and you're building systems that save time, money, and reduce human error. The R is for research. So, this is your discovery phase. You want to fully map out the manual workflow from start to finish. How does it happen? What triggers it? Who does it? How long does it take? What tools are involved? What does the time cost the business so many things that you need to figure out and you have to use this to actually be able to price it properly, which leads directly into the I, which is for identify, identify the ROI. This is where you turn your research into actual numbers. What are the monthly savings, annual savings, the opportunity cost, the efficiency gains, and remember the 10 times investment kind of golden rule. They should roughly see 10 times the return on whatever they pay you within the first year. The C is for communicate. Now that you have that price, you still have to present it in a way that makes sense. You want to paint the picture of what the business will look like once the system is live. Explain what's included. Explain how QA works. Explain what you need from them. If you can't communicate clearly, you'll probably lose them long before you even get to the price conversation. And then the E is for expand. Once the product is complete, your job still is not over. You want to look for opportunities to continue building on top of that relationship. That could be maintenance, optimization, monitoring, additional workflows, V2 upgrades, retainers, or performance bonuses. Your goal isn't just one sale. Your goal is to become their long-term partner. So, this framework gives you a repeatable, reliable way to price any AI workflow, whether it's your first project or your hundth. So, to wrap this up, I wanted to show you guys a practical example of how this framework works in real life because once you see the numbers laid out, pricing becomes a lot less scary and a lot more logical. So, we worked with a client who wanted help with their inbound sales process. They were getting about 20 leads every single week from their form on their website. And every one of those leads took about an hour of an employees time to reach out, qualify them, nurture them, and ultimately have them book in a call with the sales team. These employees who set those meetings were valued at about $40 per hour. So, this meant that this one process was costing the business $800 per week, which is $3,200 per month. And when you zoom out and you annualize it, it ends up being about $38,000 per year. So, let's walk through that example with the price framework. So P prepare. Right away I grounded myself in value based pricing. My job here was not to think about how long the workflow would take me to build. It was to think about how much value it will return to the business. The R is for research. Then came the discovery phase. We mapped out the entire manual process. When leads came in, who handled them, exactly how long it took, what tools they were using, and where the bottlenecks were. That's how we arrived at the $38,400 per year in labor costs opportunity. I identified the ROI. Once we had these numbers, the investment became obvious. I knew automating that process was going to save them about $38,000 in a year alone, not even counting the opportunity cost. So, I priced the product at 15% of those annualized savings, and that came out to $5,500. Because the ROI was so clear, it made complete sense to them, and they could see exactly how the system would pay for itself. See, communicate. Before I ever said the price, I walked them through the solution, how the sales agents would work, what steps it would automate, what testing would look like, what I would need to know from them, and how it would improve both speed to lead and lead quality. I also showed them how we would track success. By the time I anchored the price, they already believed in this outcome and they were bought in. And finally, the E expand. Once we moved into QA and prepared to push the workflow into production, that's when we started to talk about ongoing support. We agreed on a simple maintenance and optimization plan at $550 per month, which is about 10% of the original project's fee. This covered bug fixes, keeping everything aligned with the scope, making adjustments as models updated, and running monthly health reports. Now, this is where we actually did mess up. I should have been proving to the business how valuable the system really is once it was pushed into production and show them how it was actually growing the business. So in hindsight, I should have been tracking things like how fast leads were being contacted, which was basically instant now, how many leads per week were coming in, how much total time was being saved and how the sales team felt using the system. And if we were actually tracking all of these metrics kind of, you know, month after month and we're able to show them that, it would be very clear how the system is explicitly growing the business. And this would have given the client more visibility into the actual impact and a natural entry point for us to make version two improvements and the potential of getting them on a retainer. So, I know that we covered a lot of stuff today and I want to make sure that it all sticks. So, I've thrown all of this into a full resource guide that you can get for free by joining my free school community. The link for that will be down in the description. And if you want to dive a little bit deeper, I've got a full course on all of this kind of stuff. I talk about everything that I've been talking about on YouTube, but in much more depth. So, if that interests you, then definitely check out my plus community. The link for that is also down in the description. Anyways, that's going to do it for today. If you guys enjoyed, you learned something new, please give it a like. It definitely helps me out a ton. And as always, I appreciate you guys making it to the end of the video. I'll see you on the next one. Thanks, everyone.