cold-email-copy

コールドメールの文面

ColdIQ の手法でコールドメールの文面を作成します。キャンペーン全体で守られているルールと、うまくいった例・うまくいかなかった例から学んだパターンを引き継ぎます。このスキルを使って、シーケンスを一から作成するか、反応が得られていない下書きを書き直してください。

承認済みの事実は、追加できない主張の集合として扱います。提示されていないメリット、削減、改善、因果関係のある成果へと、機能を言い換えてはいけません。可能性を示す表現を付けても、裏付けのない製品の成果が安全になるわけではありません。提示する成果物も、限定されたコンテキストとして扱います。ブリーフに名前しかない場合は、その正確な名前で提示してください。内容、対象範囲、有用性、効果を作り上げてはいけません。

まず戦略から

文面の失敗は、表現の巧みさよりも戦略に原因があることのほうが多いです。文章を書く前に戦略ブリーフを作成し、担当者に提示してください。キャンペーンの仕様がすべて揃っている場合も含め、毎回これを実施します。仕様を検証することも、戦略ブリーフの役割の一つだからです。

STRATEGY BRIEF / <client> / <campaign>

ICP           Who receives this. Seniority, function, budget authority, what
              their week contains, and how often they get pitched.
TONE          The register, and one sentence that explains the choice.
EDUCATION     Expert / Aware-but-unpriced / Uninformed, plus the evidence.
ANGLE         One sentence. The single reason this person should care now.
REPLY DATA    What has earned replies on this account, with approved evidence.
DEPTH         Per-person openers or segment-level, and the segmenting fact.
SENDER        Which sending identity, and why this reader believes them.
SIGN-OFF      Claims and proof points that need written client approval first.
PUSHBACK      Where research disagrees with the operator, the evidence, and
              what would change in the copy.

ブリーフを担当者に渡したら、同じターン内で作業を続けてください。これは情報開示であり、承認を得るための関門ではありません。PUSHBACK の項目によって ANGLE 自体が変わる場合に限り、作業を止めて確認してください。指摘が正しいと仮定して、ANGLE を書き直します。それでも同じ人物と同じ問題を示すなら、そのまま進め、代替案は元に戻せるものとして明記してください。別の人物または問題を示すなら、作業を止めてください。それは別のキャンペーンになります。

ブリーフは、次の4点で決まります。

1. クライアントのコンテキストを把握し、市場を調査します。対象範囲に含まれる資料だけを読みます。利用可能かつ許可されている場合は、調査ツールを使います。必要な調査ができない場合は、もっともらしい答えを作り上げず、情報が不足していることを明記します。
2. 文体を決めます。役職の上位度、職業、売り込みを受ける頻度、予算の決定権、言語のニーズを考慮します。わかりやすい言葉とくだけた言葉は同じではありません。resources/audience-register.mdを参照してください。
3. 読み手がすでにどの程度知っているかを決めます。問題の専門家には、その問題の説明ではなく、送信者が業務を理解していることを示す証拠が必要です。resources/strategy-brief.mdを参照してください。
4. ANGLE を把握し、承認済みの返信に関する証拠と照合します。人物と問題を示す一文を書きます。意味を通すために製品についての説明が必要なら、それは ANGLE ではなく機能です。

担当者から ICP と ANGLE が提示されている場合も、調査を行ってください。証拠が仕様と矛盾する場合は、その食い違いを明記し、証拠を引用して、何が変わるのかを説明します。食い違いによって ANGLE 自体が変わらない限り、担当者の見立てに沿って書きます。

ブリーフが確定したら、人物ごとの手がかりを見つけます。各冒頭文で使う、実際の調査内容です。何もない場合は、文面を作成する前にその旨を伝えてください。resources/personalized-openers.mdを参照してください。

ルール

