Write a Recommendation That Allows No Purchase
Present improve-existing, bounded-pilot and decline options in an honest buyer recommendation, with clear evidence, decision conditions and no forced sale.
10/24/20263 min read


A useful sales recommendation should remain useful when the buyer chooses not to buy. If every route through the document leads to your product, it is a proposal with alternatives removed, not an evaluation. Give the buyer a clear account of the problem, the evidence and the conditions under which each option makes sense.
This does not require pretending that all options are equally good. It requires distinguishing your recommendation from the buyer's authority to decide. State a preference when the evidence supports one, explain what would change it and make a no-purchase outcome operationally complete.
Organize around the decision, not the catalogue
Use three routes: improve the existing process, run a bounded pilot, or decline the proposed purchase. Each needs a reason, an owner and a next state. Avoid describing the first route as “do nothing” when it includes real changes. Avoid presenting the pilot as commitment-free if it still consumes time, data access or procurement effort.
Before writing, separate buyer-confirmed requirements from seller hypotheses. A manager's interest in a demonstration is not approval to spend. A recurring inconvenience is not necessarily a priority. If the commercial timing is unknown, retain that uncertainty rather than manufacturing a deadline.
A complete fictional recommendation
The following recommendation concerns an invented AI-assisted research-note handoff service. It is a writing example, not a real customer assessment, offer or commitment.
Decision for the operations owner, 20 November 2026: Your team wants fewer ambiguous handoffs between researchers and account owners. In the fictional discovery record, you confirmed that notes sometimes arrive without a named reviewer or a stated next action. You have not confirmed that the current software prevents either field from being recorded. We therefore do not yet have evidence that purchasing a new service is necessary.
Recommended route: improve the existing process first. Assign a receiving owner and require a short acceptance or clarification response for each handoff. Operations owner Elena would own the procedure if you approve it. Review a small, agreed set of subsequent handoffs against the same criteria. This route uses your current approved tools and creates no new provider relationship. Its limitation is that ownership still requires staff attention; the procedure will not enforce itself.
Alternative route: a bounded pilot if the remaining question warrants it. If consistent ownership still fails after the procedure is understood, evaluate whether the proposed service can make that state visible without adding unacceptable administration. A possible pilot would use synthetic notes, one review queue and no customer communications. Before starting, agree acceptance checks, the responsible reviewers, any cost, access boundaries and the exit procedure. Passing the pilot would support only the evaluated workflow, not a commitment to wider deployment.
Valid route: decline this purchase. Decline if the problem is too infrequent to justify another service, the current process meets your needs after clarification, or the proposed controls do not satisfy your requirements. On that decision, we would close the evaluation under the agreed process and avoid treating the account as an active purchase initiative. Any future contact should follow your stated preference rather than an automatic sequence.
What would change our recommendation: Evidence that the revised existing process still creates material unresolved handoffs, together with a named owner willing to evaluate the alternative. Interest in additional features alone would not settle that question. The status of budget and implementation capacity remains unconfirmed.
Decision requested: Choose whether to improve the existing process, scope the limited evaluation, or close this proposal. You may also postpone a decision if a prerequisite is unresolved. No option in this note authorizes access, payment or a new contractual commitment.
Why this is stronger than a forced comparison
The recommendation identifies a plausible cause, missing ownership, before prescribing a tool. It makes the current-process route concrete and gives decline a clean next state. It also makes clear which conditions would justify revisiting the service without implying that the buyer has agreed to those conditions.
NIST AI RMF 1.0, MANAGE 1.1 includes deciding whether an AI system should proceed in light of its intended purpose and objectives. That is compatible with a genuine stop decision; it does not endorse this fictional recommendation or sales method.
Recognize when a pilot is the wrong middle ground
A pilot should not soften a known disqualifier. If the buyer requires a control that the proposed service cannot provide, another demonstration does not resolve the mismatch. Recommend declining or considering a different approach, unless a legitimate change in requirements comes from the buyer.
Likewise, do not invent return-on-investment figures to make purchase appear inevitable. If the buyer has not supplied reliable workload and cost inputs, leave the financial conclusion open. The document earns trust by making the available choices clearer, including the choice that produces no sale.
Continue with Prepare a Sales Demo Around One Confirmed Workflow or Build a Small Reference Library for Evidence-Based Selling.
