offer-architect (오퍼 설계사)

오퍼 설계사(Offer architect)

오퍼는 페이지보다 먼저 결정됩니다. conversion-page-build는 전달받은 내용에 대한 근거를 작성합니다. 만약 전달받은 내용이 약하다면, 아무도 원하지 않는 것에 대한 유려한 카피가 생성될 뿐입니다. 이 스킬은 바로 그 '내용(thing)'을 생성합니다.

먼저 브리프(Brief)가 있다면 읽으십시오

03 Projects/<Project>/_Research/[C] Conversion Brief — *.md 파일이나, 해당 설정 내에서 실행 중이 아니라면 프로젝트의 리서치 폴더를 찾으십시오. 이 브리프의 세 가지 섹션은 재결정할 대상이 아닌 입력값입니다: 레지스터(Register), 순위가 매겨진 이의(Obstacles), 그리고 사용 가능한 증거(Proof available). 특히 레지스터는 클라이언트당 한 번 설정되며 상속됩니다 — ../audience-research/SKILL.md를 참조하십시오.

브리프 없이도 실행할 수는 있지만, 출력에 그 사실을 명시하고 모든 청중 주장에 NOT ESTABLISHED — <이것을 해결할 방법>이라고 표시하십시오. 가상의 구매자를 가정하고 설계된 오퍼는 나중에 아무도 진단을 확인할 수 없는 오퍼입니다.

권장 사항의 경계

상업적 조건은 클라이언트의 결정 사항입니다. 가격 수준, 할인, 계약 형태, 환불 노출 및 위험 부담은 클라이언트가 설정할 몫입니다. 그들이 비용 측면, 현금 상황 및 결과를 책임집니다. 이 스킬은 분석을 생성한 후, 하나의 권장 사항과 그 근거를 제시하며, 이를 권장 사항으로 명확히 레이블링하여 수락, 거부 또는 고려 후 제외된 대안으로 교체할 수 있도록 합니다.

다음 두 가지 규칙을 따르며, 이는 겉으로 보기보다 훨씬 중요합니다:

• 확정된 것처럼 숫자를 결과물에 절대 작성하지 마십시오. 문서에 조건 없이 등장하는 가격은 합의된 것으로 인용될 수 있습니다. 숫자가 반드시 표시되어야 한다면, 그것이 무엇인지 명시하십시오 — 권장 사항, 예시 또는 클라이언트가 직접 언급한 숫자임을 밝히십시오.
• 문서에 확립되지 않은 내용을 명시하십시오. 보유하지 않은 비용 모델은 가격을 구조적으로 평가하는 것과 상업적으로 평가하는 것의 차이를 만듭니다. 그리고 후자는 달리 명시하지 않는 한 클라이언트가 얻고 있다고 생각하는 것입니다.

레지스터는 상속되며, 여기서 보이는 것보다 더 많은 것을 결정합니다

프레임워크 계층은 변경 없이 모든 곳에 적용됩니다: 모든 구매자는 오퍼에 대해 동일한 사항을 확립해야 하며, 아래 단계는 독자에 관계없이 동일한 순서로 이를 확립합니다. 달라지는 것은 이러한 사항을 확립하는 데 사용할 수 있는 도구(instruments)입니다.

보수적인 B2B 보증은 다이렉트 리스폰스 보증과 다릅니다. 이는 단순히 강도가 다른 동일한 장치가 아닙니다. 이는 동일한 작업을 수행하는 다른 도구입니다. 다이렉트 리스폰스(Direct-response)에서 공격적인 위험 회피(risk reversal)를 큰 소리로 내세우는 것은 구매자가 기대하는 바이며, 이것이 없으면 차별화 실패입니다. 보수적인 B2B (DACH)에서는 동일한 구성이 사기 신호가 되어 옆에 있는 검증 가능한 주장의 신뢰성을 떨어뜨리며, 메커니즘은 대신 판매 조건(term of sale)으로 전달되어야 합니다. 종종 보증이라는 단어조차 사용하지 않습니다. 이러한 비대칭성은 희소성, 가격 앵커링, 스택 표현 및 피치 전반에 걸쳐 나타납니다. 아래 모든 참조 파일은 5개의 레지스터 테이블을 포함하며, 레지스터에 따라 도구가 변경됩니다. 브리프에서 명명된 행만 읽으십시오.

다섯 가지: 보수적인 B2B (DACH) · 기술/산업(Technical / industrial) · 소비자/라이프스타일(Consumer / lifestyle) · 미션/비영리(Mission / nonprofit) · 다이렉트 리스폰스(Direct-response). ../audience-research/references/register-profiles.md에 정의되어 있습니다.

순서

일곱 단계로, 순서대로 진행됩니다. 각 단계의 출력이 다음 단계의 입력이 되므로 순서가 중요합니다.

