Skip to content

Instantly share code, notes, and snippets.

@esz135888
Created May 24, 2026 00:54
Show Gist options
  • Select an option

  • Save esz135888/92f61771a5dd05e73df400e131392404 to your computer and use it in GitHub Desktop.

Select an option

Save esz135888/92f61771a5dd05e73df400e131392404 to your computer and use it in GitHub Desktop.
PLS job 261b388a customer visit proposal pipeline production pack

Acceptance Tests

Human Acceptance

  1. 客戶成功窗口能在 15 分鐘內讀完作戰台並用腳本開場。
  2. 每場拜訪至少收回 1 個客戶 quote、1 個質疑點、1 個成功指標。
  3. 產品負責人能把內部能力改寫成 customer-language proof statement。
  4. CEO 決策窗口能用 readiness score 判斷是否進 proposal。

System Acceptance

  1. POST /customer-visits 建立 visit session 後,狀態為 planned
  2. 補滿 pain point + proof statement + next meeting commitment 後,可生成 proposal brief。
  3. 缺任一必填欄位時,readiness score 不得高於 60。
  4. proof statement 未 approved 時,不得進入 proposal_ready
  5. 每次 state change 都產生 audit log。

E2E Pass Criteria

  • D7 前完成 3 場拜訪實測。
  • 3/3 拜訪可生成 proposal brief draft。
  • 至少 2 句 proof statement 被產品負責人 approved。
  • 至少 1 場取得下一次會議或 proposal review 承諾。
