Founder-led first revenue — 対象選定、接触、discovery、失注学習を有償商談へつなぐ

最終確認: 2026-08-02
対象: 狭い日本 B2B 市場で、最初の再現可能な顧客接点と有償商談を作る個人開発者

この章は、顧客開発・営業・計測の運用設計であり、法律、プライバシー、プラットフォーム規約、メール配信、契約の個別助言ではない。販売地域、宛先、取得経路、既存関係、目的、内容、利用サービスによって結論が変わる。送信直前に最新の一次情報と専門家を確認し、判断不能を PASS に変えない。

本章と companion に現れる会社、役割、文面、ID、件数、比率、時間、金額、期日は完全な架空例である。市場 benchmark、法的基準、到達ノルマ、推奨返信率ではない。実際の送信先や個人データを公開テンプレート、生成 AI、公開 SQL へ貼らない。

この章の役割

この章は、候補市場を選んだ後から、11 章へ Qualified opportunity を渡す直前までの正本である。

Segment contract
→ Account + trigger evidence
→ Contact provenance + contactability review
→ Message + claim version
→ Attempt + delivery
→ Reply + meeting
→ Discovery evidence
→ Qualified handoff / Lost / Nurture / Stop

既存章とは次のように責任を分ける。

問い	正本
誰のどの問題を選び、何を反証するか	01 章
ポジショニング、チャネル、SEO、紹介、継続までの全体像	04 章
現行法、privacy、security、利用規約の確認	06 章
日本の狭い業務候補、支払者、安全境界	08 章
cash CAC、創業者時間込み CAC、獲得容量	09 章
platform、所有チャネル、agent 委任	10 章
Qualified 後の相互計画、提案、契約、有償 pilot、更新	11 章
対象選定から discovery evidence までの取得・接触・結果の証拠	本章
コピーして使う書式	Founder-led acquisition pack
粒度、不変条件、cutoff 集計を動かす	SQLite companion

先に結論

1. 「営業件数」ではなく、対象が正しいこと、今連絡する理由、連絡可能性、相手の反応、問題の実在を順に証拠化する。
2. 会社、担当候補、接触 attempt、thread、reply、meeting、商談は別の粒度である。率を出す前に分母を名前で固定する。
3. 公開アドレス、名刺、紹介、問い合わせフォームは同じ許可ではない。contact × channel × purpose × sender × reviewed_at ごとに PASS / STOP / UNKNOWN を残す。
4. No reply、bounce、wrong person、explicit no、not now、problem absent、no authority、legal stop を一つの「失注」にしない。
5. 返信率や「50 件送る」を普遍的 benchmark にしない。segment、batch、message version、観測期限、反証条件を先に固定し、自分の結果だけで次を決める。
6. AI は公開根拠の整理、fact と hypothesis の分離、draft、分類候補までに使う。人の属性推定、無許可収集、宛先・内容・時刻の自律選択、追送、retry、抑止解除、成果主張を委任しない。外部 action は人が固定した one-shot tuple の実行だけに狭める。
7. Qualified は好感触ではない。直近業務、現在手順、影響、再発、関係者、購入経路、安全性、次行動の evidence package を 11 章へ渡す。
8. 失注の価値は件数ではなく、次の segment / trigger / message / offer / proof / channel のどれを変えるべきか特定できることにある。

一つの stage に全部を入れない

八つの粒度

Entity	一行が表すもの	混ぜると起きる誤り
segment_contract	特定期間の対象・除外・仮説・打切り条件	対象を途中で変えて成功扱いする
account	一つの顧客組織	担当者 3 人を顧客 3 社と数える
contact	一つの役割候補と一つの連絡経路	同じ人への複数送信を新規接点と数える
message_version	同じ claim と CTA を持つ一版	成果のよい文面だけ後から選ぶ
contact_attempt	一 contact へ一 channel で一回試みた event	送信、到達、開封、返信を同一視する
reply_thread	会話のまとまり	返信 3 通を見込み客 3 人と数える
meeting	予定または実施した一回	予約を実施済み面談と数える
opportunity	一つの購入 motion	discovery の好意を受注と数える

account_id を親にし、contact_id、attempt_id、thread_id、meeting_id、opportunity_id を分ける。表示名やメールアドレスを集計キーにせず、CRM 内の権限制御された ID を使う。

Event の二時刻と snapshot の二時刻

各 event と各 metric snapshot で、最低限次を分ける。

• occurred_at: 現実に起きた時刻
• recorded_at: 台帳へ取り込まれた時刻
• outcome_cutoff_at: その snapshot で outcome が起きてよい最終時刻
• snapshot_as_of: その snapshot が知り得た event の取込最終時刻

