cs-marketing-offer-creation

Offer creation from buyer evidence

Non-negotiable clarity gate

Before keeping any sentence, ask:

Does this sentence ADD anything/answer any confusion?

If it does neither, remove it. Do not keep a line because it sounds polished, creates rhythm, or gestures at a benefit already stated elsewhere. Every line must introduce useful information, make the offer more concrete, resolve a likely objection, explain a necessary dependency, or move the buyer to the next action.

Reject copy that creates more questions than it answers. For example, “Know where Ai fits before you build” is not clear enough: fits where, and build what? “Your team stays in control” is also incomplete unless the offer says what the team controls. Prefer a concrete deliverable such as: “Get a technical plan, with step-by-step instructions on how to build a custom Ai agent.” A useful supporting line can then explain why it matters: “You can’t build a dependable Ai agent without a proper technical plan. Get one built correctly, so your agent doesn’t keep breaking, for just $49.”

On the final edit, interrogate every sentence:

What new information does this add?
Which specific confusion or objection does it answer?
Are the subject, action, object and result concrete on first reading?
Does it introduce an undefined phrase that makes the buyer ask “what does that actually mean?”

If there is no precise answer, delete or rewrite the sentence. This rule is non-negotiable and overrides stylistic preferences, clever phrasing, rhythm and the desire to make the offer sound more “marketing.”

Outcome and scope

Produce a specific offer that the intended buyer can recognise, understand and buy, while preserving what the front end really delivers and what is sold later. The result is an offer decision document plus message territories that can be handed to ads and pages.

Start with the business, customer and product evidence already available. Use competitor research to answer a real uncertainty, not as a mandatory opening ritual. A customer email explaining what work keeps returning to them can be more useful for the promise than a large sample of generic ads.

Approval boundaries. Reading supplied material, public research and writing offer documents are within scope. Do not launch ads, spend budget, publish pages, contact customers or competitors, or invent claims. Paid research tools need the user's authorisation when they consume credits. Continue with the evidence already available instead of creating an approval gate for ordinary offer work.

Establish the commercial chain

Recover the following from the request, earlier decisions, customer material and current product before writing copy. Label important statements as EVIDENCE, USER DIRECTION or HYPOTHESIS. Ask only when the missing answer would materially change the buyer, deliverable, price or funnel; otherwise make the narrowest useful assumption and mark it.

Buyer qualification: what must already be true about the business, authority, staff, customers, tools, prior attempts and ability to pay? State disqualifiers as clearly as qualifiers.
Audience state: what have they tried, what repeatedly happens, what do they think the problem is, and what do they understand today?
Purchase motive: what immediate pain are they trying to remove or what business gain are they trying to create? Separate motives that imply different incidents, proof or promises.
Front-end offer: what do they buy now, for what price, and what tangible output or decision do they leave with? Classify it as discovery/diagnosis, education, software access, implementation or another exact format.
Mechanism: how does the front end create that result, stated in terms the buyer can understand? Seller-side software, capability knowledge or process may power the mechanism without becoming the cold-traffic promise.
Downstream offer: what is sold later, at what indicative price or level of commitment, and what fit signal should the front end reveal?
Traffic and destination: cold or warm, channel, awareness level, CTA and where the click lands.
Economics and proof: price ladder, acquisition target if known, order bumps/upsells only when commercially justified, and usable proof or claims.

Do not design the front end as a disguised description of the high-ticket sale. The downstream product informs who the front end should attract, while the front-end promise must stop at what the buyer actually receives now.

Build the ICP as a buying situation

An ICP is useful when it predicts who recognises the ad, values the offer and can progress into the next sale. Capture:

Required business facts, such as existing staff, customers, a live workflow or an existing product.
Current behaviour, such as experimenting with tools, assembling automations, or building a dashboard, CRM or prototype.
The repeated incident that creates urgency.
Their ambition in their own words.
What they know, what they are unaware of, and which technical language they would not use.
Buying authority, budget context and disqualifiers.

Do not broaden an offer for established operators into “anyone interested in AI.” Do not use industry labels unless the offer or evidence requires them.

AI-worker discovery pattern

