Define a Paid Outcome

A buyer does not usually pay for your research, analysis, drafting, or use of AI. The buyer pays for a change that matters: a decision made, a deadline met, a backlog reduced, a risk exposed, or a responsibility removed. An outcome is easier to buy when both people can tell whether it was delivered.

This chapter turns the segment from the previous chapter into one paid outcome. The result must be narrow enough to finish, concrete enough to inspect, and valuable enough to justify a purchase now. It also needs a boundary. Without one, a promising first conversation can become an unlimited project.

Use this chapter before writing an offer. The offer can become convincing only after the underlying result is clear.

Start With the Buyer's Situation

An outcome begins with a person in a specific situation. Write down:

• Who experiences the problem.
• What event makes the problem urgent now.
• What they currently do instead.
• What the imperfect workaround costs in time, money, risk, or missed opportunity.
• Who approves a small purchase.
• What result would let that person say the work is finished.

Keep observed evidence separate from your interpretation. "The operations lead said invoices are reconciled manually every Friday and the last month-end close ran four days late" is evidence. "They desperately need automation" is an interpretation. The second may be true, but it needs confirmation.

The buyer should be narrow enough that the result matters in the same way each time. If one buyer wants a report, another wants training, and a third wants software, those are different outcomes. Put the adjacent requests on a watch list until evidence shows which one recurs.

Describe a Finished State

An activity describes what you will do. A finished state describes what will be true when the work is accepted.

Weak descriptions:

• Review the customer's process.
• Help with follow-up emails.
• Create an AI workflow.
• Improve reporting.

Stronger descriptions:

• Deliver a reviewed exception list that identifies every unmatched invoice in a named four-week sample, with a source reference and an owner for each unresolved item.
• Deliver twelve approved follow-up email drafts covering four named customer moments, each within a stated word range and using only facts found in the supplied source material.
• Deliver a documented handoff that lets two named employees complete one recurring report without asking the contractor for additional instructions.

A strong finished state can be inspected. It does not need to predict the customer's future revenue, guarantee a business result outside your control, or claim that an AI output is automatically correct.

Name the Acceptance Evidence

For each result, decide how the buyer will know it is done:

• A file, record, or working link exists.
• Required fields are complete.
• A person with the right authority approves it.
• A test, checklist, or reconciliation passes.
• A named employee can repeat the process from the handoff.
• A deadline is met and the handoff is acknowledged.

The evidence should match the promise. A count of generated documents does not prove that they are accurate. A dashboard delivered on time does not prove that its calculations are correct. Use evidence that tests the actual outcome and the quality standard.

Write acceptance criteria before the work begins. If the parties cannot agree on what "complete" means, the scope is not ready to price or sell.

Set a Boundary

Every first outcome needs a visible edge:

• One buyer, one workflow, and one time period.
• A maximum number of records, sessions, or deliverables.
• A defined set of source materials.
• Included review rounds and response times.
• Excluded activities and decisions.
• The date when inputs must arrive.
• Who approves the result.
• What happens when a request falls outside scope.

A boundary is not a lack of helpfulness. It protects the quality of the promised work and gives both parties a way to manage a new request without surprise.

For example, "Review every invoice" may be too broad. "Reconcile the 120 invoices in the September export and return an exception list plus a 30-minute handoff" has a countable input, a finished artifact, and a clear end.

Establish the Reason to Act Now

A real problem can still wait. Identify the trigger that makes action useful this month:

• A recurring deadline is approaching.
• A key employee is leaving.
• A backlog is delaying customer work.
• A new customer requires a faster process.
• A compliance review has a dated requirement.
• A current contractor is unavailable.

Do not invent urgency. If the buyer says the problem is real but can wait two quarters, record that evidence. A patient buyer may become a useful later customer, but the pilot may not fit the cash runway you need now.

The reason to act should come from the buyer's situation rather than pressure from you. Ask what happens if the problem remains unchanged through the next cycle.

Separate Your Work From the Customer's Decision

Your outcome can include producing evidence, recommendations, or a completed artifact. It cannot honestly promise that a customer will use the work well, that a third party will approve it, or that a business metric will move.

State the boundary clearly:

• You control delivery quality and agreed review tasks.
• The customer controls timely inputs, access, approvals, and internal adoption.
• External parties may control licenses, legal approval, or market results.
• Any estimate of savings or revenue is a scenario, not a guarantee.

This separation makes accountability credible. You remain responsible for what you promised without accepting responsibility for facts you cannot control.

Turn the Outcome Into One Sentence

Use this drafting pattern:

> For [buyer in a specific situation], deliver [inspectable result] within [time boundary], using [allowed inputs], so the buyer can [next decision or action], with completion evidenced by [acceptance test].