snapshot に含める基本条件は occurred_at <= outcome_cutoff_at AND recorded_at <= snapshot_as_of である。返信だけでなく delivery、complaint、suppression、meeting status に同じ二時計を使う。within_cutoff / after_cutoff / late_known は event の固定属性ではなく snapshot ごとの導出値である。7 月 31 日の判断へ 8 月 2 日に知った event を逆流させず、後日 restatement する場合も元 snapshot を上書きしない。

recorded_at の新しさを業務状態の新しさにしない。provider/source の revision、causal sequence、supersedes_event_id を ingestion 順と別に持ち、両 cutoff 内で有効な terminal supersession chain から状態を導出する。遅着した古い accepted が hard bounce を戻したり、古い scheduled が held/cancelled を戻したりしてはならない。信頼できる順序を復元できない場合は UNKNOWN とする。

Segment contract を送信前に凍結する

「日本の中小企業」は segment ではない。少なくとも次を同じ版に固定する。

segment_id / version:
対象業種、規模、地域:
対象 workflow と困る瞬間:
利用者 / 業務責任者 / 支払者の仮説:
今期の inclusion / exclusion:
観測可能な trigger:
現在手段と既知の代替:
提案する一成果 / 明示する対象外:
主 channel / 補助 channel:
cohort 開始 / outcome cutoff / snapshot as-of / decision date:
account 上限 / contact 上限 / attempt 上限:
最大創業者時間 / 最大現金:
今回変える一変数:
支持条件 / 反証条件 / 中止条件:

上限は成功法則ではなく、本人の損失上限である。母数が少なければ率の精度は低い。だからこそ、都合のよい account を追加したり、反応のない相手を分母から消したりしない。

Eligible と selected を分ける

• eligible: contract の inclusion を満たし、exclusion に該当しない。
• selected: 今回の上限内で実際に調べる対象へ入れた。
• contactable: その contact・channel・目的について送信 gate が PASS。
• attempted: 実際に接触 event が起きた。

選びやすい会社だけを eligible と呼ばない。eligible pool を全件作れない場合は、sampling frame、発見経路、取りこぼしを記す。紹介だけの cohort と公開情報から選んだ cohort は到達可能性が違うため混ぜない。

Account は「今この会社で起きていること」から選ぶ

Trigger evidence card

会社属性だけでは、なぜ今連絡するのか分からない。各 account に、公開または許諾された根拠と不確実性を一つ以上持つ。

Field	内容
trigger_type	採用、拠点追加、制度変更、求人記載、公開成果物、導入変更等
observed_fact	原資料から直接確認できた短い事実
source_ref	URL、公開資料 ID、紹介者許諾 ID 等
observed_at / valid_until	観測日と鮮度期限
problem_hypothesis	その fact から推測する workflow 上の困りごと
disconfirming_evidence	仮説を弱める事実
allowed_claim	初回文面で事実として言える最小範囲

採用中 → 人手不足 → 自動化ニーズ → 買う は四段の推論であり、事実ではない。文面では「求人に X の業務が記載されていた」までを fact とし、「この処理が負担か」を質問にする。

Account score は送信許可ではない

痛み、反復、支払者、到達可能性、安全性で優先順位を付けても、連絡可能性は別 gate である。高得点の account に STOP を上書きして送ってはいけない。低得点でも既存関係があるという理由だけで市場証拠へ昇格させない。

Contact provenance と contactability を fail-closed にする

連絡先の由来を記録する

最低限、次を持つ。

contact_id / account_id / role_code:
channel: email | phone | form | platform_message | referral | event | other
source_type: direct_consent | business_card | public_business_address |
             existing_relationship | referral_permission |
             permissioned_platform | purchased | scraped | unknown
source_ref / captured_at / source_snapshot_hash:
address_owner: organization | role | natural_person | unknown
intended_purpose:
privacy_notice_version / retention_due_at:

氏名、直アドレス、電話番号、私的 SNS、推定属性、自由記述を公開 pack や Codex prompt に入れない。実 CRM でも最小化、権限、保持、利用停止を設計する。

日本法について安全に言える範囲

消費者庁が掲載する特定電子メール法ガイドラインでは、営業の広告・宣伝を手段とするメールを対象とし、原則は事前同意である。同時に、取引関係、一定の方法で通知されたアドレス、Web 上で自ら公開した団体・営業個人のアドレス等には例外がある。ただし、公開アドレスの近くに広告・宣伝メールを拒否する表示がある場合、その公開例外には当たらない。拒否通知を受けた後は、その意思に反した送信をしてはならない。

