Turning an Agency’s Sales Framework Into a Delivery Model the Team Can Run

Every agency has their own fancy model or delivery framework. Discover, Engage, Produce, Grow, Iterate…whatever the stages are called.

Agency leaders build these as a storytelling tool for selling. It’s easier to talk about the service and what it does when it sounds like it’s organized into a model. But the model doesn’t mean much to the delivery team.

A good story the team couldn’t use

One agency founder I work with came up with his, nested a bunch of work under each stage, and handed it to his team. I liked it. It was strong. It was a better story than the one they’d been telling.

The only problem was the team’s reaction, which was, what is this? We don’t know what to do here.

That reaction makes sense once you look at it from where they sit. A stage name tells a prospect what phase of the relationship they’re in. It doesn’t tell a content specialist what to open on Monday morning, who hands them the input, or what “done” looks like. The work nested under each stage named what the agency does. What the team needed next was who does it, in what order, and what comes out the other end.

When I came in, I told him if he wants to keep the model, we need to give it meaning. Make it tactical and bring it all the way down to where people need it to go.

Why I kept the model

The obvious alternative is to drop the model, write down how the team already works, and let sales keep telling the story however they want. I’d rather not go that way.

The model is what the client heard in the pitch. It’s the reason they believe the engagement has a shape. If delivery runs on something else, the account team ends up translating between what the client was sold and what the team is doing, every week, on every account. Clients notice that gap, even when nobody on the agency side has named it yet.

Keeping the model means the story the client bought and the work the team does are the same thing. That only works if the model goes all the way down.

How we’re giving it meaning

1. Tie a scope of work to each stage. What the client is buying at that point, what they walk away with, and what it costs. If you can’t write a scope for it, it isn’t a stage yet. This step is the one that tells you whether the model is real. If a stage can’t be sold on its own, the work inside it probably belongs to the stage before or after it.

2. Reverse engineer each stage against the output and the client experience. Start from what the client gets at the end of the stage and what it’s like to go through it, then work backward to the work that has to happen. Anything that doesn’t feed the output or contribute to the experience comes out. This is where most of the inherited work gets questioned, including things the team has done for years because somebody asked for it once.

3. Break the stages down into work items, and map how they flow and fit together. Each item has an owner, what it produces, and which item picks it up next. This is the layer the team was missing. Once every item has a next item, you can see the handoffs, and the handoffs are where work stalls.

4. Turn each work item into steps that get assigned at the ground floor of the team. Numbered, with a time estimate, so someone can pick one up without asking what to do. The time estimates do a second job here. Add them up and you finally know what a stage costs to deliver, which is the number you need to price it and to know whether the team has room for more of it.

5. Focus on the end client deliverables and polish, polish, polish. The goal here is maximum value perception. The client never sees your work items. They see what lands in their inbox and what gets presented on the call, so that’s where the extra effort goes.

6. Run it on your next client engagement from start to finish. Document as you go and keep communication high. The first run is for learning, not for getting it right. The team will hit steps that don’t make sense and handoffs that don’t connect, and they need to feel free to say so while it’s happening.

7. Debrief, update, and keep evolving. Change the scope, the items, and the steps based on what you saw, then run it again.

The steps live in the project management system

It would be easy to hear all of this as “write SOPs for every stage.” I’ve written before about why I don’t love that approach at a lean agency. A long process doc gets written once and goes stale while the work keeps moving.

The work items and steps belong in the project management system, as templates the team runs every time a client enters a stage. When a step changes, the template changes, and the next client gets the new version. The documentation comes out of the first run, written by the people who did the work, instead of being drafted up front by someone guessing how it will go.

One stage at a time

We’re not rebuilding every stage at once. It’s tempting, because the model is on one page and it feels like one project. But every stage rebuilt in parallel means a pile of changes landing on the same team before any of them has been run on a real client.

One stage at a time gives the team something that works before the next one starts. They see a stage go from a label to a scope, a set of work items, and a client deliverable they’re proud of. That makes the next stage easier to sell to them.

If your team can’t tell you what happens inside each stage, you’ve got a good sales story and not a delivery model yet. The story is worth keeping. It needs the work underneath it.