For a discovery offer aimed at established nontechnical business owners, the qualification may require staff and customers already in place. They are comfortable trying AI tools and may have built or commissioned a CRM, dashboard, command centre or prototype, but they do not understand the memory, connections, permissions, infrastructure and guardrails required for reliable AI workers.

Two motives should normally become separate offer-message families:

Motive	What they recognise	What they want
Internal operations	Systems may work, yet checking, paperwork, coordination and exceptions still return to the owner	AI workers completing useful recurring work inside existing software or across cloud tools, with the right approvals
Customer software	They are building or already have software for customers but cannot turn agents into a dependable part of the user experience	Useful agents inside the product that help customers complete real work

A low-ticket discovery product can sell the answer to: “Given my business, what I am trying to achieve and what I have already built, how do I get AI doing useful work without creating another thing I have to manage?” Its mechanism may be a conversational discovery engine informed by implementation capabilities. Cold traffic does not know the vendor, so do not sell “discover what is possible inside our platform.” Sell the business decision and useful clarity. Keep the platform and technical capability map as internal support for the mechanism.

If the front end is discovery, it can identify suitable work, required connections, information/memory, human approvals, priorities and a credible implementation path. It cannot promise that agents are deployed unless implementation is included. Later implementation or a high-ticket agent build is a separate downstream sale.

Treat sharper interpretations carefully. Working systems plus continuing owner burden are evidence that the systems have not removed the work; they do not by themselves prove AI created more work. A wish for agents inside customer software does not prove the motive is more usage or revenue. Keep those as hypotheses until customer language or behaviour supports them.

Turn evidence into the offer

Create a compact evidence ledger before choosing a promise:

Observation or phrase	Source	Status	Offer implication
Exact customer wording or observed behaviour	customer source/date	EVIDENCE	incident, objection, ambition or proof
Explicit strategic choice	user	USER DIRECTION	constraint or decision
Plausible interpretation	analysis	HYPOTHESIS	angle to test, not a claim

Then specify:

Offer name: useful internally even when it is not customer-facing.
One buyer: the qualified decision-maker for this path.
One primary motive: pain relief or gain, with the recognisable incident.
Promise: the result of this purchase in plain buyer language.
Mechanism: why this next action creates progress.
Deliverable: exactly what they receive, its depth and limits.
Price and CTA: including any genuine guarantee or urgency.
Proof: only supported claims, with attribution where needed.
Downstream bridge: why a suitable buyer would reasonably want the later product, without implying it is included now.

Use direct bundle-offer mode when the stack is the hook

When the user supplies offer copy and explicitly says it is the version they were trying to reach, treat its structure and commercial emphasis as USER DIRECTION. Preserve it as the canonical baseline. Do not force it back through a longer founder story, a mandatory historical revenue opening or an abstract result-only headline unless the user asks for another mode.

A low-ticket bundle can be strongest when the bargain itself is immediately clear. Use this shape when the actual product stack and price do the selling:

A plain audience callout when it helps qualification.
The concrete package value and purchase price in the opening.
One short recognition moment in the buyer's language.
“Here is what you get,” followed by the real deliverables. For each, name the product, its supported value and why it is useful.
Total value, current price and one direct CTA.

This is not the same as turning the copy into a repetitive capability list. Three separately fulfilled products are a genuine offer stack. Repeating the same agent functions under several headings is padding. Keep the recognition section short and let each deliverable earn its place.

Do not lead only with an unfamiliar product name. A cold buyer may not know what a “Discovery Engine” is. Pair the stack with the wanted change, such as getting useful work off the owner, creating capacity to scale or working out where AI can save money and what to build first. The tool is the mechanism.

For the current AI business-discovery bundle, the approved campaign example is:

AI Business Discovery Engine Agent: stated value $1,122. It is a tool-equipped conversational agent with web research and knowledge of agent infrastructure, not merely a static plan or generic chatbot.
Agentic Business Case Study: stated value $197. The reported move from $50/month to over $2,000/month is seller-side case-study evidence, not a buyer earnings guarantee.
Launch-Ready One-to-One Call: stated value $275.
Stated total value: $1,594. Purchase price: $27.

Use these exact figures only for this approved offer or when the user supplies them again. A “next 24 hours” or “today only” line is a dated campaign variant; never turn it into evergreen or resetting scarcity.

Keep outcome, obstacle and mechanism separate while reasoning, then compress them into a direct offer the buyer can repeat. A useful starting shape is:

