Chapter 14

Create the Purchase Moment

Activity Without Decision

Suppose your app has been live for three months. A little more than a hundred people have created accounts. Twenty or thirty have used it more than once. A handful have sent useful feedback, several have asked for features, and you have held demos, fixed onboarding problems, written to the list, extended trials, and had a few conversations with people who seemed genuinely interested. Nobody has paid.

That sounds like a conversion problem, and it might be. But before I diagnose conversion, I want to know whether there was actually a moment when anyone had to convert. A founder can build an entire commercial process around a product without ever creating a commercial decision. The landing page offers a free trial with no meaningful ending. Users receive helpful emails and are invited to reply with feedback. The founder schedules calls to learn how people use the product. Some users stay active, others disappear, and occasionally someone says the application is useful enough that they could imagine paying for it. The process contains plenty of behavior. What it may not contain is a decision: a point where continuing requires the buyer to choose between keeping the product and keeping something else they value. Money has not entered the equation, and neither has a signed pilot, an approval request, or a dated commitment.

The funnel can look active while remaining commercially inconclusive, and this is dangerous precisely because the activity is real. A person who spends forty minutes in your software has done something. A team that connects real data to an evaluation has demonstrated more than a visitor who glanced at the homepage. We established earlier that those behaviors sit at different levels of commercial evidence. The problem here is different: you can keep collecting increasingly interesting behavior while allowing the central question to remain optional. Will somebody make the commitment the business requires?

Consider a founder running a free beta that grows from twenty users to fifty to one hundred. The founder talks to them constantly, people report bugs and request features, and the product keeps improving. Three months later there are 140 beta users and no customers. That number can be read several ways: the product is not valuable enough, the wrong people joined, the eventual price will be too high, trust is weak. But there is a more basic possibility. Nobody has been asked yet. If the beta never contained a transition into a concrete paid proposition, then zero purchases did not result from 140 people declining to purchase. The founder had 140 opportunities to learn about product behavior and potentially zero completed tests of willingness to pay. Those are not the same result.

The same pattern appears in higher-touch sales. A founder demonstrates a workflow application to a company, answers technical questions, demonstrates again for more stakeholders, sends documentation, and leaves every meeting with some version of “This looks interesting. Keep us posted.” The CRM accumulates twelve notes and the calendar six meetings, the product acquires three features because of those meetings, and the buyer has still never been asked to take a concrete commercial step.

Builders can borrow a habit here. If a transaction is supposed to write to a database, I eventually want to know whether the write occurred. I can instrument everything around it, measure request volume, latency, retries, and button clicks, and those observations help me diagnose the system. But I cannot replace the commit with an impressive collection of telemetry surrounding it. Revenue has the same inconvenient property. There are many useful events on the path toward payment, none of which should be discarded, but their presence does not mean the path reaches a purchase decision. Sometimes it does not.

So when I look at an app with plenty of activity and little revenue, before changing the headline, lowering the price, adding a feature, or declaring the market not ready, I want someone to show me where the buyer has to choose. Not where the pricing page exists. Not where the founder mentions that paid plans are coming. Where does a qualified prospect encounter a concrete proposition and have to decide whether to proceed? If we cannot point to that place, a great deal of the commercial evidence remains unresolved. We know people will visit, sign up, use the product, and remain interested. We do not know what they do when continuing costs them something meaningful.

That does not mean every free trial should end tomorrow or every friendly conversation should conclude with a demand for a credit card. Free access can be strategically useful, evaluations take time, and enterprise purchases move through legitimate steps before money changes hands. The mistake is not allowing activity before the purchase. It is allowing activity to substitute indefinitely for the purchase decision, which produces a peculiar limbo: the founder is busy enough to feel the business moving, the prospect is interested enough to stay nearby, and the product is improving enough that postponement continues to feel reasonable. Nobody has rejected anything. Nobody has accepted anything either. A long enough maybe can begin to look suspiciously like traction.

So before diagnosing why your app is not converting, trace the commercial path all the way through and find the exact screen, sentence, proposal, checkout, pilot request, or approval step where the prospect can no longer remain merely interested. If you cannot find it, you may not have a conversion problem yet. You may have built a funnel with no purchase moment. The next question is what should count as one.

What Counts as a Purchase Moment

A purchase moment is not necessarily the instant a card is charged. That would be a convenient definition, because Stripe gives the event a timestamp and occasionally a pleasant little notification. But many buying processes become commercially real before money moves, particularly when the product is expensive, implementation is involved, or an organization has more people between desire and payment than seems strictly necessary. The better definition is this: a purchase moment occurs when a plausible buyer must accept or decline a meaningful commitment that moves the purchase from discussion into action.

