Instagram LinkedIn X Youtube
Back to Blog

Why I Start With Delivery When Rebuilding Agency Services Around AI

If you’re rebuilding your agency services around AI right now, start with your delivery, not your packaging.

This almost always happens the other way around. Leaders start at the packaging and the positioning, they figure out where AI can get bolted on so the whole thing can be called AI-enabled on sales calls, and then delivery gets handed the promise and told to figure it out. That’s the trap.

A promise made in a pitch is hard to deliver

Think about what delivery does with that promise. The service has been sold as AI-enabled, so the team has to find somewhere to put AI, whether or not the work needs it. Sometimes it goes in where it helps. Often it goes in wherever it fits, so the pitch stays true.

The cost shows up later, and it shows up on the client side first. The work gets a little flatter, the account team has a harder time explaining what’s in it, and the client starts asking more questions. By the time leadership notices, the pitch and the delivery have drifted apart and nobody can say exactly when it happened.

So I start at the other end. Sit with your delivery team and see how the work gets done, then design out from there. You can work your way up to packaging once you know what the work takes, and tweak as you go. But what you can’t do is reverse engineer a delivery model out of a promise you made in a pitch.

This is embedding, and it’s the step most leaders skip.

Embedding is an empathy exercise first

Think about it from your team’s side. The most frustrating thing in the world is a leader walking in and dictating a change to work they have never once watched happen.

So embedding is an empathy exercise before anything else. Where is your team constrained? Where’s the friction? And where’s the spark, the part where the creativity and the raw strategy come from? Your team isn’t a machine, and if you don’t know where the good part lives, you’ll design straight through it.

That last question is the one people skip. Friction is easy to find, because the team will tell you about it the minute you ask. The spark is harder. It’s the step where somebody makes a judgment the process doesn’t describe, and it’s usually the reason the client is still around.

You can only see where AI belongs from inside the work

Embedding is also the only way to figure out where AI belongs in a process. Everybody talks about AI like it only ever makes things better. IT DOESN’T.

When you’re down there producing the work, you find the spots where AI slows you down, makes the job harder, waters down the output, and rips the humanity right out of it. You can’t see any of that from the top.

This is also why embedding isn’t a hunt for hours to cut. If you go in looking for savings, you’ll find them, and you’ll cut some of the spark along with them. The goal is to put AI where it makes the work better. Any time it saves is a bonus.

What you come out with is a step list

To be fair, it’s slow and time consuming to do. Embedding pulls your brain out of where it normally sits and drags it into the weeds, and it costs you real time and attention.

Sometimes I’ll come in and take on some of the work myself, which I think is the most effective way to learn it. But shadow sessions work too. So does sitting down with a recorded working session and watching how a deliverable gets made.

However you do it, what you come out with is a step list. Take one deliverable, like a blog post, and write down every step from the brief to the published page. Every step has one owner, an hour estimate, and a yes or no on AI.

That list turns into more than a process. The hours tell you what the deliverable costs to make. The owners tell you who is overloaded. The yes or no on AI tells you, step by step, where it helps and where a person has to do the work.

“I built this service. I already know how it works.”

This is the objection I’d expect from a founder, and it’s partly right. You know how the work got done when you were the one doing it.

But the service has changed hands since then. The team has picked up new tools, added steps after a bad month, and built workarounds nobody wrote down. The version in your head and the version your team runs on a Tuesday are different, and the second one is the one your client is paying for.

You also don’t have to embed in everything at once. Pick the one deliverable the most revenue depends on and start there.

Then work your way back up

Once you have the step list, you work your way back up from it. The packaging, the positioning, the buyer experience, all of it sitting on top of something your team can run.

The pitch gets easier too, because every claim in it comes from work you’ve watched happen.