The AI automation retainer: what it is, what it isn't, and how to price it

When someone asks me what a retainer is, I tell them it is a monthly fee a client pays to keep me available. Then I ask them what that means in practice. Most people say something like: "It means I get paid every month to help them with their AI stuff."

That is not a retainer. That is hourly billing with automatic invoicing.

The difference matters because the two models produce different incentive structures, different client relationships, and different multiples on your time. The builders I know who are charging $3,000 to $8,000 per month for retainers are not doing eight times more work than the builders charging $75 per hour. They are doing the same work under a different contract structure—one that makes the client's success and the builder's payment the same thing, instead of opposite things.

Here is the distinction, as precisely as I can state it.

Hourly billing buys time. Retainers buy access to judgment.

An hourly contract says: for every hour I spend on your system, you pay me $X. The incentive this creates is subtle but real—every hour spent is an hour billed, which means the builder's revenue and the client's speed are in tension. Slow is profitable. Fast is not.

A retainer says: for $Y per month, you get my attention and my judgment on your system. I decide how many hours to spend based on what will move the needle for you. The incentive changes: if the system runs well, I spend fewer hours on it, which means I have more capacity for other clients, which means I want the system to run well. The builder's incentive and the client's outcome are now aligned.

This is why retainers should cost more than hourly work, not less. You are not paying for fewer hours. You are paying for the alignment of incentives, the access, and the institutional knowledge of someone who already knows your system cold.

The mistake most builders make when structuring their first retainer is thinking about it in terms of deliverables. "For $2,000/month I will ship one new workflow and maintain the existing three." That is not a retainer; that is a service-level agreement. The difference is that a retainer client should feel like they have a person, not a product.

In practice, a real retainer contains four things.

One: ongoing monitoring and maintenance. I watch the system. I fix things when they break before the client knows they broke. This is the thing clients pay for but can never see—the absence of breakage is invisible, which is why you have to communicate what you are doing monthly or the client stops seeing the value.

Two: strategic availability. The client can message with questions, ideas, or concerns and get a response within a business day. Not an answer to every question—a response. Sometimes the answer is "I need to look into this." Sometimes the answer is "that is a bad idea and here is why." The access to that judgment is the product.

Three: a monthly review. Thirty minutes, once a month. What is the system doing, what is it costing, where is it working, where is it not. This meeting is where the value becomes visible. I track the number of leads recovered, the number of appointments booked, the cost per automation—whatever metric the client cares about—and I show them the number every month. Clients who see the number do not cancel. Clients who never see the number cancel in month four because they have forgotten why they are paying.

Four: a defined scope boundary. A retainer is not a license to build unlimited new things. It covers maintenance and iteration on the existing system, plus one small new workflow per month, plus the strategic availability. If the client wants a major new build, that is a separate project fee. The scope boundary is what keeps a $3,000/month retainer from turning into $3,000/month for $10,000 worth of work.

The Replacement Test applies here too. What would it cost to replace the outcomes this retainer produces? If the automation system is handling forty inbound inquiries per week that would otherwise require two hours of front-desk time, and front-desk time costs $22/hour, the system is delivering $88 of value per week, or roughly $380 per month, just from that one automation. The retainer should cost somewhere between fifty and one hundred percent of the total value delivered across all automations, depending on how critical the system is to the client's operations.

In practice: a retainer covering a system that a small business depends on daily should start at $1,500/month. A retainer covering a system that a mid-market company depends on should start at $3,500/month. Anything below those numbers is hourly billing with a monthly invoice. Anything above them is justified by scope, criticality, and institutional knowledge.

The last thing I will say about retainers is about timing. Do not launch a retainer on a new system. Build the system first, prove it works for sixty to ninety days, then offer the retainer as the way to keep it running well. Clients who are in the middle of a build cannot evaluate whether the retainer is worth it. Clients who have a working system they depend on—and that they would not know how to maintain themselves—understand the value immediately.

The retainer pitch is not "pay me every month to keep building." It is: "This thing is now working. Here is how you make sure it keeps working."