How to Define the Success Condition Before Tailoring the Plan

Do not tailor the plan before the win condition is visible.

That is the whole move. A buyer asks for a workflow, proposal, recommendation, or rollout path. The tempting answer is to customize fast. But if you do not know what result would make the plan count as successful, customization becomes guessing with better formatting.

Use a success-condition check when the person has real intent but the outcome is still too vague to design around. The move is not a discovery marathon. It is one short pause that asks: what would prove this worked, what evidence would count, and what boundary would make the plan not worth tailoring?

Do not confuse this with broad criteria gathering. Decision criteria compare options. A success condition defines the result that makes tailoring worth doing at all.

Quick Takeaways

• A success condition is the observable proof that a plan created the outcome the buyer actually needed.
• Ask for it before tailoring, not after you have already written the custom path.
• The fastest useful version names the desired result, the evidence of progress, and the failure boundary.
• Good success conditions use concrete nouns: fewer stalled handoffs, faster owner confirmation, cleaner renewal decision, lower rework.
• Do not ask for a success condition when the person still cannot state the basic problem.
• If the answer reveals a no-fit condition, stop tailoring and run the fit boundary instead.

Direct Answers

What is a success condition?

A success condition is the specific outcome that would prove the plan was worth doing. It turns "make this better" into a testable result such as "reduce stalled approvals after the first customer call" or "make managers confident enough to assign ownership without another meeting."

It is not the full KPI system. It is the smallest practical proof that the plan is aimed at the right job. In a sales or advisory conversation, the success condition gives tailoring a target instead of letting the seller infer the buyer's win from generic role, industry, or urgency signals.

When should I ask for the success condition?

Ask when the person wants a tailored plan but has not named what the plan must make true. The trigger is a request that sounds actionable while the proof of value is still missing.

Use it after basic intent is clear and before option design begins. If the first-turn problem is still unclear, use First-Turn Intent Clarification Protocol first. If the person has already named the success condition and you are comparing paths, move into criteria, tradeoffs, or authority checks instead.

How do I ask without slowing the conversation?

Ask in one sentence and make the answer easy.

Before I tailor this, what would make the plan a clear win: faster decision, less rework, safer handoff, higher adoption, or something else?

That question is fast because it gives examples without boxing the person in. If the answer stays abstract, ask for the evidence:

What would we see in the first two weeks that tells us this is working?

When should I avoid this move?

Avoid it when the conversation is still too early, too pressured, or too constrained for the other person to answer honestly. If the person cannot state the problem, success-condition language will sound like paperwork. If the person is being pressured toward a yes, it can become a compliance question.

Also avoid it when the objection already points to a fit break. If the person says success would require a workflow, budget, owner, or authority they do not have, stop tailoring and use No-Fit Check Before Persuasion.

The Success-Condition Check

Use this template before tailoring a plan:

Before I tailor this, I want to make sure we are aiming at the right result. What would make this a clear win: [result option A], [result option B], or [result option C]? What evidence would show progress, and what boundary would make the plan not worth doing?

The three fields are:

• Result: the outcome the buyer wants to make true.
• Evidence: the observable signal that the outcome is happening.
• Boundary: the condition where the plan should stop, shrink, or change.

Keep the result plain. "Improve communication" is too broad. "Reduce owner confusion after handoff" can guide a plan. "Increase adoption" is still incomplete. "Get managers to use the reply handoff summary before the weekly customer update" is plan-ready.

The evidence field prevents fake alignment. A buyer can say they want a cleaner process, but one person may mean fewer meetings while another means fewer escalations. Ask what they would see if the process improved.

The boundary field protects both sides. Tailoring is not always the right next move. If the buyer needs an integration that does not exist, an approver who is absent, or a workflow change outside the current mandate, the honest move may be a narrower plan or no plan yet.

Choose This Move Instead Of Adjacent Protocols

Use the success-condition check when the issue is outcome proof.

Use First-Turn Intent Clarification Protocol when the person has not made the basic request clear. Intent clarification asks, "What are we solving?" Success-condition checking asks, "What would prove the plan solved it?"

Use Decision-Criteria Elicitation Before Solutioning when several options are already on the table and the group needs shared filters. Criteria help compare paths. The success condition decides whether tailoring should begin.

Use No-Fit Check Before Persuasion when the answer exposes a disqualifying boundary. If the success condition depends on something the plan cannot deliver, persuasion is the wrong lane.

This boundary matters because sales qualification often fails by doing the right protocol at the wrong layer. Too much criteria work before the buyer has named the win feels heavy. Too much tailoring before the win is named creates polished mismatch.

The Protocol

1. Reflect the live request

Start with what the person already asked for.

You are asking for a rollout plan for the support team.

Do not add your interpretation yet. The first sentence proves you heard the request without pretending you know the target.

2. Ask for the win in operational language

Offer two or three possible success types.

Should this make triage faster, reduce escalations, improve handoff quality, or prove whether the workflow fits?

This is better than "What are your goals?" because it gives the other person a small menu and invites correction.

Shared decision-making research supports this kind of explicit preference work. The revised three-talk model added the need to elicit patient goals as part of guiding decisions, and frames decision talk around informed preferences rather than expert-only recommendation [1]. Grais transfers that mechanism cautiously: in business conversations, the plan should not outrun the person's stated outcome.

3. Convert the win into evidence

Ask what would be visible if the plan worked.

Examples:

• "What would be different in the next customer thread?"
• "What would the manager stop having to chase?"
• "What would your team trust enough to repeat?"
• "What would make the buyer say this saved time rather than added work?"