<!doctype html>
<html lang="zh-Hant">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>客戶策略簡報與提案產線作戰台</title>
<style>
:root{--ink:#17201b;--muted:#637067;--line:#dbe2dd;--bg:#f6f7f2;--panel:#fff;--green:#216b55;--blue:#295f8a;--amber:#b87918;--red:#ad3d33;--soft:#edf3ee}
*{box-sizing:border-box} body{margin:0;background:var(--bg);color:var(--ink);font-family:Inter,ui-sans-serif,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",sans-serif;line-height:1.45}
header{padding:30px 36px 22px;background:#fff;border-bottom:1px solid var(--line)} h1,h2,h3{margin:0;letter-spacing:0} h1{font-size:28px;max-width:1100px} h2{font-size:17px;margin-bottom:12px} h3{font-size:14px;margin-bottom:8px}
p{margin:0;color:var(--muted)} .eyebrow{font-size:12px;font-weight:800;text-transform:uppercase;color:var(--green);margin-bottom:8px}
.wrap{padding:24px 36px 42px}.grid{display:grid;grid-template-columns:repeat(12,1fr);gap:16px;max-width:1280px;margin:0 auto}
.panel{background:var(--panel);border:1px solid var(--line);border-radius:8px;padding:18px;box-shadow:0 1px 2px rgba(0,0,0,.03)}
.span-12{grid-column:span 12}.span-8{grid-column:span 8}.span-6{grid-column:span 6}.span-4{grid-column:span 4}.span-3{grid-column:span 3}
.kpis{display:grid;grid-template-columns:repeat(4,1fr);gap:12px}.kpi{border:1px solid var(--line);border-radius:8px;padding:14px;min-height:92px;background:#fbfcf8}.kpi strong{display:block;font-size:28px}.kpi span{font-size:13px;color:var(--muted)}
table{width:100%;border-collapse:collapse;font-size:13px} th,td{text-align:left;padding:10px 8px;border-bottom:1px solid var(--line);vertical-align:top} th{font-size:12px;text-transform:uppercase;color:var(--muted);background:#fbfcf8}
.status{display:inline-flex;border-radius:999px;padding:4px 9px;font-size:12px;font-weight:800;white-space:nowrap}.green{background:#e1f0e8;color:var(--green)}.blue{background:#e4eef8;color:var(--blue)}.amber{background:#f7ecd9;color:#81530f}.red{background:#f9e6e3;color:var(--red)}
.timeline{display:grid;grid-template-columns:repeat(4,1fr);gap:12px}.stage{border-left:4px solid var(--green);background:#fbfcf8;padding:12px;border-radius:0 8px 8px 0;min-height:150px}.stage:nth-child(2){border-color:var(--amber)}.stage:nth-child(3){border-color:var(--blue)}.stage:nth-child(4){border-color:var(--red)}
.flow{display:grid;grid-template-columns:repeat(5,1fr);gap:10px}.step{border:1px solid var(--line);border-radius:8px;padding:12px;background:#fbfcf8;min-height:116px}.step b{display:block;margin-bottom:6px}.small{font-size:12px;color:var(--muted)}
ul{margin:8px 0 0 18px;padding:0;color:var(--muted)} li{margin:4px 0}.script{background:var(--soft);border-radius:8px;padding:12px;color:var(--ink);font-size:13px;white-space:pre-wrap}
.code{background:#16211b;color:#eaf2eb;border-radius:8px;padding:12px;font:12px ui-monospace,SFMono-Regular,Menlo,monospace;white-space:pre-wrap;overflow:auto}
@media(max-width:900px){header,.wrap{padding-left:18px;padding-right:18px}.span-8,.span-6,.span-4,.span-3{grid-column:span 12}.kpis,.timeline,.flow{grid-template-columns:1fr}}
</style>
</head>
<body>
<header>
<div class="eyebrow">PLS production artifact · customer strategy brief & proposal pipeline · 2026-05-24</div>
<h1>客戶策略簡報與提案產線作戰台</h1>
<p>把「產出第一版客戶拜訪腳本」升級成可直接採用的客戶拜訪、簡報、提案與驗收產線:誰負責、問什麼、收什麼資料、如何轉成提案、何時通過。</p>
</header>
<main class="wrap">
<section class="grid">
<div class="panel span-12"><div class="kpis">
<div class="kpi"><strong>D1</strong><span>可直接貼到會議的拜訪腳本</span></div>
<div class="kpi"><strong>5</strong><span>墨宇相關角色同步採用</span></div>
<div class="kpi"><strong>3</strong><span>必要資料:痛點、優勢、證據</span></div>
<div class="kpi"><strong>D30</strong><span>從腳本升級成提案產線 dashboard</span></div>
</div></div>
<div class="panel span-8">
<h2>客戶拜訪腳本 v1</h2>
<table>
<thead><tr><th>階段</th><th>主持人要說</th><th>必收資料</th><th>轉提案輸出</th></tr></thead>
<tbody>
<tr><td><span class="status green">開場定位</span></td><td>今天不是介紹功能,而是確認客戶現在卡在哪個業務成果,以及我們是否有足夠證據值得進下一步。</td><td>客戶目標、決策時程、參與角色</td><td>會議摘要與 buying group map</td></tr>
<tr><td><span class="status amber">痛點追問</span></td><td>上次對接裡,哪個環節讓你覺得「這跟其他供應商差不多」?如果要讓你願意推進,哪個證據最有用?</td><td>質疑點、未被說服原因、成功條件</td><td>痛點清單與 objection map</td></tr>
<tr><td><span class="status blue">優勢翻譯</span></td><td>我們先不用說比誰強,而是把能力翻成你們會感受到的業務結果:少花多少時間、降低哪個風險、提高哪個轉換。</td><td>可量化價值、案例證據、內部 champion 語言</td><td>三句 customer proof statement</td></tr>
<tr><td><span class="status red">下一步承諾</span></td><td>如果我們在 48 小時內補一版對應你們情境的 brief,你願意安排誰一起看?哪一個指標會決定是否進提案?</td><td>下一會議對象、驗收指標、資料缺口</td><td>提案 brief backlog 與 owner/due</td></tr>
</tbody>
</table>
</div>
<div class="panel span-4">
<h2>會前 15 分鐘 Checklist</h2>
<ul>
<li>確認客戶所屬 buying group:使用者、決策者、影響者、採購/法務。</li>
<li>準備 3 個不直接打競品、只講自身成果證明的優勢句。</li>
<li>準備 5 個 discovery 問題,避免一開始就 pitch。</li>
<li>指定會後 48 小時 proposal brief owner。</li>
</ul>
</div>
<div class="panel span-12">
<h2>D1 / D7 / D14 / D30</h2>
<div class="timeline">
<div class="stage"><h3>D1 · 腳本可用</h3><ul><li>客戶成功窗口可直接拿腳本開會。</li><li>產品負責人補 3 個 proof statement。</li><li>CEO 決策窗口確認提案門檻。</li></ul></div>
<div class="stage"><h3>D7 · 產線成形</h3><ul><li>3 場拜訪回收痛點/質疑/證據。</li><li>建立 proposal_brief 資料表。</li><li>週會只看 deal readiness score。</li></ul></div>
<div class="stage"><h3>D14 · 簡報模板</h3><ul><li>把共通痛點轉成 5 頁策略簡報。</li><li>每頁綁證據、角色、CTA。</li><li>反對意見回覆進 playbook。</li></ul></div>
<div class="stage"><h3>D30 · 系統化</h3><ul><li>PLS 後台進 dashboard/tool。</li><li>自動從拜訪紀錄生成 brief draft。</li><li>提案採用率與成交風險可追。</li></ul></div>
</div>
</div>
<div class="panel span-12">
<h2>Purpose-to-Purpose E2E</h2>
<div class="flow">
<div class="step"><b>原始目的</b><span class="small">客戶策略簡報與提案產線要讓客戶感受到差異化優勢。</span></div>
<div class="step"><b>主成果</b><span class="small">拜訪腳本、資料欄位、brief 轉換規則、驗收與同步訊息。</span></div>
<div class="step"><b>人採用</b><span class="small">客戶成功開會、產品補 proof、CEO 定提案門檻。</span></div>
<div class="step"><b>專案指標</b><span class="small">痛點回收率、proof 完整度、proposal readiness、下一會議承諾。</span></div>
<div class="step"><b>錢路徑</b><span class="small">提高提案轉換、縮短 brief 製作時間、減少錯誤 pitch 流失。</span></div>
</div>
</div>
<div class="panel span-6">
<h2>市場成熟做法</h2>
<p>Gartner B2B Buying Journey 指出複雜 B2B 採購涉及多位決策者,供應商資訊若能幫助買方推進 buying jobs,更容易讓採購順利。HubSpot discovery call practice 則強調先圍繞目標與價值提問,再把價值連回客戶基準。這輪把成熟做法落成「問法、資料欄位、brief 轉換、驗收」。</p>
<ul>
<li>https://www.gartner.com.au/en/sales/insights/b2b-buying-journey</li>
<li>https://blog.hubspot.com/sales/discovery-call-questions</li>
</ul>
</div>
<div class="panel span-6">
<h2>Data / API / Permission</h2>
<div class="code">tables:
customer_visit_sessions
buyer_roles
pain_points
proof_statements
proposal_briefs
apis:
POST /visits
POST /proof-statements
POST /proposal-briefs
GET /proposal-readiness/:account_id
roles:
customer_success: submit visit notes
product_owner: approve proof
ceo_window: approve proposal gate</div>
</div>
<div class="panel span-4">
<h2>Production Acceptance</h2>
<p><b>Owner:</b> 墨宇客戶成功窗口 + 墨宇產品負責人。</p>
<p><b>Due:</b> D7 前完成 3 場腳本實測。</p>
<p><b>Pass:</b> 每場有痛點、質疑、proof、下一步承諾,且可生成 proposal brief。</p>
</div>
<div class="panel span-4">
<h2>Solution Selection</h2>
<p>選 `tool + project`:比單純 communication 更完整,因為要形成可重複產線;暫不做 full system,因為仍需 D7 實測資料驗證欄位。</p>
</div>
<div class="panel span-4">
<h2>People Sync LINE</h2>
<div class="script">我已把第一版客戶拜訪腳本做成可執行產線。
請你今天回覆:
1. 下一場要套用的客戶名稱/情境
2. 你能補的 1 句 proof statement
3. D7 前可實測幾場
若無回覆,先標成資料缺口:visit_owner_pending。</div>
</div>
</section>
</main>
</body>
</html>

Data Model / API / Sync

Tables

customer_visit_sessions

  • id uuid primary key
  • account_name text
  • visit_date date
  • customer_success_owner uuid
  • product_owner uuid
  • ceo_gate_owner uuid
  • stage enum: planned, completed, brief_generated, proposal_ready, closed
  • next_step_due_at timestamptz

buyer_roles

  • id uuid primary key
  • visit_session_id uuid
  • role_type enum: user, economic_buyer, technical_influencer, procurement, executive
  • name_or_label text
  • main_concern text
  • success_metric text

pain_points

  • id uuid primary key
  • visit_session_id uuid
  • moment text
  • customer_quote text
  • unconvinced_reason text
  • severity int

proof_statements

  • id uuid primary key
  • pain_point_id uuid
  • proof_owner uuid
  • internal_capability text
  • customer_language_statement text
  • evidence_url text nullable
  • approval_state enum: draft, approved, rejected, retired

proposal_briefs

  • id uuid primary key
  • visit_session_id uuid
  • brief_summary text
  • readiness_score int
  • next_meeting_commitment text
  • generated_at timestamptz

APIs

  • POST /api/pls/customer-visits
  • POST /api/pls/customer-visits/:id/pain-points
  • POST /api/pls/proof-statements
  • POST /api/pls/proposal-briefs/generate
  • GET /api/pls/proposal-readiness/:account_name

Permissions

  • 客戶成功窗口:建立 visit session、填痛點與下一步。
  • 產品負責人:新增/批准 proof statement。
  • CEO 決策窗口:批准 proposal gate 與下一步資源。
  • PLS worker:可生成 draft,但不得批准 proof 或代表客戶承諾。

Audit / Rollback

每個 proof approval 與 proposal gate change 都寫入 actor、old_state、new_state、evidence_url、reason。錯誤 proof 只能 retire,不刪除原始拜訪資料。

Decision Record

Decision

將「第一版客戶拜訪腳本」升級成 tool + project 形式的客戶策略簡報與提案產線作戰台。

Options Considered

  • communication only:能快速產出話術,但無法形成資料回收與提案產線。
  • doc only:可讀性高,但缺操作面與驗收節奏。
  • presentation:適合 D14 後客戶簡報模板,但 D1 先需要拜訪資料。
  • tool + project:最佳,因為目前瓶頸是把拜訪腳本、資料欄位、owner、驗收節奏連成可重複產線。
  • full system:暫不採用,因為 D7 前仍需用 3 場拜訪驗證欄位。

Recommendation

D1 使用 HTML 作戰台;D7 用實測資料調整 schema;D14 產出策略簡報模板;D30 再進 PLS 後台 dashboard/tool。

Adoption Status

Ready for review. 需要墨宇客戶成功窗口與產品負責人各回一個 next customer/proof signal。

If Not Adopted

請回覆卡點是:腳本不適合、proof 不足、owner 不對、還是 proposal gate 不清楚。不要只要求重寫摘要。

E2E Verification

Checks

  1. Context confirmed AI-native project de53d513 and deliverable bucket a5f3b2f3-2d8e-4d0a-b25c-009e66d4eaf1.
  2. Primary artifact is HTML, not Markdown.
  3. Required files exist: production-brief.md, data-model.md, acceptance-tests.md, decision-record.md, artifact-url-or-pr.md.
  4. Market context has at least 2 external sources.
  5. PLS upload-files and public Gist publication must both succeed.
  6. Public URL must return HTTP 200 and list customer-visit-proposal-war-room.html.

Current Result

Pass. Public Gist returned HTTP 200 on 2026-05-24 and gh gist view --files listed customer-visit-proposal-war-room.html plus all appendices.

Primary URL: https://gist.github.com/esz135888/92f61771a5dd05e73df400e131392404#file-customer-visit-proposal-war-room-html

{
"job_id": "261b388a-ad2b-428e-ae20-b9a69681d860",
"ai_native_project_id": "de53d513-ec69-423b-9de2-7969241d2895",
"project": "客戶策略簡報與提案產線",
"what_hermes_learned": [
"The project should not wait for humans to organize notes; AI can create the first operational script and schema.",
"The real bottleneck is converting visit data into customer-language proof and proposal readiness.",
"A full system is premature until D7 validates fields from three customer visits."
],
"market_learning": [
"B2B buying is multi-stakeholder and non-linear; sales artifacts must help buyers complete buying jobs.",
"Discovery calls should center on goals, value and benchmarks before pitching features."
],
"assumptions_to_test_next": [
"Customer success can run three scripted visits before D7.",
"Product owner can approve at least two proof statements.",
"CEO decision window can define proposal gate criteria."
],
"next_round_priority": "Convert real D7 visit notes into a 5-page strategy brief template and proposal readiness dashboard."
}

Market Context / Market Maturity

Sources

Mature Practice

Gartner 的 B2B Buying Journey 強調複雜 B2B 採購通常涉及多位決策者,而且買方需要完成多個 buying jobs。成熟的 sales/proposal 產線不只是 pitch,而是幫買方降低採購複雜度與內部協調成本。

HubSpot discovery practice 強調 discovery call 要圍繞客戶 goals、value 與 benchmarks,而不是先講功能。成熟做法會把問題、價值、證據與下一步承諾結構化。

PLS Gap

PLS 目前有「要產出第一版客戶拜訪腳本」的訊號,但還缺可重複的資料欄位、proof approval、proposal readiness 與 owner/due/acceptance。

This Round Upgrade

本輪補上 HTML 作戰台、拜訪腳本、資料模型、API/sync、權限/稽核、acceptance tests、people sync 與 learning memory。市場研究只作為輸入,主成果是可採用產線。

People Sync

Targets

  • 墨宇客戶成功窗口:2a3628b7-d28f-4161-9ca8-ce15c4ead131
  • 墨宇產品負責人:45a2dfa3-9174-4f64-b333-33dfd9eafc87
  • 墨宇 CEO 決策窗口:6217ca6d-7a9b-47fd-bc95-05f795d9b4e7
  • 墨宇營運負責人:1585671a-76ad-4291-a10e-897dfee85170
  • 墨宇工程窗口:b89e1674-24fe-4189-808d-0825914ee35a

LINE Draft

我已把第一版客戶拜訪腳本做成可執行產線,不再只是一段話術。

請你今天回覆:

  1. 下一場要套用的客戶名稱/情境
  2. 你能補的 1 句 proof statement
  3. D7 前可實測幾場

若無回覆,我會先把資料缺口標成 visit_owner_pending,不進 proposal automation。

Expected Reply Signal

至少一個客戶情境、一句 proof statement、一個 D7 實測場次承諾。

客戶策略簡報與提案產線 Production Brief

場景

AI 自建專案 de53d513-ec69-423b-9de2-7969241d2895 的卡點是「產出第一版客戶拜訪腳本」,但真問題不是只有話術,而是匯入資料尚未轉成可採用成果,也缺 owner/驗收節奏。

D1 / D7 / D14 / D30

  • D1:客戶成功窗口可直接使用拜訪腳本;產品負責人補 3 句 proof statement;CEO 決策窗口確認提案門檻。
  • D7:至少 3 場客戶拜訪實測,回收痛點、質疑、證據與下一步承諾。
  • D14:把共通痛點轉成 5 頁策略簡報模板,每頁綁證據、角色與 CTA。
  • D30:在 PLS 後台形成 proposal pipeline dashboard/tool,自動從拜訪紀錄生成 brief draft。

Purpose-to-Purpose E2E

原始目的:讓客戶策略簡報與提案產線能真正提高客戶對差異化優勢的感受。 主成果:HTML 作戰台 + 拜訪腳本 + 資料模型 + acceptance tests。 人採用:客戶成功照腳本開會,產品補 proof,CEO 定 proposal gate。 專案/錢/風險指標:提高 proposal readiness、減少錯誤 pitch、縮短 brief 製作時間、降低客戶感受不到優勢的流失風險。

Owner / Due / Acceptance

  • Owner:墨宇客戶成功窗口、墨宇產品負責人。
  • Supervisor:墨宇 CEO 決策窗口。
  • Due:D7 前完成 3 場腳本實測。
  • Acceptance:每場拜訪都有痛點、質疑、proof、下一步承諾,且能生成 proposal brief。

Production Readiness

Production Path

  1. D1:使用 HTML 作戰台與拜訪腳本。
  2. D7:把 3 場拜訪資料填進 customer_visit_sessionspain_pointsproof_statements
  3. D14:用 approved proof statements 生成策略簡報模板。
  4. D30:接入 PLS dashboard/tool,自動產出 proposal brief draft。

Sync

  • 拜訪後 24 小時內由客戶成功窗口填 visit notes。
  • 產品負責人 48 小時內 approve/reject proof statement。
  • PLS worker 每週生成 proposal readiness scorecard。

Permission / Audit

PLS worker 可生成 draft,但不能批准 proof 或代表客戶承諾。所有 proposal gate change 必須有 actor、reason、evidence。

Failure / Rollback

若 D7 三場實測無法產出 proof,回滾到 doc + communication:先補痛點清單與內部優勢共識,不進 proposal automation。

Skill Usage

  • purpose_e2e_toolbox_v2:用於 D1/D7/D14/D30、目的到目的 E2E、價值/錢路徑、人能力提升、solution stack、資料/API/權限/稽核與 decision record。
  • Web search:查 Gartner B2B Buying Journey 與 HubSpot discovery call practice,作為 market_context 與 market_maturity 輸入。
  • HTML/dashboard artifact:用本地檔案建立可開啟主成果,再用 Gist 與 PLS upload-files 發布。
  • PLS fixed helper:使用 doctor/touch/claim/context/progress/upload-files/complete。

Solution Selection

Selected

tool + project

Why

這不是單一 LINE unblock,也不是單純寫文件。目標是把客戶拜訪腳本變成可重複的策略簡報與提案產線,所以需要操作面、資料欄位、角色責任、驗收節奏與下一版系統化入口。

Why Not Smaller

  • communication 只能催 owner 回覆,不能收斂成 proposal data。
  • doc 只能解釋流程,不能讓團隊直接看狀態與 pass/fail。

Why Not Bigger

  • system 需要先有 D7 實測資料驗證欄位與權限;現在直接建完整系統會過早。

Next Upgrade

D7 實測後把 readiness score 與 proposal brief generation 接入 PLS dashboard。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment