# Offer Creation

> Create, improve, reposition, and evaluate business offers using live market research plus structured offer design. Use when the task is to: (1) turn a topic, niche, or problem into an offer, (2) improve an existing offer, (3) adapt an offer to a new market or segment, (4) choose pricing, guarantees, tiers, or qualification rules, or (5) analyze whether an offer is strong enough to sell.

- Skill: `moussaoui-ghiles/offer-creation` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add moussaoui-ghiles/offer-creation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/moussaoui-ghiles/offer-creation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: Moussaoui-Ghiles (https://skillmd.com/u/moussaoui-ghiles)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/moussaoui-ghiles/offer-creation

---


# Offer Creation

Use this skill to build offers systematically instead of brainstorming randomly.

## Core rules

1. Run live market research before making strong claims about demand, pricing, guarantees, objections, or competitor patterns.
2. Apply three frameworks in order: Hormozi (what to build) → Haynes (how to frame it) → Fazio (how to deliver it). Do not skip the operational layer.
3. An offer is not complete until it has a fulfillment factory with mapped stations, an intake form, a pre-call sequence, a communication cadence, and a case study production process.

**Always read `references/framework.md` before starting any work.** It contains the full detail on every concept referenced in this skill — value equation, "you're f\*\*\*ing me" scale, desire stacking, guarantees, pricing, fulfillment factory, intake forms, pre-call sequence, communication cadence, case study flywheel. Without it, you will produce shallow output.

Also read before starting:
- `references/market-research.md` — live research workflow using web tools
- `references/output-template.md` — final output structure

## Entry modes
Choose one mode first.

### 1. Topic → offer
Use when the user starts with a topic, niche, market, audience, or problem and wants a net-new offer.

### 2. Offer → improve
Use when the user already has an offer and wants to strengthen positioning, pricing, guarantees, tiering, or conversion quality.

### 3. Offer → adapt
Use when the user wants to keep the core mechanism but retarget it to a different niche, buyer, or channel.

## Workflow

### Step 1: Clarify the starting point
Capture what is known:
- topic / niche / buyer
- painful problem
- desired outcome
- current offer if one exists
- current proof / authority / case studies
- delivery constraints
- preferred business model if specified

If key inputs are missing, make reasonable assumptions only when the user clearly wants exploratory ideation. Otherwise ask for the missing information.

### Step 2: Run live market research
Use `web_search` and `web_fetch` to gather current evidence before deciding on:
- pain intensity
- buyer language
- competitor offers
- pricing bands
- guarantee patterns
- objections
- whitespace
- whether the offer likely fits cold traffic, outbound, or only warmer channels

Follow `references/market-research.md`.

Minimum standard: do not present claims about current markets as facts unless they are supported by URLs you actually checked.

### Step 3: Build or diagnose the offer (Hormozi — what to build)
Use the value equation from `references/framework.md`.

At minimum, evaluate:
- dream outcome
- perceived likelihood
- time delay
- effort and sacrifice

Then improve the offer by:
- increasing desired upside
- increasing certainty
- reducing time to result
- reducing buyer effort and friction

### Step 4: Pressure-test the framing (Haynes — how to frame it)
Apply these checks from `references/framework.md`:

- "You're f\*\*\*ing me" scale: does value flip absurdly in the buyer's favor at EVERY phase? Check each phase independently (diagnostic, build, retainer). If any phase fails, restructure it.
- Costly not expensive: what does NOT buying cost them? That number must dwarf your price. Calculate both sides explicitly.
- Desire density: for premium offers, are 3-5 independently compelling desires stacked? Rich buyers buy on desire density, not price.
- Tier check: do the tiers (if any) improve speed and certainty at each level? Not every offer needs all three tiers — if stakes are too high for DIY, skip it.
- 30-day recurring value test: if the offer has a retainer, can the client point to what they received THIS month that is worth more than what they paid? Name the specific monthly deliverable.

### Step 5: Construct the offer
Build these parts explicitly:
- positioning
- core promise
- mechanism
- deliverable stack
- desire stack when useful
- tiering when useful
- pricing model
- guarantee or risk reversal
- qualification rules
- urgency / incentive only if justified

Rules:
- sell outcomes, not vague services
- make the offer concrete
- do not add random bonuses
- price from value, certainty, and economics
- do not recommend guarantees that depend on uncontrollable variables
- do not recommend recurring pricing unless recurring value is credible

### Step 6: Build the fulfillment factory (Fazio — how to deliver it)
This is the operational blueprint. Use `references/framework.md` fulfillment factory section.

Build these components:

**Fulfillment factory stations:** Map every step of delivery as a station. Each station: what happens, who does it (you / AI / automation / partner / client), how long. Map separate factories for each phase (diagnostic, build, retainer) and each tier (DIY/DWY/DFY) if applicable. Calculate total active time per engagement and capacity (how many clients simultaneously).

**Client intelligence extraction (intake form):** Design a structured 20-30 question intake form. Every question must tie to a delivery station. Sections: basics, current state, problem specifics, access/contacts. Sent immediately after payment. Takes 20-30 minutes to complete.

**Pre-call consumption sequence:** Design 3 touchpoints between booking and sales call. Touchpoint 1: confirmation + short video (what happens on the call, sample deliverable). Touchpoint 2: one teaching insight that positions expertise. Touchpoint 3: day-before reminder + guarantee + urgency. All automated.

**Communication cadence:** Define the update rhythm for each phase. Specify what, when, and through what channel. The client should never have to ask "what is happening?" Do not tell them about the cadence — just execute it consistently.

**Case study production:** Build into delivery by default. Capture "before" at intake, "after" at delivery, ask permission at 90 days. Every client becomes a case study. Case studies feed content. Content attracts new clients. Track case study production as a delivery metric.

### Step 7: Check delivery feasibility
Reject or downgrade offers that are attractive on paper but weak operationally.

Evaluate:
- repeatability
- margin potential
- buyer implementation burden
- proof requirements
- automation or systemization potential where relevant
- risk of churn or fulfillment breakdown
- whether the core process is documented clearly enough to repeat and improve
- whether the offer can work through cold traffic or outbound if scale is a goal
- 80/20 ratio: is 80% of energy on acquisition and 20% on fulfillment? If fulfillment is consuming too much, the factory is not built right

For service offers, distinguish mindful work from mindless work and push repeatable mindless work toward automation or systemization where realistic.

### Step 8: Score and refine
Score the offer on the rubric in `references/framework.md`.

If the score is weak, fix the weakest levers first instead of rewriting everything randomly.

Typical fix order:
1. weak outcome
2. weak certainty / proof
3. too much buyer effort
4. too much delay
5. poor economics or fulfillment feasibility
6. unclear qualification

### Step 9: Return the final output
Use `references/output-template.md`.

Always include:
- a one-line offer
- the full offer design
- why it should work
- weaknesses / risks
- at least 2 variants when the task is exploratory or strategic

## Quality bar
Good outputs are:
- evidence-backed
- concrete
- economically sensible
- operationally feasible
- specific about who it is for and not for

Bad outputs are:
- generic
- copied from market clichés
- priced only from competitor averages
- full of fake certainty
- loaded with random bonuses that do not improve the value equation

## Default behavior
If the user asks for an offer quickly, still do a lightweight live research pass before finalizing.

If evidence is thin, say:
- what is known
- what is inferred
- what needs validation next