Success Plan

A contract records what is being sold and for how much. It does not record why this customer bought. For a long time that information lived only in the head of the sales rep who closed the deal, and never made it into writing.

Which made the first onboarding call always start the same way. The customer success contact introduces themselves and asks what the team is hoping to get out of the product. From the customer's side, this is the fourth time they have explained something they already covered three times during the sale. They say again that they bought it to cut review time, the contact writes it in a notebook, and six months later that contact moves teams and the notebook goes with them.

The missing baseline was the other half of the problem. With no goal written down, every customer gets measured against the same yardstick — usually something like whether a lot of people log in. But if a customer's goal is halving document review time, healthy for them isn't a high login count, it's review actually getting faster. Customers succeeding in an unusual way get flagged red by that yardstick, and someone spends weeks working a perfectly fine account.

One plan is built from six parts.

1. The outcome the customer wants, written in their vocabulary rather than the product's. Not "roll out co-editing" but "cut contract review from 3.5 days to 2." Written in product language, the customer has no way to judge later whether the goal was met.
2. The success criteria — the conditions under which this counts as having worked. A number and a date together: average review time at or under 2 days, held for two consecutive months, within six months. Without criteria you end up six months later trading the observation that things went reasonably well.
3. The starting value. How many days review takes right now. Leave this blank and 2 days later on tells you nothing, because you can't tell improvement from how it always was. Customers frequently don't know their own number, which makes measuring it the plan's first task.
4. The route. The steps to the goal, each with a date, and each with one named person on your side and one on the customer's. A step with only one of those names is a step nobody does, because each side waits for the other to open it.
5. The people. Who holds the budget, who actually runs the rollout, and who objects to it. There is a field for the objector because that person tends to speak up at renewal.
6. Risks and assumptions. The conditions under which this plan breaks: that budget review happens in September, that the main contact goes on leave in the spring. When one of those actually turns, you use the escalation path — the agreed route for who gets pulled in and when.

Writing happens in two passes. Sales hands over a draft of the goals and people they heard during the deal, and the customer success contact fills it in together with the customer. Filled in alone, it becomes your plan rather than theirs. Pagedeck requires that the customer edit parts 1 and 2 into their own words. When there's a sentence the customer actually wrote, you can build on it six months later; without one, the meeting becomes you asking a customer to approve goals you set for them.

There are four readers. The account contact opens it weekly to see the next step on the route. The customer's budget owner sees it quarterly, and having the person who controls spend look at the goal and the progress in the same document is what pays off most at renewal. Grace reads it first when something goes wrong, because an account dashboard shows a score while this document shows what was promised. The product team reads it when weighing a feature request, since a request tied to a contracted goal is handled differently from one that isn't.

This document is also what tells a health score — several signals combined into one number from 0 to 100 — what it should be measuring. For a customer whose goal is review speed, the review-related signals carry more weight, which cuts down on good accounts being misfiled as red accounts.

The one-page summary of outcomes you put in front of a budget owner at renewal comes out of this file. Parts 1 and 2 on the left, what actually happened on the right.

"The plan says the goal is rolling out co-editing. That's our sentence, not the customer's."

The goal hasn't been written in the customer's own operational terms.

"Part 3 is empty, so we have no basis for claiming anything improved."

Nobody measured the starting value, which makes progress unprovable.

"This request maps to a goal in their success plan, so it doesn't get the standard priority."

The document is being used to weigh product requests.

At Pagedeck, Sofia books an hour with the customer inside two weeks of signing and fills the document in with them. Part 3 takes the longest. Few customers know how many days review currently takes, so the call usually includes counting the dates on their last five contracts.

The file gets revised every quarter. In the meeting with the customer she reads the goal out loud, and if it has changed it gets rewritten on the spot. A reorg on the customer's side can easily make permission management more urgent than review speed.

The most common assumption is that this is written once at signing and then filed. The word plan suggests something you set up at the start. But customer goals change inside a year, and a document that hasn't absorbed the change makes you measure health against the wrong standard. Six months in, the goal on the page and what the customer actually wants have drifted apart, and pulling that page out at a renewal meeting means reading them back a goal that is no longer theirs.

Treating it as an internal document is the other frequent mistake. Handled that way there's never a reason to show it to anyone, which is convenient. But a plan the customer has never read is only your expectation. The steps assigned to their side — migrating existing material, changing an internal rule — never start if nobody there has seen the file. Ask six months later why there's no progress and each side says it was the other's job. Sending the file once at signing does not fix this; the customer has to have been in the room while it was written.