How to Write an Exit Criterion for a Forward-Deployed Engagement
“Improve customer support” has never survived a contract. It survives the proposal, though, because agreeing to it costs nobody anything on the day they agree.
An exit criterion is the sentence that replaces it. It names the number that has to move, where it starts, the date it gets read, and the person whose reading counts. Write it before anyone builds. Each of those terms is cheap to settle on day one and expensive to settle at the first invoice.
Pick a number someone already measures
Start at the money and walk down. Cost and churn sit at the top, and neither moves in six weeks. So keep going until you reach a number that passes two tests: someone at the customer already measures it, and a small team could move it within a few weeks.
Say you’re working on support at a subscription software company. The number is probably the repeat-contact rate, the share of issues that come back within seven days. It’s already in the support system. It sits right below the quality of the first answer. And it connects upward to both cost and churn. If you can’t name the number, you can’t prove the engagement worked, and you can’t price on outcomes either. Most proposals skip this because the champion is enthusiastic and the words sound fine in a meeting, and nobody feels the cost until someone asks for proof a quarter later.
Write the baseline down
What’s the rate right now? Measured over which period? Does it swing with the billing cycle? A usable baseline has four parts: the number, the window it was measured over, the method, and a named owner on the customer’s side. Leave one out and you’ll spend the end of the engagement arguing about the start of it. Define the terms while you’re there. In this example, a repeat contact is the same customer raising the same issue category within seven days, on any channel. Vendors in this market define the word “resolved” in very different ways, and a customer who hasn’t read the definition finds out at the first invoice. The definition of the outcome is the contract.
Let the people who handle failures help write it
The champion who brought you in will agree to anything. The people who deal with the failures will decide whether it worked, so they help write the number. Here’s a hypothetical that shows the difference. In a support-automation pilot, the champion says “deflect tickets”. The queue lead says the real test is the angry customers. The criterion becomes: resolve 40% of tier-1 tickets by week five, with no drop in satisfaction on a 50-ticket sample the queue lead picks. That sentence has a threshold, a window, a guard against gaming and a judge, and the judge chose the sample.
Thirty minutes with the person who handles the exceptions gets you most of that. Do it before the proposal.
Book the day it gets read
Put the review on the calendar when the engagement starts. Title it plainly: go or no-go.
If the budget holder won’t accept the invite, you’ve learned something before spending six weeks. Make the proof stronger than a before-and-after chart if you can. Roll out to two regions first and agree in advance that the others are the comparison group. When nothing can be held back, name someone on the customer’s side who keeps tracking the benefit after you’ve gone.
Decide now what a partial result means
The awkward outcome is the common one: your number moved and the money didn’t. So write the theory down too. Better first answers reduce repeat contacts within weeks, which reduces contact volume within a month, which lowers cost within a quarter. Every arrow in that chain can be checked. If repeat contacts fall and volume doesn’t, the delivery may have been fine and the theory was wrong, and you’ll know which arrow broke. That’s a different conversation from a failed build, and it’s far easier when both sides read the chain before they started.
- Better first answersYour delivery
- Fewer repeat contactsWithin weeks
- Lower contact volumeWithin a month
- Lower costWithin a quarter
The whole thing fits on a page
Five lines, agreed before the first commit. The outcome: the number, down from its baseline, in the customer’s own system. The definition: what counts, in one sentence. The proof: who gets it first, who’s the comparison, for how long. The owner: the named person whose report both sides agreed to believe. The date: the day it’s read, already on the calendar. How the price attaches to those lines is a separate decision, and it changes what you should agree to.
There’s more in How to Define the Outcome a Forward-Deployed Team Is Paid For. The pilot version is in Charge for the Pilot, and Write Down the Day It Ends.