同資料の表示例では、少なくとも送信者の氏名・名称、受信拒否を通知できる旨、その通知先メールアドレスまたは URL に加え、送信者の住所と苦情・問合せ先も確認対象になる。一部をリンク先へ表示できる場合があっても、「本文に配信停止リンクだけあれば十分」とは扱わない。どの表示と同意記録が今回の送信に必要かは、特定商取引法等の重なる規律も分けて review する。消費者庁・総務省 特定電子メールの送信等に関するガイドライン / 特定電子メール法のポイント

個人情報保護委員会は、名刺交換の状況から自社広告の予測可能性がある場合を説明する一方、特定電子メール法等も別に守る必要があるとしている。また、利用目的は本人が合理的に予測できる程度に特定し、ダイレクトメール停止要求は適切・迅速に処理すべきとしている。公開されている情報も個人情報保護法の対象から自動的に外れない。PPC 個人情報保護法 Q&A / PPC 通則編

したがって、次を一般則にしない。

• Web にあるから送信可
• B2B だから規制対象外
• 調査と書けば広告ではない
• 一度名刺交換したから全製品を永久に案内可
• 配信停止リンクを付ければ無許可送信可
• 購入リストだから取得元が保証済み

Contactability review

一行の粒度は contact × channel × purpose × sender × review_version とする。

Field	内容
result	PASS / STOP / UNKNOWN
legal_basis_candidate	consent、public business address、existing relationship 等の候補。法的結論そのものではない
recipient / sender / purpose / content	今回の実体
source evidence	取得元、取得時刻、表示、拒否文言の snapshot
privacy purpose	特定・通知・公表の根拠
channel terms	問合せフォーム、SNS、directory 等の規約・用途
required display	送信者名、拒否通知の案内と宛先、送信者住所、苦情・問合せ先等の適用確認
consent / exception record	同意または例外候補の証拠、適用する保存期間、正本の保管先
suppression check	contact、account、domain、全体の拒否履歴
reviewer / reviewed_at / valid_until	人、時刻、再確認期限
recheck trigger	表示変更、目的変更、別製品、別 channel、関係終了等

UNKNOWN は送信不可である。法令例外の候補を Codex が見つけても、人が exact source と文面を確認するまで PASS にしない。フォームや platform message はメール法だけでなく、その窓口の目的と規約を確認する。

Suppression は最優先の共有状態

拒否、苦情、spam report、法務停止、hard bounce、誤宛先を append-only event として残す。送信ツール、CRM、手動メール、代理店、別 campaign の全てが同じ抑止状態を見る。

STOP > PAUSE > UNKNOWN > READY

• STOP: explicit opt-out、実際の complaint / spam report、hard bounce、誤宛先、法務停止、規約禁止、禁止 claim。exact contact/channel か、意思表示・規律が及ぶより広い scope に適用する。
• PAUSE: soft bounce、deferred、未確認の provider alert、contact 有効性調査、attempt 上限、明示した再開条件待ち。
• UNKNOWN: review 欠損・期限切れ、取得元不明、目的不一致、規約未確認。
• READY: 上位状態がなく、trigger、contactability、message、送信基盤が全て有効。

抑止 event は contact/account/domain/all × channel/all × purpose/product/sender/all × effective_at の scope を持つ。hard bounce を無関係な domain 全体へ自動拡張せず、逆に account-level の明示拒否を別 contact で迂回しない。scope が不明なら UNKNOWN として人が確認する。

verified opt-out、complaint/spam report、hard bounce、wrong recipient、legal stop の STOP は自動失効させない。解除は、人が新しい根拠を確認し、同じ immutable scope stream の active event 一件を exact ID で supersede する RELEASE event にする。一件の release で重なる account/domain/all scope を消さず、active suppression を全て再評価する。自動期限を持てるのは、soft bounce、deferred、未確認 alert、attempt cap 等の PAUSE だけである。

Message と claim を version 固定する

初回文面の仕事

初回文面は契約を取る文書ではない。相手が次のどれかを低負担で返せるようにする。

• 仮説が違う
• 担当が違う
• 今ではない
• 直近例を話せる
• 公開資料だけ見てほしい
• 今後の連絡を止めてほしい

件名: [公開された具体的業務]について確認

[source]で[観測した fact]を拝見しました。
[対象 workflow]では、[具体的な例外/手戻り]が起きるのでは、という仮説を調べています。

実際には、現在どのように確認されていますか。
もし担当外でしたら、その旨だけで大丈夫です。今後の案内が不要な場合もお知らせください。

[実在する送信者名 / 所属 / 連絡先 / 必要な表示]

「同業で 30% 改善」は、同じ定義、比較期間、母数、顧客許諾を示せなければ使わない。顧客名を伏せても、成果の存在を捏造してよいわけではない。