1. 설계 전 진단 — references/value-equation.md. 점수가 아닌 진단 도구로 읽는 네 가지 변수입니다. 출력은 결정적 제약(binding constraint), 즉 현재 가장 큰 피해를 주는 약점 변수입니다. 이 후의 모든 단계는 이 변수를 목표로 합니다.
2. 장애물 매핑 — 동일한 파일. 어떤 것이 제안되기 전에, 구매자와 결과 사이에 실제로 존재하는 장애물을 열거합니다. 기록되지 않은 장애물은 나중에 반대 의견(Objection)이 됩니다.
3. 모든 장애물을 제거하는 무언가로 바꾸고, 그것이 구매자에게 어떻게 도달할지 선택 — references/delivery-models.md. 전달 방식(vehicle)은 포장 디자인이 아닌 설계 결정입니다. 하나의 약속은 구매자가 혼자 수행하는지, 감독하에 수행하는지, 아니면 대신 수행해 주는지에 따라 세 가지 다른 오퍼이자 세 가지 다른 가격이 될 수 있습니다. 그리고 세 가지 중 하나는 이 구매자에게 잘못된 것입니다.
4. 스택을 구축하고 가격을 책정 — references/value-stack-and-bonuses.md, 그 다음 references/pricing-and-anchoring.md. 스택이 먼저입니다. 합산되지 않는 스택을 근거로 주장된 가격은 뒷받침할 내용이 없는 가격입니다.
5. 위험 회피 설계 — references/guarantees-risk-reversal.md. 이것이 작동하지 않을 경우 어떻게 될지, 중재 없이도 실제로 이행될 수 있는 조건으로 명시합니다.
6. 이름을 짓고 앵글(Angle)을 선택 — references/offer-angles.md. 앵글은 재구성(reframes)할 뿐 오퍼 자체를 변경하지 않습니다. 새로운 앵글이 문제를 해결하는 것처럼 보인다면, 문제가 과연 프레이밍(framing)이었는지 확인하십시오.
7. 피치(Pitch) 생성 — references/pitch-formats.md. 짧은 버전, 중간 버전, 긴 버전. 각각 독립적으로 작성되는 것이 아니라 동일한 핵심 주장에서 파생됩니다.

이미 존재하는 오퍼 감사(Auditing)

실제 작업의 대부분은 1단계가 아닌 여기서 시작됩니다. references/offer-audit-checklist.md는 누군가 이미 조립한 오퍼에 대해 전체 순서를 역방향으로 실행하고, 발견된 내용을 증거 상태별로 분류하며 결정적 제약을 명명합니다. 오퍼가 이미 존재할 때 먼저 실행하십시오. 그러면 재설계 단계가 특정 목표를 가질 수 있습니다.

생성 결과물

볼트 규칙에 따라 03 Projects/<Project>/_Research/[C] Offer — <Name>.md 파일 하나, 또는 그 외의 경우 프로젝트의 리서치 폴더에 생성됩니다. 이 파일에는 다음이 포함됩니다: 네 가지 변수 진단 및 어떤 변수가 제약인지, 장애물-해결책 매핑, 각 항목의 가치 출처가 포함된 스택, 전달 모델 및 그 이유, 권장 사항임을 표시한 가격 분석, 위험 회피 권장 사항과 제외된 대안, 이름과 앵글, 그리고 세 가지 피치 길이.

스택과 위험 회피 섹션은 conversion-page-build가 페이지의 가치 스택(Value stack) 및 보증(Guarantee) 섹션을 작성할 때 필요로 하는 정보입니다. 여기서 모호하게 남겨진 부분은 거기서 발명되므로, 출처가 없는 스택 항목이나 트리거가 없는 보증은 단순한 느슨한 끝이 아니라 하류로 전달되는 결함입니다.

NOT ESTABLISHED 및 전제 조건 명시 규칙

하나의 규율의 두 가지 측면입니다. 둘 다 스킬 전체의 정책이며, 참조 파일은 이를 적용하고 다시 설명하지 않고 여기를 참조합니다.

증명할 수 없는 발견사항은 NOT ESTABLISHED — <해결에 필요한 것>이라고 작성하며, 애매한 표현으로 순화하거나 생략하지 않습니다. 이는 audience-research가 사용하는 것과 동일한 규율이며, 동일한 이유입니다: 명시된 격차는 해소되고, 조용한 격차는 클라이언트에 의해 발견됩니다.

산술이 의존하는 확인되지 않은 사항은 해결되지 않고 전달(carried)됩니다. 오퍼의 숫자가 아무도 실제로 확인하지 않은 사항(실제로 존재하는 자리의 수, 명시된 총액이 1인당인지 그룹인지, 조건이 합의되었는지 단순히 논의되었는지)에 의존할 때, 그 가정과 함께 그것이 반대 방향으로 판명될 경우 무엇이 바뀌는지 기록한 후 진행하십시오. 세금 처리와 징수 시점이 가장 자주 문제가 되는 두 가지이며, 둘 다 references/pricing-and-anchoring.md에 전달됩니다. 이 규칙이 금지하는 것은 애매모호함을 당신이 원래 목표했던 결론에 유리한 방향으로 조용히 해소하고, 그 위에 세 개의 섹션을 쌓는 것입니다. 그런 실패는 완성된 문서에서 보이지 않으며, 이것이 바로 가정이 당신의 머릿속이 아닌 페이지에 있어야 하는 이유입니다.