For a consumer app, that moment may be wonderfully literal. The user reaches the limit of the free tier, sees that continued access costs $12.99, and chooses. For self-serve SaaS, it may arrive at the end of a fourteen-day trial, when continued use requires choosing a plan and entering payment details. This is different from merely having a pricing page. A user can visit one, develop strong opinions about the middle tier, and leave without committing to anything. The existence of a price is not the same as creating a decision around it.

For a higher-priced B2B product, the moment may be a proposal. You have demonstrated a workflow application to an operations team, they agree it addresses a real problem, and the next step is a thirty-day paid pilot for $5,000 beginning October 1. The purchase moment arrives when somebody who can move the decision is asked to approve that pilot. They may say yes, or no, or that it needs budget approval, in which case another meaningful decision has become visible. What matters is that the proposition can no longer survive entirely as a pleasant possibility. Enterprise purchases contain several such commitments: a department leader sponsors the evaluation, a technical owner approves a controlled pilot, someone authorizes security review or procurement, budget is reserved, legal reviews terms. Not every administrative action qualifies. Uploading a security document because someone casually asked does not mean much. The action matters when the buyer gives something up to continue: time, budget, political capital, a place on the implementation calendar, the attention of another team, or a commitment to begin under defined conditions.

That is why “send me a proposal” is deceptively ambiguous. Sometimes it means “I am seriously considering this and need the document that lets me move it forward.” Sometimes it means “sending you away to write a document seems easier than ending this conversation.” The words are identical; the surrounding behavior tells you which. You do not need to become suspicious of everyone who asks for a proposal. You need to know what happens after it exists. Who reviews it, what decision follows, is there a price and a scope and a date, and is somebody responsible for saying yes or no? The same test applies to pilots. “We should pilot this” can stay theoretical for months. A pilot becomes commercially interesting when someone defines what will be tested, who participates, when it begins, what happens if it succeeds, and what commitment the buyer will make.

Suppose a consultant tells you during a demo that $199 a month seems completely reasonable. Useful. Then you ask whether she would like to begin the paid plan today. Before the question, she was evaluating the reasonableness of a price in the abstract. After it, $199 is competing with keeping $199, along with the setup, attention, and uncertainty that accompany the purchase. Her answer now carries different information. Payment is not the only commitment worth observing; Chapter 8 established why a dated pilot or conditional commitment tells you something before money moves. The point here is to make sure the commercial path contains a place where the next rung can happen.

I find it useful to trace a product from first contact forward and ask a very literal question: Where does the buyer have to choose? A mobile app answers with an upgrade screen. A SaaS product answers with the end of a trial. A consultant selling software-supported work answers with a proposal that requires a deposit. An enterprise AI product answers with approval for a defined paid pilot, then procurement, then a larger deployment decision. There is no universally correct mechanism, because the commitment should fit the purchase. A $9 utility does not need a six-stage buying process, and a system that touches sensitive financial data should probably not invite a Fortune 500 company to “Start instantly” with a corporate card and a confetti animation. Commercial seriousness is not measured by how many steps you add. It is measured by whether the steps make the buying decision more real, which also rules out manufactured commitments: requiring a credit card for a free trial adds friction, but friction is not willingness to pay, and a meaningless letter of intent does not create demand.

So take your current commercial path and identify the exact event where a qualified buyer must choose whether to allocate something meaningful in order to proceed. If there is no such event, you have found a problem. If there is one, write it down, and then ask a considerably more uncomfortable question. Are you actually putting qualified buyers in front of it? Because once purchase moments become this concrete, another pattern becomes hard to ignore. Founders have a remarkable number of ways to avoid creating them.

Design the Conversion Event

A purchase moment can exist in theory and fail in practice because the buyer cannot tell what they are being asked to do. The founder has a pricing page, a button, a trial that ends eventually, a proposal that was sent. Somewhere in the machinery a decision is supposedly waiting. But the buyer is not sure what they get, what it costs, when payment begins, or whether the founder is actually asking them to proceed. That is a conversion event with too much interpretation left to the customer.

For a self-serve product, the event should answer a few questions without detective work. What will I receive? What will I pay? What changes if I say yes? What happens if I do nothing? Suppose someone has used your application for fourteen days and completed several real tasks. On the final day they receive: Your trial ends today. Continue with the Professional plan for $79 per month to keep your projects, integrations, and automated reports active. Then a clear button. That is a commercial event. Compare: Hope you’re enjoying the product. We’d love your feedback. If you’d like to learn more about our plans, check out the pricing page. The second is friendly and may produce feedback. It also asks the buyer to construct the purchase process themselves: decide whether they want to buy, find the page, work out which plan applies, infer what happens when the trial ends. Every ambiguity is another chance to postpone without explicitly rejecting anything.