Claim ledger

文面の一主張を一行にする。

Claim class	例	必須 evidence
observed_fact	公開資料に月次報告工程が記載	source snapshot、観測時刻
customer_problem_hypothesis	集計差戻しが負担かもしれない	hypothesis と明記。fact 化しない
own_capability	sample を手動で一件作れる	現在の提供範囲、期限、制約
measured_outcome	処理時間が短縮した	cohort、baseline、測定法、許諾
third_party_fact	制度が特定日に変わった	現行一次情報、適用範囲
offer_term	有償 pilot の価格・範囲	現行 offer version

message_version は subject、body、CTA、offer、claim IDs、対象 segment、承認日、廃止日を固定する。生成文を contact ごとに変える場合も、どの fact を差し込んだかと最終 human approval を保存する。

「パーソナライズ」を魔法にしない

Sahni らの大規模 field experiment では、既存の consumer email campaigns で件名への名前追加が open と lead に影響した。しかし、これは日本 B2B の未承諾 outbound、問題 trigger、商談化の普遍的因果を示さない。Sahni, Wheeler & Chintagunta, 2018

名前や褒め言葉を差し込むことより、次を検証する。

• なぜこの account かが fact で説明できる
• なぜ今かが trigger とつながる
• 質問が一つで答えられる
• 仮説であることが分かる
• 合わない、担当外、停止の出口がある

研究の効果量を返信率 benchmark に転用せず、自分の eligible cohort で再検証する。

送信基盤は「届いたはず」を作らない

Gmail は個人 Gmail 宛の全送信者に SPF または DKIM、TLS、DNS、RFC 準拠等を求め、1 日約 5,000 通以上の bulk sender には SPF、DKIM、DMARC alignment、marketing mail の one-click unsubscribe 等を追加で求める。bulk sender 判定は primary domain 単位で、一度該当すると恒久扱いとする FAQ もある。Google Email sender guidelines / Google FAQ

Yahoo の Sender Hub も、全送信者と bulk sender の認証・DNS・苦情率・unsubscribe 要件を分け、bulk の固定件数閾値は公表しない。また Yahoo Japan は別主体であり、同 FAQ は Yahoo Japan の方針を代弁しない。Yahoo Sender Requirements / Yahoo FAQ

これらは大量送信へ近づく目標ではない。少量の個別送信でも、少なくとも次を行う。

• 自分が管理する domain で SPF、DKIM、DMARC と送信 provider を確認する。
• marketing と transactional の stream、From、権限を分ける。
• SMTP response、bounce、complaint、unsubscribe を event として取り込む。
• hard bounce、拒否、苦情を再送リストへ戻さない。
• volume を急増させず、provider の最新規則と rate limit を確認する。
• open pixel は privacy・精度・client 制限があるため、open を人間の閲読や価値とみなさない。

送信 accepted、delivery 推定、inbox 到達、閲読、理解、返信は別である。通常取得できるのは provider event の一部だけなので、不明を delivered に変えない。

Attempt、delivery、reply を append-only にする

Attempt event

以下の機械実行 contract は v1 として email だけを扱う。phone、form、platform message、referral、event は、同じ contactability review を入口にしても、用途規約、同意、実行 receipt、停止方法が違う。email の authentication、provider delivery、bounce 欄を PASS に流用せず、channel 固有 contract がなければ人による action も UNKNOWN で止める。

attempt_id / batch_id / account_id / contact_id:
channel / message_version / claim_set_hash:
segment_contract_hash / selection_evidence_id:
contactability_review_id / trigger_evidence_id:
sequence_within_contact:
occurred_at / recorded_at:
send_approval_id / human_approved_by / approved_at / approval_expires_at:
single_use_idempotency_key / execution_claimed_at:
preflight_at / suppression_watermark:
provider_message_ref_hash:

送信前 trigger は最低限、次を拒否する。

• account が matching contract で eligible かつ selected でない、または contract hash が違う
• current review が PASS でない、期限切れ、purpose が違う
• current suppression が active
• message が draft、retired、claim が STOP / UNKNOWN
• trigger が期限切れ、source が失われた
• batch または contact の事前 attempt 上限を超える
• hard bounce、legal stop、account-level explicit no の後
• event 時刻が判断時点より未来

承認時の suppression check だけでは足りない。executor は送信直前の一つの local transaction で、current contract、eligible/selected、review、最新 suppression watermark、attempt 上限、approval expiry を再確認し、未使用の idempotency key を AUTHORIZED → EXECUTING へ一度だけ遷移させる。その後 provider を呼び、receipt を照合する。timeout や crash で結果が UNKNOWN のときは自動 retry せず、同じ provider idempotency key と履歴を照合してから人が決める。承認後に入った opt-out や complaint を、古い check で追い越してはならない。

