オファーアーキテクト は何をしますか？
オファーはページの前に決定されます。conversion-page-build は渡されたものに対して議論を書きます。渡されたものが弱い場合、誰も欲しがらないものに対する流暢なコピーが生成されます。このスキルは、その「もの」そのものを生成します。
最初にブリーフがあれば読む
03 Projects/<Project>/_Research/[C] Conversion Brief — *.md、または（このセットアップ外で実行している場合）プロジェクトのリサーチフォルダを探してください。そのうちの3つのセクションは、再決定するものではなく、ここへの入力です。レジスター、ランク付けされた異議、および利用可能な証拠です。特にレジスターはクライアントごとに一度設定され継承されます。../audience-research/SKILL.md を参照してください。
ブリーフがなくても実行は可能ですが、その旨を出力に明記し、すべてのオーディエンスに関する主張を NOT ESTABLISHED — <それを確定するために必要なもの> とマークしてください。想定されたバイヤーに対して設計されたオファーは、後で誰もその診断を確認できないオファーです。
推奨の境界線
商用条件はクライアントの決定事項です。 価格レベル、割引、契約形態、返金リスク、誰がリスクを負うかはクライアントが設定するものです。クライアントはコスト面、キャッシュポジション、結果に対する責任を負います。このスキルは分析と、その推論を伴う1つの推奨を生成します。それは推奨としてラベル付けされ、受け入れ、拒否、または検討して却下された代替案と交換することができます。
以下の2つのルールは、見た目以上に重要です。
- 確定したかのように数値を成果物に決して書かないでください。 文書内で修飾なしに登場した価格は、合意されたものとして引用されます。数字を表示する必要がある場合は、それが推奨、イラスト、またはクライアント自身が述べた数値であることを明記してください。
- 確定していないことは文書内に明記してください。 あなたが持っていないコストモデルは、価格を構造的に評価することと商業的に評価することの違いであり、後者は、別段の記載がない限りクライアントが得られると思っているものです。
レジスターは継承され、ここでは見た目以上に多くのことを決定する
フレームワーク層はどこでも変更されずに適用されます。すべてのバイヤーはオファーについて同じことを確立する必要があり、以下の手順は誰が読んでも同じ順序でこれらを確立します。異なるのは、それらを確立するためにどの手段が使用可能かです。
保守的なB2B保証は、ダイレクトレスポンスの保証とは異なります。 これらは同じジョブを果たすための異なるボリュームの同じデバイスではなく、異なる手段です。ダイレクトレスポンスでは、攻撃的なリスクリバーサルを大声で宣言することがバイヤーの期待であり、その欠如は差別化の失敗です。保守的なB2B（DACH）では、同じ構造は詐欺のシグナルとなり、隣にある検証可能な主張の信頼性を損ないます。そのため、メカニズムは代わりに販売条件として提供される必要があり、多くの場合「保証」という言葉をまったく使わずに提供されます。同じ非対称性が、希少性、価格アンカリング、スタックの提示、ピッチにも見られます。以下のすべての参照ファイルには、レジスターが手段を変更する5つのレジスター表が含まれています。ブリーフで指定された行のみを読んでください。
5つのレジスター：保守的なB2B（DACH） · 技術/産業 · 消費者/ライフスタイル · ミッション/非営利 · ダイレクトレスポンス。../audience-research/references/register-profiles.md で定義されています。
手順
7つのステップ。順番通りに実行します。各ステップの出力が次のステップへの入力となるため、順序が重要です。
- 設計前の診断 —
references/value-equation.md。スコアではなく診断として読む4つの変数。出力は制約となっている変数、つまり現在最も損害を与えている弱点を持つ変数です。この後のすべてのステップはその変数を対象とします。 - 障害のマッピング — 同じファイル。このバイヤーと成果の間に実際に存在するものを、何も提案する前に列挙します。書き留められなかった障害は、後で異議として現れます。
- すべての障害をそれを取り除くものに変え、それがどのようにしてバイヤーに届くかを選択する —
references/delivery-models.md。手段はパッケージングの決定ではなく設計の決定です。同じ約束でも、バイヤーが単独で作業するか、監督下で作業するか、代わりに作業してもらうかによって、3つの異なる価格の3つの異なるオファーになります。そしてそのうちの1つはこのバイヤーにとって間違っています。 - スタックを構築し、価格を設定する —
references/value-stack-and-bonuses.md、次にreferences/pricing-and-anchoring.md。スタックが先です。整合性のないスタックに対して主張される価格は、裏付けのない価格です。 - リスクリバーサルを設計する —
references/guarantees-risk-reversal.md。これが機能しない場合に何が起こるかを、仲裁なしで実際に履行可能な条件で明記します。 - 名前を付け、アングルを選ぶ —
references/offer-angles.md。アングルはリフレーミングするものであり、オファーを変更するものではありません。新しいアングルが問題を解決するように見える場合は、問題がフレーミングであったかどうかを確認します。 - ピッチを作成する —
references/pitch-formats.md。短い、中程度、長いの3種類。それぞれ、独立して作成するのではなく、同じ主要な主張から導出されます。
既存のオファーの監査
実際の作業のほとんどはステップ1ではなくここから始まります。references/offer-audit-checklist.md は、誰かがすでに組み立てたオファーに対して上記のシーケンス全体を逆方向に実行し、見つかったものを証拠の状態によって分類し、制約となっている変数を特定します。オファーが存在する場合は、最初にこれを実行します。そうすれば、再設計のステップには具体的な目標が与えられます。
このスキルが生成するもの
1つの文書。金庫の慣例により 03 Projects/<Project>/_Research/[C] Offer — <Name>.md、またはそれ以外の場合はプロジェクトのリサーチフォルダに保存されます。これには、4変数の診断とどの変数が制約となっているか、障害から解決策へのマップ、各行の価値の出所を含むスタック、配送モデルとその理由、推奨としてフラグが立てられた価格分析、リスクリバーサルの推奨と却下された代替案、名前とアングル、そして3つのピッチの長さが含まれます。
スタックとリスクリバーサルのセクションは、conversion-page-build がページの「バリュースタック」と「保証」セクションを記述するときに必要とするものです。ここで曖昧にされたものは、そこで発明されます。したがって、出所のないスタック行やトリガーのない保証は、単なる未解決事項ではなく、下流に渡される欠陥です。
NOT ESTABLISHED と継続的仮定ルール
1つの規律の2つの側面。両方ともスキル全体の方針です。参照ファイルはこれらを適用し、再記述する代わりにここを参照します。
証拠を示せない発見は NOT ESTABLISHED — <それを確定するために必要なもの> と記述し、決してあいまいな表現に和らげたり、削除したりしてはいけません。これは audience-research が使用するのと同じ規律であり、同じ理由です。明示されたギャップは埋められますが、静かなギャップはクライアントによって発見されます。
計算が依存している未確認の事柄は、解決せずに継続します。 オファーの数字が誰も実際に確認していないもの（本当に存在する場所の数、記載された合計が一人当たりかグループ全体か、条件が合意されたのか単に議論されたのかなど）に依存している場合、その仮定を、それが逆だった場合に何が変わるかとともに書き留め、次に進みます。税務処理と徴収のタイミングは最も頻繁に問題となる2つであり、どちらも references/pricing-and-anchoring.md で継続されています。これが禁止するのは、暗黙のうちに、自分が目指していた結論を支持する方向であいまいさを解決し、その上に3つのセクションを構築することです。その失敗は完成した文書では見えません。だからこそ、仮定を頭の中ではなくページ上に記述する必要があるのです。