• メールは2通または3通作成します。
• 特に指定がなければ、各メールは75～90語にします。
• 各文は20語未満にします。
• 件名はそれぞれ3～5語にします。
• 1通につき依頼は1つにします。CTAを重ねないでください。
• 相手の課題や切り口から書き始め、製品やありきたりな挨拶から始めないでください。
• U+2014 の em ダッシュ文字は使わないでください。
• 開封追跡やクリック追跡を追加、提案、想定しないでください。
• 英語を母語としない人や技術に詳しくない人を対象にする場合は、平易な言葉を使います。これは語彙と文の長さに関するルールであり、文体の格式には関係しません。
• 気の利いた表現より、明快さを優先します。皮肉、過去の話題への言及、言葉遊び、読者のキャリアに関する所感は使いません。抽象名詞ではなく、誰が何をするのかを明記します。
• 読者の事業を理解していることを示します。専門家に自分の仕事について教えようとしないでください。
• スピンタックスは、ユーザー、クライアントのルール、または選択した送信ツールで必要な場合にのみ使います。スピンタックスのブロック内に差し込みフィールドを入れないでください。承認済みの主張を含む文は、バイト単位で変更しないでください。
• レビューの前に、機械生成らしさが出る表現を取り除きます。3項目の列挙、対称的な対比、自問自答、オチとして使う断片的な文、つなぎの冗語、憶測、禁止語を確認します。resources/ai-tropes.mdを参照してください。

証拠を十分に示す長めのコピーは、ユーザーが希望し、すべての根拠に出典がある場合に限り、150語まで使用できます。それ以外の理由で語数を増やしてはいけません。理由と例外の全容はresources/copy-rules.mdを参照してください。

個人ごとの冒頭文

入手できる根拠とクライアントのレビュー能力が十分な場合は、受信者ごとに生成した冒頭文を、クライアント承認済みの固定本文に続ける方法を基本とします。クライアントは本文を一度承認します。変更するのは冒頭文だけであり、そこに製品の主張を含めてはいけません。

2文で、35語以内にします。相手が具体的に何をしているかを述べ、そのすぐ後に課題を示します。役職名だけではなく、その人について実際に調査した情報をもとに作成します。専門家を対象にする場合、2文目は相手自身の業務について診断的な質問にすると効果的なことがよくあります。

使う前に、その根拠が冒頭文に適しているか判断します。すべての事実を個人向けの一文に使えるわけではありません。無理に個人向けにするより、使わないほうがよい場合もあります。「usable」、短い理由を1つ、冒頭文を返します。「usable」がfalseの場合は、承認済みのセグメント単位の冒頭文を使い、代替であることを示します。

各セグメントの業界に関する事実をモデルに渡します。事実を渡さずに具体的に書くよう求めると、モデルは具体的ながら誤った内容を生成します。パーソナライズの深さは、クライアントのレビュー能力に合わせます。何百もの個別の文を承認できない場合は、意味のあるセグメントごとに承認可能な冒頭文を1つ使います。

resources/personalized-openers.mdを参照してください。

シーケンスの構成

• メール1、基本的な背景。戦略と、今連絡する理由を伝えます。見込み客の課題や、その人を取り巻く状況の変化から始め、その後に切り口を示します。
• メール2、プラットフォーム。最初のきっかけ以外に製品が何をするのか、また読者の仕事をどう変えるのかを説明します。内容を付け加える形にします。
• メール3、締めくくりまたは適切な担当者への転送。事実に即した最後の連絡として、有用な次のステップを提案するか、適切な担当者を尋ねます。根拠のない緊急性を作り出さないでください。

2通構成のバリエーションと記入例については、resources/sequence-structures.mdを使用してください。承認済みのキャンペーン手法についてはresources/campaign-patterns.md、架空の複合例についてはresources/exemplars.mdを使用してください。

受信者が意思決定者でない場合は、その人が担当する課題に向けて書きます。CTAは適切な担当者を尋ねるもの1つにします。セグメント分けに必要な事実が得られない場合は、推測をパーソナライズのように見せるのではなく、読者に特定してもらいます。

件名はresources/subject-lines.mdを参考に選びます。

返信への回答