Delivery event

accepted / delivered_signal / soft_bounce / hard_bounce / deferred / rejected / unknown を分ける。provider の delivered は一般に inbox 閲読の証拠ではない。delivery の causal chain と、complaint、spam report、unsubscribe 等の recipient/provider feedback stream は分け、配信後の complaint で delivery 事実を消さない。一方で terminal hard bounce や適用 scope の STOP を、遅着した古い benign event で戻さない。

Reply outcome

返信本文を分析台帳へ複製せず、権限管理された原文への ID と、人が確認した分類を残す。

Outcome	意味	次の扱い
positive	直近例を話す意思がある	meeting または質問を明示
question	情報不足	一問へ回答。勝手に positive 化しない
referral	別担当を示した	新 contact の provenance と review を作る
wrong_person	担当外	account 仮説は未反証、contact は終了
explicit_no	提案を拒否	scope を確認し suppression へ反映
not_now	時期が違う	restart trigger と日付があるときだけ nurture
problem_absent	想定問題がない	segment/trigger 仮説の反証
no_authority	利用者だが購入経路がない	stakeholder 仮説を修正
legal_stop	規制・規約・権利上停止	即 STOP、人が review
other / unknown	分類不能	原文確認まで positive にしない

No reply は reply event ではない。同じ metric snapshot に含まれる attempt があり、同じ二時計で human reply がない account/contact として導出する。無反応を CRM から消したり、暗黙の拒否・関心へ読み替えたりしない。

Follow-up は上限と停止条件を先に置く

普遍的な最適回数や間隔はない。batch contract に次を入力する。

• contact ごとの最大 attempt
• 最小間隔
• account ごとの最大 contact
• 最終日
• 追送する新情報の条件
• bounce、拒否、苦情、規約変更時の即時停止

「返信がないから同じ文面を送る」は新しい学習を生まない。新しい trigger、質問への有用な回答、相手が求めた資料等がなければ、上限前でも終了できる。AI に cadence を自動実行させない。

Discovery は意見収集でなく直近業務の証拠化

面談前

1. trigger fact と problem hypothesis を分離する。
2. 売りたい機能ではなく、直近の一件を聞く質問を作る。
3. 録音、文字起こし、生成 AI 利用の許可と保管方針を確認する。
4. 面談の目的、時間、販売へ移る条件を相手へ明示する。

面談の scheduled / held / cancelled / no-show と、録音・文字起こし・AI 処理の authorization / actual use / artifact / retention / deletion は別 stream にする。許可・法的根拠・privacy notice・顧客方針の適用確認が PASS でない限り、録音開始、transcript 作成、外部 AI provider への送信を行わない。拒否・撤回後は新しい処理を止め、既存 artifact の保存・削除・例外は根拠と scope を人が確認して event 化する。

面談中

順序は次を基本にする。

1. 最後にその業務が起きた日時ときっかけ
2. 入力から完了までの人、手順、tool、待ち
3. 例外、差戻し、やり直し、確認
4. 時間、現金、遅延、品質、risk の実際の影響
5. 何もしなかった場合と現在の代替
6. 次の発生日、優先度が変わる trigger
7. 利用者、責任者、購入者、security・法務・経理
8. 安全に試せる data、権限、対象外
9. 相手と自分の期限付き次行動

誘導質問を避ける。

避ける	代わりに聞く
この自動化があれば使いますか	前回はどう処理しましたか
月 1 万円なら払いますか	現在、誰の何時間・何費用が発生しましたか
AI 要約は便利ですか	どの判断で原文へ戻り、誰が承認しますか
これが一番の課題ですか	直近 3 件の中で何を先に直しましたか

将来の好意的意向より、過去の行動、現在の支出、次の実業務、具体的な約束を強い evidence とする。ただし、過去の一例だけで市場全体へ外挿しない。

Discovery evidence の最小 package

account_id / meeting_id / outcome_cutoff / snapshot_as_of:
recent_workflow_example:
current_alternative:
impact_baseline + unit + period:
recurrence / next_occurrence:
user / process_owner / value_decider:
buyer / budget_path / signature path:
data / permission / safety feasibility:
standard_scope_fit / exclusions:
disconfirming evidence:
customer next action + due_at:
founder next action + due_at:
source quote refs / reviewer / confidence:

原文、解釈、推論を別欄にする。AI 要約だけを source にせず、reviewer が原文へ戻れるようにする。

Qualified handoff を明示する

本章の終点は、11 章の 9 条件へ対応する evidence package と、新しい opportunity_id である。