This is a working sentence, not marketing copy. It exposes missing elements. If the result cannot be described without several unrelated jobs, narrow it. If the deadline is absent, the scope has no economic edge. If the acceptance test is vague, delivery will be disputed.

Read the sentence back to the buyer and ask what is inaccurate or incomplete. Their correction is stronger evidence than your interpretation.

Decide What the Customer Owns

The outcome should make clear what the buyer receives:

• A working file.
• A final document.
• A recorded handoff.
• A reusable checklist or template.
• Access to a system for a stated period.
• A recommendation that the buyer decides whether to implement.

Do not silently assign ownership or licensing rights that the buyer expected. If third-party tools, fonts, data, or model providers are involved, review their terms and the customer's requirements. If the work includes confidential materials, define who may access them and when they must be deleted or returned.

Apply a Usefulness Test

Before drafting the offer, test the outcome in five ways:

1. Specific: Could two reasonable people inspect the result and agree whether it is finished?
2. Bounded: Can you estimate the inputs, time, revisions, and dependencies?
3. Valuable: Did the buyer describe a cost or missed opportunity tied to this result?
4. Timely: Is there a real trigger for purchasing within the current cash window?
5. Responsible: Can you deliver without unverified claims, unlawful access, or avoidable privacy risk?

If any answer is no, revise the outcome before writing a proposal or setting a price. A convincing sales message cannot repair a result that is undefined.

A Worked Paid Outcome

The following is an illustrative composite, not a claim about a real buyer.

Nina is a former operations analyst. In the previous exercise, she chose independent training companies with five to fifteen employees. Three owners described the same recurring moment: after a live workshop, a large transcript is available, but no one has time to turn it into a useful follow-up sequence before the next event.

Nina's first impulse is: "I will help training companies use AI to create content." That is too broad. It could include social posts, course design, customer service, or an always-on chatbot.

She narrows the promise to:

> For an owner of a small live-training company who has an approved transcript from the most recent paid workshop, deliver twelve follow-up email drafts covering four named customer moments within five business days, using only the supplied transcript and program notes, so the owner can approve a post-workshop sequence before the next event, with completion evidenced by the owner's written approval of the four sequences and a source note for every factual claim.

The boundary includes one workshop transcript, one set of approved program notes, two review rounds, and a maximum of fifteen source emails. It excludes list cleanup, legal review, sending the emails, claims about response rates, and ongoing campaign management.

The buyer supplies the transcript, confirms the four workflow moments, reviews drafts by a stated date, and decides whether the draft claims are suitable for their business. Nina removes customer names from the transcript when they are not needed, uses only an approved work account, and records where each claim came from.

The acceptance test is a reviewed file plus a short handoff that explains how each draft maps to its source. This is still a meaningful result, but it is a result Nina can inspect and deliver.

Your Chapter Exercise

Choose the strongest segment card from the previous chapter and complete this exercise:

1. Interview or re-read evidence for one triggering situation.
2. Write three activity statements for what you could do.
3. Rewrite each as an inspectable finished state.
4. Add the acceptance evidence for each result.
5. List the inputs, dependencies, and exclusions.
6. Identify the buyer who approves completion.
7. Explain the cost or consequence of remaining unchanged through the next cycle.
8. Draft the one-sentence outcome statement.
9. Ask one buyer to correct the statement, especially the definition of done.
10. Mark any claim you would need to verify before putting it in an offer.

Do not ask the buyer to approve a large custom project yet. The objective is to confirm that you understand one useful outcome.

Chapter Deliverable

Create a one-page paid-outcome card containing:

• Buyer and triggering situation.
• Current workaround and observed consequence.
• Finished state.
• Acceptance evidence.
• Inputs, deadline, review limit, exclusions, and approvals.
• Customer responsibilities and your responsibilities.
• Data and access needs.
• One-sentence outcome statement.
• Evidence still missing.

Source and Decision Caution

Past behavior is useful evidence, but a few conversations do not prove demand, willingness to pay, or a reliable market. Do not present interview anecdotes as measured market facts.

Business, consumer, data, solicitation, and record-keeping rules vary by jurisdiction. Obtain qualified legal, tax, insurance, or privacy advice when an outcome involves regulated information, financial decisions, health information, sensitive personal data, or a consequential outcome.

AI tools can produce plausible but false facts, quotations, and source references. Keep a human review step, preserve source material where permissions allow, and do not put confidential information into an unapproved service. An AI-generated artifact is not proof that the promised outcome was achieved.

The next chapter turns this outcome into a one-page offer that the buyer can understand and respond to.