In higher-value sales, the event may not be a button. After a successful evaluation with a small business team, a weak ending is Let me know what makes sense for next steps, which is commercially polite and operationally useless. A stronger one is Based on the evaluation, the next step would be the six-month team plan we discussed at $6,000, including onboarding for the five pilot users and continued access to the workflow you tested. If you want to proceed, I’ll send the agreement today and we can schedule onboarding for next week. That does not force a yes. It makes yes and no possible. The same applies to pilots: define which users participate, what will be tested, what it costs, when it begins, and what happens when it ends. “Would you be interested in doing a pilot?” sounds specific until both parties discover one imagined a paid evaluation next month and the other imagined free access until somebody remembered to revisit the subject. Commercial ambiguity has an impressive ability to survive meetings.

The value should remain visible at the decision point. Founders explain the product carefully during acquisition and evaluation, then reduce the purchase request to Upgrade to Pro: $99/month. That may be enough when the value is obvious. Often the event should reconnect the price to what the buyer is continuing to receive: keep generating the reports the team has started using, keep the automation connected, preserve the workflow that justified the evaluation. That does not require marketing copy at checkout, only enough context that the buyer knows the tradeoff. Clarity about price matters for the same reason. If the product costs $149 a month, say $149. If there is a $2,500 implementation fee, put it in the proposal. If the pilot costs $5,000 and converts to a $20,000 annual agreement only if both sides proceed, say that. Where pricing depends on scope or usage, the answer is not false simplicity but a clear current commitment: the buyer may not know the final annual cost, but they can know that the next step is a $3,000 paid discovery engagement, or see the usage rate and an estimate for the workload they described.

There is another reason to care. A vague conversion event gives you vague evidence. Suppose ten qualified users finish a trial and none become customers. If the trial simply expired, the pricing page was hard to find, existing work stayed accessible, and nobody was asked to continue on a paid plan, what did the ten reject? Possibly nothing. The system observed expiration. It did not observe refusal. I prefer conversion events that leave a clean record: the buyer encountered the proposition, the price was visible, the next action was understandable, and proceeding required a meaningful commitment. Behavior then becomes easier to interpret, not perfectly easy, but at least the answer belongs to something real. So before changing your price, rebuilding onboarding, or buying traffic, inspect the moment where evaluation becomes purchase. Could a reasonable buyer explain what they are being asked to buy, what it costs, what happens if they say yes, and what happens if they say no? If those answers are fuzzy, fix the event before interpreting the conversion rate.

Ask for the Next Commitment

There is an easy way to misuse this chapter. If stronger commitments produce better evidence, perhaps the answer is to ask everyone to buy immediately. Sometimes that is exactly right: if someone lands on a $15 utility and wants the result, put the price in front of them. If you are selling a system that will connect to a company’s production data and cost tens of thousands of dollars, asking a stranger to sign an annual agreement ten minutes into the first conversation produces a very clean no and very little information. The objective is not the largest commitment you can imagine. It is the next commitment the buyer can reasonably make.

The Commitment Evidence Ladder is the design tool here. Someone tells you they have exactly the problem your application addresses. Do not skip to revenue; the next useful question is whether they will evaluate seriously. Will they schedule the demonstration, bring the data needed to test it, and involve the colleague who owns the workflow? If they will not invest enough effort to evaluate something they call painful, that is worth knowing. Suppose they complete the evaluation and say the product works. Another compliment is not the next commitment. Price is. “The plan for a team your size is $500 a month. If the remaining technical questions are resolved, is that within the range you would proceed at?” They have now encountered the number. If $500 is impossible, you have reached a different problem. If the amount is reasonable but they need one integration first, the next commitment involves that condition, and specificity matters. “If we build the integration, would you still be interested?” is weak. “If that integration passes your test by October 15, will you begin the thirty-day pilot at the price we discussed?” asks the buyer to connect the requested condition to an observable next action. You are not trapping them. You are discovering whether the integration actually stands between the present situation and a decision, which matters for builders especially, because a feature request gives us something delightfully concrete to work on and can feel solved the moment we start building it.