acquisition_account_id:
source_batch_id / first_touch_source / assist_touch_ids:
discovery_evidence_ids:
qualification requirement → evidence ID / confirmed / unknown / refuted:
disconfirming evidence:
proposed motion: pilot | production
opportunity_id:
mutual next step / customer owner / founder owner / due_at:
pre-Qualified cash spend / founder minutes / fully-loaded cost to Qualified:
handoff reviewed_by / reviewed_at / package_hash:

Qualified に不足があれば UNKNOWN または CONTINUE である。meeting 実施、デモ希望、価格質問、強い共感の一つだけでは Qualified にしない。handoff 後も acquisition source は履歴として残すが、契約、invoice、payment、pilot outcome は 11 章の正本へ移す。

Lost と Nurture を学習へ変える

Loss reason は一つの観測主因を選ぶ

Loss / pause reason	主に再検討するもの	してはいけない短絡
problem_absent	segment / trigger	コピーだけを派手にする
low_impact	problem / value unit	根拠なく値下げする
wrong_timing	trigger / channel timing	永久 nurture に置く
wrong_person	role / provenance	account 全体を失注にする
no_purchase_path	segment / stakeholder / offer	利用者の好意を forecast にする
scope_mismatch	offer / standard boundary	無料個別開発で埋める
trust_or_proof	proof / risk reversal	架空実績を足す
security_privacy_legal	segment / data / offer	objection handling で押し切る
price_value_mismatch	value evidence / price metric	一件だけで全価格を変える
channel_rejection	channel / contactability	別 contact へ迂回する

decision_reason → change_domain → next hypothesis → owner → due_at を一組にする。全てを同時に変えると原因が分からない。

Nurture の条件

Nurture は「いつか買うかも」ではない。次が全て必要である。

• 再開 trigger
• 最早再開日または decision date
• 再開してよい channel と contactability review
• 相手が期待する価値ある更新
• owner

いずれかがなければ Lost または Unknown とし、active forecast から外す。nurture も suppression より優先されない。

Funnel は三つの分母で別々に読む

Account-weighted

市場と商業 motion を見る。

account contact rate = attempted distinct accounts / eligible selected accounts
account reply rate = replied distinct accounts / attempted distinct accounts
account discovery rate = discovery-evidenced accounts / attempted distinct accounts
account qualification rate = qualified accounts / attempted distinct accounts

Contact-weighted

役割仮説と到達経路を見る。

contact attempt rate = attempted contacts / reviewed contactable contacts
contact reply rate = replied contacts / attempted contacts
wrong-person rate = wrong-person contacts / replied contacts

Attempt-weighted

配信と cadence を見る。

accepted rate = accepted attempts / attempted sends
hard-bounce rate = hard-bounced attempts / attempted sends
reply-per-attempt = replied attempts / attempted sends

三つを一つの conversion rate にしない。同じ account の 3 contacts、同じ contact の 3 attempts があれば値は変わる。小標本では率とともに numerator / denominator、account list、confidence の限界を示す。

必ず併記する数

• eligible だが未選定
• selected だが contact 不明
• review STOP / UNKNOWN
• attempted だが cutoff まで no reply
• soft/hard bounce、deferred、delivery unknown
• reply はあるが分類 unknown
• scheduled / held / no-show meeting
• discovery evidence あり / なし
• reply、delivery、feedback、suppression、meeting status の after-cutoff / late-known
• CONTINUE / PAUSE / Qualified / Lost / Nurture / STOP / UNKNOWN

No reply を分母から除いた「返信者のうち positive」は、獲得能力を表さない。

Attribution は事実の順序だけを保存する

最初に account を観測した first_touch_source は一つに固定する。その後、返信や面談に影響し得た assist_touch は複数残す。恣意的な 40/30/30 等の配賦で小標本を精密に見せない。

first touch: directory_public at t1
assist: peer_intro at t2
attempt: founder_email at t3
reply: t4

これは peer_intro が 30% 貢献 と証明しない。source 別 CAC を出すときは、事前に決めた attribution rule、lookback、対象 motion、除外を version 化する。別 rule の結果を横並びにし、都合のよい rule だけ採用しない。

Qualified までの費用と CAC を混ぜない

09 章の内部時間価値へ接続する。

pre-Qualified cash spend
= list/data/tool fee + event/partner fee + send cost + acquisition travel 等

pre-Qualified founder minutes
= research minutes + review minutes + writing minutes + sending minutes
 + reply handling + meeting + follow-up + CRM/review

pre-Qualified founder-time cost
= pre-Qualified founder minutes / 60 × internal hourly value

fully-loaded cost to Qualified
= pre-Qualified cash spend + pre-Qualified founder-time cost