Goal-setting and action-planning literature is useful here because it separates general desire from concrete behavior and follow-through. Bailey describes goal setting as helping people identify specific behaviors to change and how to act on them [2]. Grais infers the business version: a tailored plan needs a visible behavior or state change, not only a positive feeling.

4. Name the boundary before tailoring

Ask what would make the plan wrong.

What condition would make this not worth tailoring right now?

The answer may reveal missing authority, no budget, no owner, no data access, or a workflow dependency. If the boundary is real, shrink the plan before you customize.

The AHRQ SHARE approach asks clinicians to explore options, assess values and preferences, reach a decision, and plan to revisit implementation [3]. The direct business transfer is not medical advice. It is the sequence: compare options only after the person has named what matters and how the decision will be revisited.

5. Tailor only to the named condition

Once the result, evidence, and boundary are visible, tailor the plan in one of three ways:

1. Outcome fit: choose the plan that best serves the stated result.
2. Evidence fit: design the first checkpoint around the visible proof.
3. Boundary fit: remove, narrow, or delay work that violates the stop condition.

If you cannot connect a plan detail to one of those three fields, it is decoration. Cut it.

6. Close with a success-condition restatement

End by making the target portable:

I will tailor the plan around this condition: success means [result], first evidence is [signal], and we stop or change course if [boundary].

That restatement matters in AI-assisted work. NIST's AI Risk Management Framework emphasizes managing AI risk across design, development, use, and evaluation, not only at the moment of output [4]. Grais infers a practical rule for generated plans: the success condition must survive the summary, prompt, handoff, and review.

Worked Example

A buyer says:

We want Grais to help our customer success team reply better.

Weak version:

Great. We can tailor a workflow for support, renewals, and escalation handling.

This sounds helpful, but it hides the target. "Reply better" could mean faster replies, fewer escalations, better tone, cleaner owner handoff, higher renewal readiness, or lower manager review time.

Stronger version:

Before I tailor that, what would make the plan a clear win: faster first replies, fewer manager escalations, cleaner account handoffs, or stronger renewal conversations?

The buyer answers:

Fewer manager escalations. The team can respond, but managers keep getting pulled in because ownership and next step are unclear.

Now ask for evidence:

What would we see in the first two weeks if that improved?

The buyer says:

Reps would send the next step with the owner named, and managers would only enter when a policy exception is needed.

Now ask for the boundary:

What would make this not worth tailoring right now?

The buyer says:

If reps cannot see the account context, they will still ask managers to interpret it.

The tailored plan is now obvious. It should not be a generic support-writing workflow. It should focus on owner naming, next-step language, policy-exception routing, and the minimum context reps need before sending. If context access is missing, the first phase is not rollout. It is a constrained pilot or setup task.

Common Failure Modes

• Decorative tailoring: adding role, industry, or channel details that do not connect to the success condition.
• Abstract wins: accepting "better quality" or "more alignment" without evidence.
• Hidden no-fit: treating a stop condition as a minor preference.
• Over-discovery: asking ten questions when one result, one evidence signal, and one boundary would be enough.
• False speed: writing a custom plan quickly, then losing a week to rework because the target was wrong.

The stop condition is simple: if the person cannot name a result or evidence signal after one clean prompt and one example, do not keep tailoring. Return to intent clarification, ask for missing context, or park the plan until the owner can answer.

Why This Works

The success-condition check works because it changes the conversation from customization to fit.

Shared decision-making models repeatedly point to the same structure: choices improve when options, tradeoffs, preferences, and decisions are made explicit before commitment [5]. Success-condition language gives that structure a lightweight business form.

Implementation-intention research adds a second mechanism. Goal intentions alone do not reliably become action; if-then plans help connect situations, responses, and desired outcomes [6]. Grais does not claim that a sales success-condition check reproduces those intervention effects. The bounded inference is narrower: a tailored plan is more usable when it names the situation, target response, and outcome before work begins.

The CDC Clear Communication Index is also relevant because it treats understanding as a design problem. The Index is research-based and uses scored items drawn from communication literature to help people develop and assess public materials [7]. The transfer here is about clarity: if the plan's main win is not visible, the audience has to infer what matters.

The practical result is a better default: tailor only after the buyer names what success would prove.

Evidence Map

• Elwyn et al. 2017 supports eliciting goals before option comparison; Grais uses this to justify asking for the win condition before tailoring.
• Bailey 2017 supports moving from broad goal language to specific behavior and action planning; Grais uses this to make success conditions observable.
• AHRQ SHARE supports comparing options, assessing preferences, reaching a decision, and revisiting implementation; Grais uses this as a sequencing model.
• NIST AI RMF supports carrying risk and evaluation considerations through AI system use; Grais uses this to require the success condition to survive generated plans and handoffs.
• Elwyn et al. 2012 supports shared decision making as preference-aware deliberation; Grais uses this as the decision-quality mechanism.
• NCI implementation-intention guidance supports linking situations, responses, and goals; Grais uses this as bounded support for success-condition-to-action mapping.
• CDC Clear Communication Index supports main-message clarity and audience understanding; Grais uses this to keep the win condition plain.

References

1. A three-talk model for shared decision making: multistage consultation process
2. Goal Setting and Action Planning for Health Behavior Change
3. The SHARE Approach Essential Steps of Shared Decision Making
4. AI Risk Management Framework
5. Shared Decision Making: A Model for Clinical Practice
6. Implementation Intentions
7. CDC Clear Communication Index