The instinct is always to build the automation first. That's the wrong order — especially when LTV is on the line.
Every time I see a team struggling with an agentic workflow, the problem is the same: they built the pipeline before they had the playbook. They automated a process they didn't fully understand. Now they have a fast, efficient system producing mediocre outcomes at scale.
The right sequence is the opposite. You start with the human. What would a great rep do in this situation if they had everything they needed? What would they say? When would they say it? What information would change how they open the conversation? You work all of that out first — in plain language, with real examples, tested against the edge cases — and then you build the automation that makes it possible at scale.
This sounds obvious. Almost nobody does it.
The Mistake Everyone Makes
The pressure to automate is real. There's a workflow that's currently manual and inconsistent. Reps are doing it differently, timing it differently, saying different things. You want to standardize it and scale it. So you pick a tool, wire up a trigger, and ship it.
What you've actually done is locked in all the inconsistency. The automation doesn't know which version of the process was right. It just runs whatever you told it to run, every time, reliably. And if what you told it to run was underspecified — if you skipped the hard conversation about what good actually looks like — you now have a system that's very good at being mediocre.
Automating a broken motion just makes it fail faster. And now it fails consistently, at scale, with no human judgment to catch it. The LTV impact of that is real and compounding.
What the Playbook Forces You to Figure Out
When you write the playbook before you build the system, you're forced to answer questions that automation lets you skip. Who owns this moment — and do they have the skills to handle it? What does the customer know going into this conversation, and how does that change the opening? What's the single thing that has to happen for this interaction to succeed? Where does it break down in practice?
Those questions are uncomfortable because they often surface problems you'd rather not deal with. Maybe the person who's supposed to make the call isn't equipped to run the expansion conversation. Maybe there's a role boundary issue nobody has named. Maybe the process has a single point of failure that no one has fixed because the manual workaround was covering for it.
Writing the playbook forces it all into the open. That's exactly the point.
I went through this building an expansion motion around a specific milestone trigger — six positive conversations as the signal to have the upsell conversation. Before touching any automation, I mapped the conversation: what the rep says, what the AE says, how the handoff works, what happens if no one responds. I had to figure out that the customer often doesn't know certain things have been running — and that changes the entire opening. I had to define the role boundary between rep and AE explicitly, because ambiguity means the rep tries to close something they shouldn't and the AE never gets involved. Both failures are LTV losses with different causes.
None of that comes out of a workflow diagram. It comes out of writing the playbook and asking hard questions about every step.
The Single Point of Failure Test
Once you have the playbook, there's one more thing to do before you touch any tooling: find the single point of failure. Every process has one. The step where, if a human doesn't act, everything downstream stops. The handoff that depends on someone remembering to do something. The notification that only matters if someone sees it and responds.
In the motion I built, it was the rep confirming the expansion call was done. The whole AE notification — same-day outreach, speed to lead, the close — depended on that one action. If the rep had to go find a checkbox in a different tab, they'd skip it. Not out of negligence. Out of being busy and human. And every skip is an expansion event that doesn't happen — a permanent reduction in LTV for that account.
Once you've named the single point of failure, you design the automation specifically to protect it. The confirmation happens in the same thread the rep is already working in. No context switch. The system pings them, they reply, the AE gets notified. If they don't reply: reminder four hours later. Still nothing: another four hours and their manager sees it. The whole escalation path is baked in because every link in the chain matters when you're engineering for LTV.
You can't design for that until you've done the playbook work to know what the critical action is.
Version One Is Not the Finished Product
The other thing the playbook-first approach gets you is a clear sense of what version one actually is. Not a fully automated system with every edge case handled. A functional motion with the most important parts automated and the rest running on human judgment while you learn.
The details will change. The conversations will surface things the playbook didn't anticipate. The role boundaries will need adjusting. Build to evolve, not to lock anything in permanently.
What doesn't change is the underlying logic — who owns what, what the customer needs to hear, what good looks like. That's the playbook. Get that right first and the automation becomes straightforward. Get it wrong and no amount of sophisticated tooling fixes it. It just fails at scale.
The teams building the best LTV-engineering systems aren't the ones with the most sophisticated tech stacks. They're the ones who did the hard thinking about the human process first and then built the system to support it. That order matters more than any tool you choose.
Write the playbook. Find the failure point. Then build.
Lincoln Murphy formally named and popularized Customer Success starting in 2010 and has spent 15 years connecting it to expansion revenue and commercial outcomes. Read The Premise.