Use this [price] [deliverable] to [specific result] without [real obstacle]

This is a starting shape, not a compulsory template. Prefer the shortest version that still names what is bought and why it matters. The mechanism can live in a supporting sentence on a page; it does not have to become a technical headline. For image-ad handoff, supply the headline, offer/price and CTA plus a visual mechanism note. Do not solve a weak image by printing the full explanation on it.

Test every draft:

Can a qualified buyer recognise their present situation in the first line?
Does the promise answer a decision they already want made or a result they already want created?
Would a cold prospect understand it without knowing the vendor, product name or technical architecture?
Does the mechanism explain progress without technical theatre?
Does the deliverable fulfil the promise at the stated price?
Does each major motive have its own path rather than a vague all-in-one line?
Are outcome, revenue, usage, time-saving and workload claims supported?
Is implementation clearly separated from discovery or education?
Can the buyer repeat what they get, why it matters and what they pay without hearing an additional explanation?

Money is one possible endpoint, not a universal requirement. Time back, owner relief, reduced management burden, faster decisions, customer capability and risk reduction can be stronger when that is what the buyer is actually seeking. Do not force a number, order bump or revenue claim because another funnel used one.

Match every guarantee to the purchase it covers. A verified money-back guarantee for a low-ticket discovery product covers that purchase only. An outcome-backed implementation guarantee, such as a revenue result or money back, is a separate commercial offer and obligation. Treat a floated outcome guarantee as a HYPOTHESIS until its result, scope, attribution method, time window, exclusions and refund terms are explicitly approved and supportable. Never append it to the discovery offer by association.

Result-led refund guarantees

When the user asks for a result-backed guarantee, name the useful result of this purchase before the refund. Do not leave risk reversal as only a generic “30-day money-back guarantee” badge. Use this reusable structure:

Get [specific result/deliverable within this purchase], or get [purchase price] back

State the refund-request window clearly in the primary text or offer terms. Keep any existing broader refund policy intact: the result-led wording must not add completion requirements, implementation milestones or other new hurdles to an existing refund right. Reuse terms already authorised in the session; do not ask again merely because the copy is more specific.

For the $27 AI Discovery Engine, the user-directed version is:

Find where AI fits in your business and what to build first, or get your $27 back

Supporting terms: “If it doesn’t give you that clarity, request a refund within 30 days of purchase.” This promises discovery clarity, not a deployed agent, revenue growth or a completed build. A separate implementation-result guarantee needs its own supported scope and terms. For images, shorten the guarantee while preserving the same result and refund meaning; carry the full window in the accompanying copy and destination. Keep actual product, checkout and ad terms consistent before publication.

Research only the uncertainty

Use public research when it can change a decision: whether a format or promise has survived, how competitors package the front end, where prices cluster, or which mechanisms are crowded. Record the search scope and limitations.

When the Meta Ad Library is relevant, read ad-library-research.md. Longevity and creative duplication are directional signals, not conversion or profitability data. Quote competitor copy as evidence; never ship it as the user's copy.

Artifacts

Save a dated offer decision document containing:

The commercial chain and ICP qualification.
The evidence ledger, including unresolved hypotheses.
The selected front-end offer and exact boundaries.
The downstream offer and qualification bridge.
Distinct message territories for each supported motive.
Research scope and limitations when external research was used.

Store the reusable strategic conclusions in the authorised business-memory system when one is configured. Keep private emails and customer-identifying records in the appropriate private source store; do not copy them into a reusable skill repository.

Verification and status

Before reporting completion, confirm the named buyer meets the qualification, the front-end promise matches the deliverable, the downstream product is not implied as included, each material claim has a source/status, and the message works for the stated traffic awareness. Report what remains a hypothesis and what evidence was not covered.

Use DRAFT for an offer that has not run, DOGFOODING while it is being used on the owner's campaign, PROVEN only after repeat evidence, AWAITING APPROVAL for a real pending approval and BLOCKED for a missing required input. Research quality alone does not make an offer proven.

Handoff

Send the commercial chain, selected promise, evidence ledger, exact deliverable and message territories to cs-marketing-image-ads and cs-marketing-website. Keep full implementation scope with the relevant build or sales-delivery workflow.