fully-loaded cost per Qualified
= fully-loaded cost to Qualified / Qualified accounts

Qualified は顧客獲得ではないため、この値を CAC と呼ばない。本章では Qualified までの cash と minutes を測る。成熟後の CAC は outcome definition を version 固定し、contract_effective、first_cash_received、paid_in_full を別々に表示する。これらを一つの cash-received へ潰さない。

各 CAC は、同じ cohort の pre-Qualified ledger に、11 章の提案、redline、security、vendor 登録、購買・法務対応等の post-Qualified cost event と、選んだ exact outcome event を join し、09 章の境界で一度だけ計上して初めて出す。未成熟 cohort をゼロ CAC や無限 CAC と表示せず IMMATURE / NO_OUTCOME / UNKNOWN とする。

外注、購入リスト、AI enrichment は現金だけでなく、重複除去、誤情報確認、法務、苦情、rework の創業者時間を含める。自分の面談時間を無料としない。

小さな batch で学ぶ

Experiment card

experiment_id / batch_id:
segment and sampling frame:
unit of assignment: account | contact
control / treatment message versions:
変える一要素:
primary outcome and exact denominator:
guardrails: complaint / suppression / bounce / legal stop / time / cash
start / cutoff / maturity date:
maximum accounts / contacts / attempts:
minimum practically useful effect:
analysis rule / missing / late event rule:
stop / continue / inconclusive rule:

account の複数 contacts を別 variant へ割り付けると相互汚染するため、通常は account 単位で割り付ける。返信が来るまで何度も結果を見て、良い時点で止めた比較を確証と呼ばない。標本が小さいときは、効果量の精密推定より、明白な STOP、強い反証、運用上の欠損を見つける。

観測から導く順序

1. Gate 違反、苦情、誤送信、重複、future leakage がないか。
2. Sampling frame と分母が壊れていないか。
3. Bounce、wrong person、no reply、meeting no-show のどこで止まるか。
4. 顧客原文に共通する事実と反証は何か。
5. 次に変える一 domain は何か。
6. 追加 batch の最大損失を許容できるか。

有意差がないことを「同じ」と断定しない。差が見えない、観測力が足りない、実務上差が小さいを分ける。

三つの完全架空例

以下は 08 章の業務候補を使った書き方例であり、実在企業、法的送信許可、需要、返信率を示さない。

例 1 — 広告・制作会社の月次クローズ

Observed fact:
  公開採用ページに、複数媒体の月次レポート集計と顧客説明資料作成が記載。
Hypothesis:
  媒体差分と修正履歴の確認が月末に集中するかもしれない。
Safe question:
  前回の月次締めで、数値差分はどの段階で誰が確認しましたか。
Disconfirming answer:
  既に一つの基盤へ統合され、差戻しも発生していない。
Change if repeated:
  この trigger を segment inclusion から外す。

例 2 — 専門工事会社の追加工事証拠

Observed fact:
  公開施工事例に、現場写真と追加工事項目が掲載。
Hypothesis:
  指示、写真、見積版、承認が別経路になり回収漏れが起きるかもしれない。
Safe question:
  直近の追加工事一件は、指示から請求可否の確認まで何を照合しましたか。
Stop boundary:
  公開窓口に営業連絡拒否、または個別 review が UNKNOWN。
Qualified evidence:
  次の実案件、現行手順、未回収の基準、業務 owner、購入経路、安全な sample が確認済み。

例 3 — 税理士向け月次説明 pack

Observed fact:
  事務所サイトが月次試算表と経営説明を明示。
Hypothesis:
  根拠資料から説明差分を作る review が担当者依存かもしれない。
Safe question:
  前回、顧客への説明前にどの数字へ戻って確認しましたか。
Scope boundary:
  税務判断、申告、無検証 AI 出力を置換しない。
Loss learning:
  explanation は標準化済みだが資料回収が問題なら、offer を変えるか segment を外す。

架空例を成果実績として再利用しない。実際の文面は exact account、source、review、claim evidence を人が確認する。

Codex を使う安全な流れ

委任してよい

• 指定した公開ページから trigger candidate を抽出し、URL と引用位置を並べる
• fact、hypothesis、unknown、disconfirming evidence を分離する
• 承認済み message version から draft を作る
• reply outcome と loss reason の分類候補を理由付きで出す
• account/contact/attempt の重複候補を提示する
• cutoff-safe な funnel、time、cash 集計を再現する
• discovery note から未確認 requirement を列挙する

委任しない