The same logic applies inside the buyer’s organization. A department may not be able to purchase during the conversation, but the options are not only “buy now” and “keep me posted.” The next step may be the sponsor scheduling a technical evaluation, approval for a paid pilot, an introduction to the budget owner, or submission to procurement. The action should correspond to whatever has to become true next for the purchase to continue. So instead of “How do I close this customer?” ask: What is the next meaningful commitment this buyer would make if the current commercial hypothesis were true? If the person does not yet understand the product, asking for a credit card is premature. If they have evaluated it, accepted the price, and spent three weeks discussing implementation, offering another free demo moves in the wrong direction. Early founders make both mistakes, asking for too much too soon or continuing to ask for tiny commitments long after the buyer could make a larger one. The oversized ask produces a rejection caused by the jump itself. The undersized ask lets the buyer continue indefinitely without exposing the next constraint.

Do not keep asking the buyer to repeat a decision they have already made. If they have agreed the problem matters, stop asking whether it matters. If they have evaluated successfully, stop treating another evaluation as progress. If they have accepted the price, move toward the implementation, approval, or purchase decision that remains. This is also the discipline for follow-up. Instead of another version of “just checking in,” return to the action that was supposed to happen next: schedule the evaluation the operations lead was going to join, ask for the security requirements, ask whether the budget approval occurred. A follow-up with a defined commitment has a purpose. A follow-up whose only objective is to remind someone that you continue to exist performs a more modest service.

There will still be stalled decisions; buyers change priorities, budgets disappear, sponsors leave. The point is not to eliminate uncertainty but to stop voluntarily creating more of it. At each stage, identify what the buyer has committed to, then ask what behavior would move the question one step closer to payment. Not five steps. Not the easiest step. The next one. And if the buyer needs time to make that decision, give them time. A real purchase moment does not become more legitimate because you add a countdown clock to it.

Do Not Manufacture Urgency

A purchase moment is not a pressure moment. You do not need a countdown timer, a disappearing bonus, or a mysteriously limited supply of software licenses to make a buyer decide. You need a real proposition and a point at which the buyer must choose.

Founders are told that people procrastinate and that an offer without urgency drifts indefinitely, and there is truth in that. If nothing changes when the buyer waits, waiting may be perfectly rational. But that does not license inventing consequences that do not exist. If your product can accept another customer next Tuesday, “only three spots left” is not strategy. It is fiction. If a discount ends Friday because Friday sounds commercially exciting, the deadline tells you less about demand than a real price would. If a banner resets to fourteen minutes every time the browser refreshes, the buyer may learn something about the product, and it is probably not what you intended.

Real urgency comes from reality. Sometimes the buyer has a deadline: a contract renews next month, a reporting requirement begins in January, budget expires at the end of a fiscal period, a manual process costs enough that every additional month has a consequence. Sometimes the seller has a legitimate constraint: you can onboard only two pilot customers because each requires significant implementation work you are handling personally. State it plainly. “We can begin two additional pilots in October because I am still handling implementation myself” communicates a real limitation. “Only TWO EXCLUSIVE FOUNDING MEMBER SPOTS REMAINING!!!” communicates something else.

The difference is not stylistic. Manufactured urgency contaminates the experiment. If a buyer purchases because they believe the price doubles at midnight, what did you learn? Perhaps the offer was worth the price. Perhaps they were responding to fear of losing the discount. Perhaps they would have bought next week anyway, or will regret it tomorrow. The more pressure around the event, the harder it becomes to separate willingness to buy the product from willingness to avoid the threatened consequence. That does not make every deadline manipulative; introductory prices end, cohorts start on real dates, service businesses have capacity limits. The standard is simple: would the constraint still exist if nobody saw the marketing copy? If yes, you have something real to communicate. If no, be careful about treating the resulting behavior as evidence.

There is a less visible form of manufactured urgency: the founder trying to force a purchase because the business needs the answer. The month has been slow, the prospect has been evaluating for weeks, you need this deal. All of that creates urgency for you. It does not create urgency for the buyer, and your desire to close does not increase the economic importance of the customer’s problem. You can make the decision clear, ask directly, set reasonable dates, and explain the real consequences of delay. You cannot negotiate reality into being urgent. So make the commercial path firmer rather than louder. If the trial ends Friday, say what happens Friday. If the buyer has everything needed to decide, ask for the decision. Then leave room for a legitimate no, because the entire method in this book depends on interpreting buyer behavior, and if you manipulate the conditions around that behavior too aggressively, you make your own evidence harder to trust.

The purpose of the purchase moment is not to win every purchase. It is to bring the proposition into contact with a real decision. Create that moment deliberately. Make the offer understandable, put the real price or commitment in front of the buyer, ask for the next appropriate action, and let yes and no both mean something. Then pay attention to what happens, because something useful can occur even when the buyer seems to agree with almost everything. They may have the problem, value the product, accept the price, and understand the process, and still refuse. Not because the economics failed. Because buying from you feels too risky. That is a different commercial problem, and it deserves its own diagnosis.