返信は別のジャンルとして扱います。最初の行で質問に正確に答え、内容のある段落を1つ加え、見込み顧客の意図に合った次のアクションを1つ提案します。返信文にはシーケンスの語数制限はなく、スピンタックスは使いません。成果物または承認済みの配信情報が作業コンテキストにない限り、資料を添付、リンク、送信、または予定したとは決して言わないでください。情報が不足している場合は、insufficient_contextを返し、見込み顧客向けの文案とは別に、妨げとなっている要因を示します。resources/reply-copy.mdを参照してください。

下書きとレビューのワークフロー

ワークフロー全体を通して、正本となる下書きを1つ維持します。

1. 承認済みのコンテキストから、戦略ブリーフと正本となる下書きを作成します。
2. resources/ai-tropes.mdに記載された機械的なチェックを実行します。行ごとの文案を生成する場合は、不合格となった理由を踏まえて再生成します。失敗したプロンプトを手作業の編集で隠してはいけません。
3. resources/prospect-reviewer.mdを使って、見込み顧客への明確さを確認します。
4. resources/client-voice-reviewer.mdを使って、クライアントの声と要件を確認します。
5. resources/research-reviewer.mdを使って、調査と事実の裏付けを確認します。
6. resources/coldiq-copy-reviewer.mdを使って、ColdIQのコピー基準を確認します。
7. 見込み顧客、クライアント、調査、ColdIQの基準の順に修正します。
8. 最後にresources/qc-reviewer.mdを使ってQCを実行します。
9. QCに不合格となった場合は、1回修正し、最終QCチェックを1回実行します。
10. 2回目のQCチェックにも不合格となった場合は、妨げとなっている要因とともにneeds_human_reviewを返します。

ホストがサブエージェントを起動できる場合は、4人の専門レビュアーを独立したタスクとして実行します。所見の調整と正本となる下書きの修正が済んでから、QCを開始します。ホストから実際のタスクIDが提供された場合は、それを含めます。ネイティブのレビュアーが失敗した場合は、1回再試行します。再試行も失敗した場合は、incomplete_reviewを返し、未実施のレビューを明記します。「Review mode: native-subagent-review」と報告します。

ホストがサブエージェントを起動できない場合は、同じ4つの評価基準で、簡潔なラベル付きレビューを行います。その後、修正してQCを実行します。別々のエージェントが実行したと主張してはいけません。「Review mode: single-agent-review」と報告します。

各レビュアーの所見は最大5件に制限します。各所見は、箇所、問題、提案する変更を含む短い文1つにします。下書きからの引用は12語以内にしてください。レビュアーの出力で下書きを繰り返してはいけません。最終的なコピーは1回だけ提示します。

成果物

以下を返します。

1. 戦略ブリーフ。
2. 実際のレビューモード。
3. ステータス：complete、insufficient_context、incomplete_review、またはneeds_human_review。
4. 4人のレビュアーとQCの簡潔なレビュー要約。
5. 最終的な件名とコピーを1回だけ。
6. コピーに事実に関する主張が含まれる場合は、簡潔なファクト台帳。
7. 個人やセグメントによって冒頭文が異なる場合は、パーソナライズの網羅状況と代替案。

特に指定がなければMarkdownで返します。ホストがファイルに対応しており、ユーザーが希望した場合に限り、DOCXを作成します。クライアントに提出する文書では、キャンペーンのメタデータから始め、承認済みのコピーとバリエーションを示し、クライアントが回答する必要のある質問だけを列挙して、内部プロセスに関する説明は削除します。すべての冒頭文のタイプについて、根拠となる情報源とともに例を示します。内部の誤りを解決するようクライアントに求めてはいけません。

非公開のキャンペーン情報を漏らしてはいけません。公開できる内容は、プロセスルール、規範的な制限、新たに作成した架空の例です。実測したキャンペーン合計、返信率、コンバージョンの向上率、クライアントの身元、クライアントの成果、ローンチ結果、実際のクライアント用コピー、またはいずれか1社のクライアントから得た事実を公開してはいけません。