• protected / sensitive attribute、健康、思想、家庭、財務等を推定して targeting する
• login、robots、規約、rate limit を回避して contact を収集する
• 私的 contact を enrichment する
• legal basis、規約適合、送信可否を自動確定する
• recipient、文面、送信時刻を human approval なしに決め、送信する
• suppression を解除する
• 顧客の発言、成果、導入社、統計を生成する
• no reply を positive、lost、nurture に自動変換する

classification へ raw reply や transcript を渡す前に、data class、redaction、利用可能な model/provider、region/retention、目的、顧客方針を人が確認する。出力は許可された label set の候補に限定し、人が原文と照合するまで UNKNOWN である。model 出力から suppression、Nurture、Lost、Qualified 等の state を直接変更しない。

二段階承認

Research approval:
  account / source / fact / hypothesis / retention / prohibited inference

Send approval:
  exact contact / channel / purpose / contactability review / latest suppression
  matching contract + eligible + selected / exact message hash / claims
  sender identity / stop method / exact send time / expiry / single-use idempotency

両者を一つの「AI が確認済み」にしない。既定は人が送信する。tool executor を使う場合も、人が固定した一宛先・一内容・一時刻の one-shot action だけに狭め、宛先選択、内容変更、追送判断、retry、抑止解除を許さない。送信前 preflight と single-use idempotency を通し、送信後の external receipt を取り込んで人が current state を review する。

週次 Acquisition review

順序を固定する。

1. STOP: 苦情、拒否後送信、誤送信、規約違反、禁止 claim、privacy/security incident。
2. PAUSE: bounce 急増、無効 contact、attempt 上限、review 期限切れ、容量超過。
3. UNKNOWN: source、contactability、delivery、reply 分類、discovery requirement の欠損。
4. 分母: eligible / selected / contactable / attempted を account、contact、attempt 別に照合。
5. Outcome: no reply、reply class、held meeting、discovery evidence、Qualified。
6. Economics: cash、founder minutes、Qualified/contracted/cash-received までの成熟。
7. Learning: 一つの change domain、次 batch の上限、owner、decision date。

STOP > PAUSE > UNKNOWN > READY_TO_DECIDE

一つでも上位状態があれば、良い返信や商談で相殺しない。READY_TO_DECIDE は成功ではなく、証拠が揃い、人が CONTINUE / CHANGE / QUALIFY / LOST を選べる状態である。

典型的な失敗

返信率だけを最適化する

議論を呼ぶ件名で返信は増えても、problem evidence や Qualified が増えるとは限らない。primary outcome を商業判断に近づけ、苦情と誤適格化を guardrail にする。

送信数を進捗にする

送信は activity で、顧客価値の証拠ではない。account selection、trigger、wrong person、no reply のどこに問題があるかを読む。

Account と contact を混ぜる

同じ会社の 5 人へ送り 1 人が返した結果を、5 社中 1 社の市場反応として扱わない。

「担当者を紹介してください」を許可の継承にする

紹介された contact について、新しい provenance、purpose、channel review を作る。紹介者の許可を本人の全目的同意へ拡張しない。

Open tracking を顧客関心にする

proxy、privacy protection、security scanner、画像 block により歪む。返信、面談、直近業務、次行動をより強い evidence にする。

AI personalization を大量送信機にする

一見固有な文を作れても、source が誤り、claim が過剰、相手の期待に反するなら risk を高速化する。AI が増やす前に review capacity と suppression propagation を測る。

Nurture を墓場にする

再開 trigger も日付もない案件を active と数えない。forecast、容量、CAC を歪める。

最小実装

最初は CRM の全面導入より、次の 10 表または sheet でよい。

1. segment/batch contract
2. account + trigger evidence
3. contact provenance
4. contactability review + suppression
5. message version + claim ledger
6. attempt + delivery
7. reply + meeting
8. discovery evidence
9. decision + Qualified handoff
10. time + cash cost

重要なのは append-only ID、cutoff、分母、fail-closed gate である。template packをコピーし、データモデルを確認したい場合は SQLite companionを disposable database で実行する。

今週の実行順

1. 08 章または自分の接点から一つの狭い workflow を選ぶ。
2. segment contract と反証条件を一版作る。
3. 上限内の account を作り、各社で fact と hypothesis を分ける。
4. 送信せず、contact provenance と contactability を人が review する。
5. PASS の対象だけ message claim を確認し、exact send を承認する。
6. no reply と全 outcome を残し、held discovery では直近一件を聞く。
7. Qualified evidence が揃った account だけ 11 章へ渡す。
8. cutoff に分母、反証、時間、現金を照合し、次に変える一 domain を決める。

初回の成果は「大量に送れた」ことではない。誰へ、なぜ、どの根拠で接触し、何が反証され、どの evidence が有償商談へつながったかを再現できることである。