報價架構師
報價是在頁面之前決定的。conversion-page-build 會為它收到的任何內容撰寫論證；如果收到的內容薄弱，結果就是針對沒人想要的東西寫出流暢的文案。這項技能會產出那個東西。
首先閱讀簡報（如果存在的話）
尋找 03 Projects/<Project>/_Research/[C] Conversion Brief — *.md，或者如果你不是在該設置下運行，則尋找你的專案研究資料夾。簡報中的三個部分在這裡是輸入，而不是需要重新決定的東西：語域 (Register)、排序後的異議 (Objections) 和可用的證明 (Proof available)。特別是語域，每個客戶設定一次並繼承——請參閱 ../audience-research/SKILL.md。
沒有簡報你仍然可以運行，但要在輸出中說明，並將每個受眾聲明標記為 NOT ESTABLISHED — <what would close it>。針對假設的買家設計的報價，是一個事後無人能驗證其診斷的報價。
建議的邊界
商業條款是客戶的決定。 價格水平、折扣、合約形式、退款風險以及誰承擔風險，都是由他們設定——他們掌握成本面、現金狀況和後果。這項技能產出分析，然後給出一個附有理由的建議，並標記為建議，以便它可以被接受、拒絕，或替換為被考慮過但擱置的替代方案。
以下兩條規則看起來簡單，但都非常重要：
- 切勿將數字寫入交付成果，如同已成定局。 文件中未經限定的價格會被當作已達成協議而引用。如果必須出現一個數字，請說明它是什麼——一個建議、一個示意，或是客戶自己陳述的數字。
- 在文件中說明哪些是尚未確立的。 你沒有的成本模型，是結構性評估價格和商業性評估價格之間的區別，而客戶通常認為他們得到的是後者，除非你明確說明。
語域是繼承的，它在這裡的決定性比看起來更大
框架層在各處不變地傳遞：每個買家都需要就報價確立相同的事項，而以下步驟以相同的順序為任何閱讀者確立這些事項。變化的是哪些工具可用於確立它們。
保守的 B2B 保證不是直接回應式保證。 它們不是兩種不同強度的相同裝置——它們是服務於同一工作的不同工具。在 Direct-response 中，大聲說出的激進風險逆轉是買家所期望的，而它的缺失是差異化上的失敗。在 Conservative B2B (DACH) 中，同樣的結構是一個詐欺信號，會使旁邊可驗證的主張失去信譽，而該機制必須以銷售條款的形式交付——通常完全不使用 guarantee 這個詞。同樣的不對稱性也存在於稀缺性、價格定錨、堆疊呈現和提案中。下面的每個參考文件都包含一個五種語域的表格，其中語域的變化會改變工具；僅閱讀簡報中提到的行。
五種語域：Conservative B2B (DACH) · Technical / industrial · Consumer / lifestyle ·
Mission / nonprofit · Direct-response。定義在
../audience-research/references/register-profiles.md。
順序
七個步驟，按順序進行。每一步的輸出是下一步的輸入，這就是順序重要的原因。
- 在設計之前進行診斷 —
references/value-equation.md。四個變數，作為診斷而非評分來閱讀。輸出是限制性約束：那個弱點目前造成最大損害的變數。此步驟之後的所有內容都針對該變數。 - 映射障礙 — 同一個文件。在提出任何方案之前，列舉實際存在於這個買家和成果之間的事物。任何未被寫下的障礙，日後都會變成一個異議。
- 將每個障礙轉化為消除它的東西，然後選擇如何將其傳達給買家 —
references/delivery-models.md。載體是一個設計決策，而不是包裝決策：同一個承諾，根據買家是獨自完成、在監督下完成，還是為他們完成，會以三種不同的價格呈現為三種不同的報價——而其中一種對這個買家來說是錯誤的。 - 構建價值堆疊，然後定價 —
references/value-stack-and-bonuses.md，然後是references/pricing-and-anchoring.md。先有堆疊。建立在一個不成立的堆疊上的價格，是一個背後空無一物的價格。 - 設計風險逆轉 —
references/guarantees-risk-reversal.md。如果這不起作用會發生什麼，用無需仲裁即可兌現的條款來陳述。 - 命名並選擇角度 —
references/offer-angles.md。角度重新定義框架；它不會改變報價。如果一個新角度似乎解決了問題，請檢查問題是否出在框架上。 - 產出提案 —
references/pitch-formats.md。短、中、長三種格式，每種都源自同一個承載性核心主張，而非獨立撰寫。
審核已存在的報價
大多數實際工作從這裡開始，而不是從步驟 1 開始。references/offer-audit-checklist.md 會對某人已經組合好的報價反向運行整個順序，根據證據狀態對其發現進行分類，並指出限制性約束。當報價存在時，先運行它；之後的重新設計步驟就有了具體的目標。
這項技能的產出
一份文件，按照庫約定位於 03 Projects/<Project>/_Research/[C] Offer — <Name>.md，或者在你的專案研究資料夾中。它包含：四個變數的診斷以及哪個變數構成限制、障礙到解決方案的映射、帶有每項價值來源的堆疊、交付模式及其原因、帶有標記為建議的定價分析、風險逆轉建議和擱置的替代方案、名稱和角度，以及三種長度的提案。
堆疊和風險逆轉部分是 conversion-page-build 在撰寫頁面的「價值堆疊」和「保證」部分時，需要放在面前的內容。此處任何含糊不清的內容都會在那裡被創造出來，因此一個沒有來源的堆疊行和一個沒有觸發條件的保證，並不是未解決的問題——它們是被傳遞給下游的缺陷。
NOT ESTABLISHED 以及承載假設規則
這是同一紀律的兩個方面。兩者都是技能範圍內的政策：參考文件會應用它們並在此處引用，而不是重新陳述。
你無法提供證據的發現，應寫為 NOT ESTABLISHED — <what it would take>，永遠不要將其軟化為模糊的說法，也永遠不要遺漏。這與 audience-research 使用的紀律相同，原因也相同：一個被陳述的缺口會得到填補，而一個未被察覺的缺口則會被客戶發現。
計算所依賴的未經確認的事項，應被承載，而非解決。 當一個報價的數字依賴於某些尚未有人真正確認的事情時——例如實際存在多少名額、一個陳述的總數是每人還是團體、一個條款是已同意還是僅被討論——請將該假設寫下，並附上如果事實相反會如何變化，然後繼續進行。稅務處理和收款時機是最常造成問題的兩項；兩者都在 references/pricing-and-anchoring.md 中被承載。這禁止的是：默默地在支持你原本結論的方向上解決模糊性，然後在其之上建立三個部分。這種失敗在完成文件中是看不見的，這正是為什麼假設必須寫在頁面上，而不是留在你的腦海中。