SRP 戰略中心｜操作教學（選擇＋執行）

老闆先睇 · Executive Summary

如果你只用 5 分鐘，先了解 SRP 想改變咩

大部分美容院、醫美中心、SPA 或連鎖服務企業，都唔係完全冇客、冇員工或者冇系統；真正問題通常係：系統有好多資料，但資料冇變成每日應做的工作；前線做咗好多工作，但結果又冇可靠地回到管理層。

SRP 業績驅動作業系統要處理的，正正係中間呢段「由數據到行動、由行動到結果」的斷層。它唔只係列出會員名單，亦唔只係展示報表，而係將經營訊號整理成 Opportunity，再透過 Program、指派、SLA、Task、結果紀錄及歸因，形成一套可以每日運作的管理方式。

戰略中心作為「領航」（比喻），應該回答 6 個問題

領航問題	SRP 對應能力	你會得到甚麼
我哋目前身處邊度？	戰略中心、總覽、Pipeline、Data／Run Health	知道目前機會、工作、樽頸及資料是否可信。
下一個目的地係咩？	Revenue Driver、Objective、Program 目標	將「提升業績」拆成 Lead、二訪、回訪、到店、續購等具體方向。
有邊幾條路可以行？	Playbook、Signal、Preview、Suppression、Channel	比較可行路線，先看候選、排除、品質及容量再決定。
邊個行、幾時要到？	Assignment、SLA、Task、Follow-up	每個行動都有負責人、到期時間及下一步。
我哋有冇偏離路線？	Overdue、Pipeline 堆積、Run Error、Health	及早發現容量不足、資料錯誤、工作逾期或流程漏水。
最後有冇真正到達？	Booking、Arrival、Paid、Attribution、Prepaid 分流	用已核實業務結果收尾，而唔係只報告做咗幾多次 Call。

領航 ≠ 自動駕駛：SRP 負責整合訊號、提供方向、組織工作及保存證據；最終 Program 規則、客戶接觸、資源分配及擴大決定仍由獲授權的人員負責。

老闆最關心的 8 個問題

你可能會問	SRP 點樣回答
我哋究竟漏緊邊類生意？	按 Lead SLA、未成交興趣、取消／No-show、服務到期、二次到訪、沉睡、消費下降等訊號分類。
咁多名單，應該先跟邊個？	用訊號、優先分數、資料品質、到期時間及價值類別排序，而唔係所有人同一優先級。
邊個負責？幾時要完成？	設定 Holder First、Round Robin 或 Shop Team，配合 SLA、Escalation、每日容量及每人工作上限。
會唔會同一個客重複被騷擾？	可排除未來預約、Opt-out、Program 衝突，並設定冷卻期及頻率上限。
前線今日應該做咩？	「我的工作」只顯示指派給目前員工的工作，可篩今日到期／逾期，並記錄下一步。
員工話跟咗，點證明？	Task 有開始、結果、備註、下次跟進及狀態；Program Run 亦有執行紀錄及錯誤。
做完到底有冇收入？	Direct、Assisted、Observed 分開；已付款與預付核銷分開；增量要有合格實驗先成立。
會唔會自動化過頭？	WhatsApp 保持手動草稿；Program 有草稿、審批、啟用、暫停及結束；Runner 另有獨立開關。

SRP 最適合邊類企業？

有一定會員及交易歷史已有預約、療程、付款及會員資料，但未能有效轉成行動。

有多位前線或多間分店需要清晰派工、SLA、分店範圍及一致工作方法。

重視回訪與長期關係收入不只靠一次新客，而係服務週期、二訪、續購及挽回。

不想只靠大規模群發希望先做合規排除、容量控制及個別跟進。

想知道活動真正結果不滿足於「發出幾多訊息」，要看預約、到店、付款及歸因。

需要安全分階段導入希望由 Preview／Shadow 開始，再逐步啟用 Program 與 Runner。

管理層應有的合理期望：SRP 提供的是更有紀律的發現、派工、跟進及量度方法。實際業績仍會受客源質素、服務能力、價錢、員工技巧、供應及市場環境影響；系統不應被理解為必然產生收入的機器。

01 · 產品價值

SRP 呢套功能有咩用？

一般系統只會話你「今個月做咗幾多生意」；SRP 再向前一步，幫你處理「下一步應該跟邊批人、由邊個跟、幾時要跟、做完有冇結果」。

減少漏跟客將逾期 Lead、未成交興趣、取消預約、服務到期、消費下滑等訊號集中處理。

提高前線執行力店長有分派、SLA、逾期及容量視角；員工有清晰「我的工作」。

避免同一客人被重複滋擾可設定未來預約、Opt-out、Program 衝突、冷卻期及頻率上限。

減少用散落 Excel 管名單由 Program 設計、預覽、審批、啟用、執行到結果都保留狀態。

前線結果可以追蹤未接、感興趣、無興趣、回電、Opt-out、完成等結果有一致紀錄。

收入說法更可信Direct、Assisted、Observed、Incremental 分開；預付核銷不扮新增現金。

適合嘅實際場景

場景	傳統做法	使用 SRP 後
新 Lead 過咗幾個鐘未跟	靠員工自己記得	Lead SLA 訊號 → Opportunity → 指派 → Task → 結果
客人取消／未到	名單散落、無優先次序	Booking Recovery 訊號 → 挽回工作 → 產能價值分開看
護理週期到期	人手翻查上次療程	Service Due 根據歷史週期找候選客人
90 日未活躍	一次過廣播訊息	Inactive 訊號＋Opt-out／未來預約排除＋人工跟進
有活動但唔知有冇成效	只睇派出幾多訊息	由 Opportunity／Task 一直看到付款歸因及結果分類

一日／一週實際點用？

角色與時間	實際動作	完成後應有甚麼
店長｜開舖後 15–30 分鐘	看總覽的今日到期、逾期、Signal Breakdown、Assignee SLA；到機會收件箱處理高優先及未指派項目。	今日工作有人負責；超出容量的工作已延後或調整。
前線｜開班	進入「我的工作」→ 今日到期 → 按優先度開始處理。	每個開始的工作都有真實狀態。
前線｜每次聯絡後	立即記錄結果；no_answer／call_back 填下次時間；wrong_contact／opt_out 填原因。	管理層知道做咗咩及下一步，客人保護狀態亦可被更新。
店長｜收舖前	重新整理我的工作及總覽；檢查仍逾期、等待客戶及未指派工作。	留下清晰交班，而唔係口頭講「差唔多做晒」。
營運負責人｜每週	看 Program、Runs、Pipeline、Results、Health；比較 Signal／Shop／Assignee。	決定維持、調參、縮量、暫停或擴大。
老闆／管理層｜每週或每月	看 Opportunity、執行率、預約／到店、歸因實收、拒收及資料健康。	知道問題出在機會、執行、到店、付款還是量度，而唔只看一個營業額總數。

02 · 經營痛點 · 點解一般做法未夠？

你看到的問題，往往只係表面；SRP 要處理的是背後工作斷層

「客人少咗」、「員工跟得慢」、「活動冇效果」只係結果。要改善，先要分清楚問題出現在哪一段：係訊號冇被發現、名單冇優先次序、冇人負責、工作容量不足、跟進冇紀錄，定係量度方式本身有問題。

痛點 1：報表永遠講昨天，冇人知今日要做咩

表面現象	老闆知道上月營業額跌，但店長仍然要自己猜應該打邊批客。
真正成因	報表屬於落後指標，只描述結果，冇將結果拆成可控制的 Lead、預約、到店、回訪及續購動作。
SRP 解法	把 Lead SLA、服務到期、二次到訪、消費下降等訊號變成 Opportunity，再進入 Program／Task。
老闆應看	Open Opportunities、今日到期工作、逾期工作、Pipeline Stage、Signal Breakdown。

痛點 2：會員資料好多，但名單越做越大

表面現象	每次活動都匯出幾千人，前線根本處理唔晒，最後只好群發。
真正成因	「符合條件」不代表「現在值得跟」；缺少優先次序、資料品質、到期時間及容量限制。
SRP 解法	Program Preview 先計候選／排除、最低分數、每日 Task 上限及每人上限，再決定是否啟用。
老闆應看	Preview Candidates、Excluded、Estimated Daily Tasks、Data Quality。

痛點 3：有客人，但 Lead 跟得太慢

表面現象	網上查詢、Lumi Lead 或門店查詢已入系統，但幾個鐘甚至隔日先有人跟。
真正成因	冇統一 SLA、冇逾期提示、冇清晰負責人，員工只處理自己眼前最容易的工作。
SRP 解法	`lead_sla` 找出逾期 Lead，按 holder／round robin 指派，並在「我的工作」顯示到期時間。
老闆應看	逾期 Task、Assignee SLA、感興趣但未預約、Lead→Booking→Payment 的分段結果。

痛點 4：員工話「跟咗」，但管理層無法追蹤

表面現象	Call List 有很多剔號，但唔知係無人接、客人有興趣、要求回電，定已經完成。
真正成因	結果代碼不一致、缺少下一步日期、狀態與會員／Opportunity 冇連結。
SRP 解法	Task 統一記錄 no_answer、interested、not_interested、wrong_contact、call_back、opt_out、completed；需要時強制下次跟進時間或原因。
老闆應看	Task 狀態、Next Action、到期／逾期、Follow-up 是否完成。

痛點 5：同一個客人被幾個部門重複聯絡

表面現象	客人已預約仍收到召回；剛拒絕聯絡又被另一個 Program 打電話。
真正成因	篩選名單與預約、Opt-out、舊 Call List、其他 Program 互不相知。
SRP 解法	可排除未來預約、Opt-out、Program 衝突、服務補救優先，並加冷卻期與 Frequency Cap。
老闆應看	Excluded Count、Suppression Checks、Opt-out 結果及 Contact Cooldown。

痛點 6：分派唔公平，忙嘅人更忙，閒嘅人冇工作

表面現象	所有機會都落到最資深顧問；有人有幾十張逾期 Task，有人冇工作。
真正成因	冇 Assignment Strategy、每日容量、每人上限及 SLA 升級。
SRP 解法	可選 Holder First、Round Robin、Shop Team；設定 Staff Task Cap、Daily Capacity、SLA、Escalation。
老闆應看	Assignee SLA、Active Tasks、Overdue Tasks、Completed Tasks。

痛點 7：預約取消／No-show 留低空檔，但冇系統性挽回

表面現象	房間、治療師及設備突然空出，店長臨時在群組問有冇客可以補位。
真正成因	取消事件冇變成有時限的 Recovery Opportunity，亦冇與其他工作排優先次序。
SRP 解法	`booking_recovery` 建立 visit opportunity，指派人員跟進並追蹤 booked／arrived。
老闆應看	Recovered Visit Opportunities、Booking、Arrival；實收另行量度，唔把產能價值直接當現金。

痛點 8：活動只看發送量，容易高估功勞

表面現象	活動期間營業額上升，就把全部收入歸功於訊息或 Call Team。
真正成因	冇區分直接證據、輔助接觸、純觀察及真正增量；亦可能把預付核銷當新收入。
SRP 解法	Direct、Assisted、Observed、Incremental 分開；Payment／Refund 使用來源金額；Prepaid Consumption 分流。
老闆應看	Direct Paid、Assisted Paid、Observed Paid、Bookings、Arrivals、Prepaid Consumption。

痛點 9：自動化太進取，容易出現品牌與合規風險

表面現象	錯誤名單被大量聯絡；員工未檢查內容就發出；Program 一開即超出容量。
真正成因	缺少 Preview、審批、手動最終確認、獨立 Runner 開關及安全停止機制。
SRP 解法	Program 由 draft → pending approval → active；WhatsApp 為 manual draft；Runner 另有開關；可 Pause／End。
老闆應看	Program Status、Health、Channel Readiness、Run Error、Data Quality。

痛點 10：每次活動都由零開始，組織冇累積學習

表面現象	同一類召回活動做過多次，但冇人知道邊個訊號、渠道、分店或人員效果較好。
真正成因	設定、執行、結果分散；冇版本、Run 歷史、Breakdown 及一致結果口徑。
SRP 解法	Program 有版本、Clone、Run、Retry；Results 可按 Program、Signal、Shop、Assignee、Channel 分析。
老闆應看	同類 Program 的 Preview、Run Health、Task Completion、Attributed Result 變化。

03 · 應用理論 · 用白話講清楚

SRP 唔係一堆功能拼埋一齊；背後係一套「由訊號推動行動」的管理方法

以下理論唔需要管理層讀學術論文先識用。每一個概念，都直接對應系統內一個決策或操作。

理論 1：領先指標 vs 落後指標

營業額、付款、到店係落後指標：發生之後先知道。Lead 是否逾期、興趣後有冇預約、首次服務後有冇二次預約、服務週期是否到期，係較接近行動的領先指標。

美容業例子：「今月回訪收入下降」已經太遲；「170 名會員已超過個人服務週期而未預約」先係可以今日安排工作的訊號。

在 SRP 的應用：Signal、Opportunity、Due At、Recommended Action、Task。

理論 2：客戶生命週期（Customer Lifecycle）

同一位客人處於新 Lead、首次到店、待二訪、活躍回訪、套餐餘額、消費下降或沉睡階段時，適合的下一步完全不同。靜態會員群組只能描述「佢係邊類人」，生命週期則回答「佢而家最需要邊一步」。

例子：剛完成首次服務的客人，應優先處理第二次預約；90 日未回店但已有未來預約的客人，應被排除，而唔係再收到召回。

在 SRP 的應用：second_visit、service_due、inactive_90／180、spend_drop、future booking suppression。

理論 3：Next Best Action（下一個最合適行動）

Next Best Action 唔係叫系統自動決定所有事情，而係根據訊號、狀態、資料品質及可用渠道，提供一個可解釋的「下一步建議」，再由人員執行或確認。

例子：Lead SLA 逾期 → 優先 Call；無人接聽 → 必須設定下次 Follow-up；有興趣 → 下一步應轉向 Booking，而唔係繼續重複推銷。

在 SRP 的應用：Recommended Action、Outcome Code、Next Follow Up At、Pipeline Stage。

理論 4：Theory of Constraints（先處理最大樽頸）

業績鏈條由多個環節組成：Lead → 聯絡 → 興趣 → 預約 → 到店 → 付款 → 回訪。如果最大流失發生在「有興趣但未預約」，再增加更多 Lead 未必有用；應先處理目前限制整體結果的樽頸。

例子：每週 200 個 Lead，但 60 個逾期未跟，優先改善 Lead SLA；如果 Lead 已跟得快，但大量 booked 未 arrival，就先處理 no-show／arrival 流程。

在 SRP 的應用：Pipeline Funnel、Signal Breakdown、Interested Waiting Booking、Booked Waiting Arrival。

理論 5：容量約束與 Work-in-Progress 限制

產生 1,000 個「機會」唔代表團隊有能力處理 1,000 個工作。過多 Work-in-Progress 會令所有工作都延遲，最後員工只揀最容易的客人處理。有效系統必須將候選量同人手容量一齊設計。

例子：420 名合資格沉睡客，但 4 名顧問每日每人只可處理 8 個；Program 應按每日 30–32 個工作分批，而唔係第一日全數派出。

在 SRP 的應用：Daily Task Cap、Staff Task Cap、Daily Capacity、SLA、Preview Daily Tasks。

理論 6：Closed-loop Management（閉環管理）

一次性名單只有「開始」，沒有「結果」。閉環要求每一步都有輸入、負責人、狀態、結果及下一步，並將結果送回管理層，成為下一輪決策依據。

Sense發現可信訊號

Decide選優先級與規則

Act指派並完成工作

Measure記錄預約／到店／付款

Learn按結果調整下一輪

在 SRP 的應用：Program → Run → Opportunity → Task → Outcome → Attribution → Results。

理論 7：Human-in-the-loop（人機協作）

美容、醫美及高接觸服務涉及信任、敏感資料、個人狀況及品牌語氣，唔適合將所有決定交給背景自動化。系統適合負責發現、排序、提醒及保存證據；人員負責判斷內容、處理例外及最後接觸。

例子：SRP 可以為 manual_whatsapp Task 準備交接連結，但員工仍要檢查對象及文字，再在 WhatsApp 確認發送。

在 SRP 的應用：Program Approval、Manual Run、Manual WhatsApp、Outcome Note、Pause／End。

理論 8：Fail-closed 與合規優先

當 Opt-out 或必要資料不可確認時，系統應寧願唔聯絡，亦唔應假設可以聯絡。呢種設計叫 Fail-closed：缺少可信證據時先阻擋，再由人員處理。

例子：Message Cohort Preview 會排除 Opt-out、未來有效預約及有效舊 Call List；如果相關資料來源不可用，應避免誤放行。

在 SRP 的應用：Suppression Checks、Opt-out、Future Booking、Program Conflict、Cooldown、Frequency Cap。

理論 9：歸因階梯——相關不等於因果

客人在一次 Call 後付款，可能與該 Call 有直接連結，亦可能本來已打算購買。為避免將所有功勞歸給活動， SRP 將證據分成不同級別：

Direct

有 Growth 工作 context、token 或來源連結直接連到結果。

Assisted

窗口內有已確認接觸，但沒有更強的直接來源。

Observed

結果在機會後出現，但沒有已確認接觸證明；不加入直接歸因總額。

Incremental

要有有效 holdout 及樣本檢查，先可描述為相對對照組的增量。

理論 10：Learning System（由每次執行累積學習）

真正有價值的系統唔係一次計出「最佳答案」，而係保留每次 Program 設定、Run 狀態、排除、Task 結果及歸因，令團隊可以比較不同訊號、分店、員工及渠道，逐步改善下一輪。

在 SRP 的應用：Program Version、Clone、Run History、Retry、Result Breakdown、Health。

04 · 完整案例庫 · 全部使用合成數據

由實際經營情境，睇清楚 SRP 點樣由問題走到結果

以下案例用來解釋方法及製作示範資料，不代表任何客戶的實際業績，亦不代表採用系統後必然得到相同結果。每個案例都刻意將「活動數量」、「已發生結果」及「可否宣稱增量」分開。

案例 1：新 Lead 太多，但逾期未跟——Lead SLA 作戰

企業背景	3 間美容中心，每週由網上查詢、Lumi 及門店登記取得約 148 個 Lead，由 4 名顧問輪流跟進。
原有痛點	每朝人手下載名單；員工先跟自己熟悉的客；31 個 Lead 超過內部 4 小時目標仍未有首次接觸。
SRP Program	訊號選 `lead_sla`；SLA 4 小時；Assignment 選 Round Robin；每日 Task Cap 32；每人上限 8；渠道選 Manual Call。
系統流程	Runner 找出逾期 Lead → 建立 Opportunity／Task → 平均指派 4 名顧問 → 員工在「我的工作」按到期時間處理 → 記錄結果及下次跟進。
一輪合成結果	31 個 Opportunity；29 個可聯絡 Task；20 個成功接觸；8 個表示有興趣；5 個建立預約；4 個到店；3 筆新付款。
應如何解讀	可以報告完成率、逾期改善、Booking／Arrival 及 3 筆已核實付款。未有對照組時，不可話 3 筆全部是「系統新增增量」。
管理決定	如果大量 Task 仍逾期，先改善人手容量或 SLA；如果接觸快但 Booking 低，問題可能轉到話術、產品或預約承接。

賣點：唔係再買更多 Lead，而係先減少已付成本取得的 Lead 因跟進太慢而流失。

案例 2：客人問過療程但未預約——Interest Unconverted

企業背景	醫美中心每月有大量面部療程及儀器查詢，不少客人已表示興趣，但之後無預約／付款。
原有痛點	「有興趣」只寫在備註；無統一 Grace Period；同事幾日後先想起，或者重複聯絡已有預約的人。
SRP Program	選 `interest_unconverted`；Grace Period 24 小時；Tracking 14 日；排除 Future Booking、Opt-out、Program Conflict；Holder First。
合成 Preview	原始興趣訊號 96；已有未來預約 15；Opt-out 7；其他 Program 衝突 4；剩餘候選 70；每日工作 20。
前線做法	先讀 Opportunity 的 Explainable Evidence 及 Source Timeline；聯絡後記錄 interested、call_back、not_interested 等結果。
合成結果	70 候選中完成接觸 49；18 個建立預約；13 個到店；8 個有新付款；另有 6 個要求稍後跟進。
應如何解讀	8 筆付款可按 Direct／Assisted 證據顯示；未聯絡但自行付款者應屬 Observed 或其他來源，唔應強行算入。

案例 3：取消／No-show 留低空檔——Booking Recovery

企業背景	一間高端 SPA 每週平均有 22 個取消或 No-show，涉及房間、治療師及儀器時段。
原有痛點	店長臨時在群組叫人打客；無記錄邊個被聯絡、邊個補約、空檔最後有冇被填補。
SRP Program	選 `booking_recovery`；Grace Period 2 小時；價值類別為 visit_opportunity；按分店團隊派工。
系統流程	取消／缺席事件 → Recovery Opportunity → 今日到期 Task → 員工聯絡及安排新 Booking → 到店事件回流。
合成結果	22 個事件；16 個可聯絡；9 個重新預約；6 個最終到店；其中 4 個產生新付款。
應如何解讀	6 個到店可作 Recovered Visit／Capacity 指標；只有實際新付款可進入 paid revenue。預付療程到店不代表新增現金。
管理決定	如果重新預約多但到店低，應改善提醒／訂金／確認流程；如果空檔本身已由 Walk-in 填補，唔應重複計算產能價值。

案例 4：新客做完第一次，但冇第二次——Second Visit Activation

企業背景	皮膚管理中心每月有約 120 名首次完成服務的新客，管理層希望建立二訪習慣，而唔係只靠一次折扣。
原有痛點	首次服務後的 Follow-up 無標準；顧問只記得高消費客；已有第二次預約的人仍在名單。
SRP Program	選 `second_visit`；Due Days 設 21；排除 Future Booking 及 Opt-out；Holder First；SLA 24 小時。
合成 Preview	120 名首次客；已預約二訪 28；仍未到期 8；Opt-out 3；剩餘 81 個候選。
合成結果	完成聯絡 60；22 個建立二訪預約；17 個到店；12 個有新付款；5 個為預付療程回店。
應如何解讀	12 筆新付款與 5 個 prepaid consumption 必須分開；二訪率應以合資格 cohort 作分母，唔好用全部新客造成偏差。

案例 5：服務週期已到，但客人未回店——Service Due

企業背景	美容中心提供面部護理、脫毛及身體療程，不同服務有不同合理回訪週期。
原有痛點	固定用「30 日未回」篩所有人，忽略個人實際間隔；容易太早催促或太遲跟進。
SRP Program	選 `service_due`；設定 Min Samples 3、Lookback Days 365 及 Due Multiplier；Minimum Data Quality 要求足夠歷史。
合成 Preview	檢查 1,200 名有服務歷史會員；420 人樣本不足；260 人未到期；145 人已有未來預約；剩餘 175 候選。
前線做法	詳情先顯示 Evidence 及 Recommended Action；顧問按會員過往服務及備註決定 Call 或 Follow-up。
合成結果	175 候選分 7 日處理；98 個成功接觸；36 個預約；29 個到店；其中 18 筆新付款。
應如何解讀	資料樣本不足的人被排除，係品質保護而唔係漏客；實際回訪成效應按服務類別及分店分拆。

案例 6：90 日未活躍會員太多——分批 Win-back

企業背景	4 間分店累積 2,400 名約 90 日無近期付款活動的會員，但只有 5 名顧問可負責召回。
原有痛點	一次匯出全部名單，首兩日大量 Call，之後工作堆積；客人已有預約或曾拒收仍被打擾。
SRP Program	選 `inactive_90`；排除 Future Booking、Opt-out、Program Conflict；Cooldown 168 小時；Frequency Cap 2／30 日；每日 35、每人 7。
合成 Preview	2,400 原始訊號；已有預約 305；Opt-out 110；Program 衝突 145；資料品質不足 80；候選 1,760；預計分約 51 個工作日處理。
管理決定	老闆可先按 Priority Score 或分店縮小至 420 個高優先候選，做兩星期 Pilot，而唔係立即處理全部。
Pilot 合成結果	420 候選；完成 310；有興趣 72；預約 48；到店 35；新付款 21；要求拒收 9。
應如何解讀	先評估完成率、拒收率、預約及實收，再決定是否擴大。沒有 holdout 時，21 筆付款不等於 21 筆因果增量。

案例 7：老客消費明顯下降——Spend Drop

企業背景	連鎖醫美中心發現部分過往穩定消費會員，在最近一個窗口的實收較之前明顯下降。
原有痛點	只按「總消費高」找 VIP，無法知道邊個正在下降；顧問等客人完全流失先發現。
SRP Program	選 `spend_drop`；設定 Window Days、Minimum Prior Spend 及 Drop Ratio；排除已有預約及 Service Recovery 個案。
合成 Preview	過往合資格付款會員 680；達到最低 prior spend 240；符合下降比例 74；排除已有預約 18；候選 56。
跟進方式	先用 Customer Summary 及 Source Timeline 了解情況；重點可以係服務體驗、療程週期或關係維護，唔應只推優惠。
合成結果	56 候選；完成接觸 41；確認服務問題 6；建立 Follow-up 15；新預約 12；新付款 7。
應如何解讀	部分成果可能是服務補救而唔係銷售；需要分開看 Recovery、Booking 及 Paid，不應只追求短期付款。

案例 8：客人尚有療程餘額但中斷——Treatment Balance

企業背景	SPA 有一批客人尚有療程次數／餘額，但長時間未預約，影響服務完成及關係維護。
原有痛點	員工容易將「叫客返嚟用已付款療程」誤當成新增營業額，導致結果口徑失真。
SRP Program	選 `treatment_balance`；設定 Minimum Remaining；價值類為 prepaid_consumption；排除 Future Booking 及 Opt-out。
合成 Preview	有餘額會員 310；已有預約 128；未達 Minimum Remaining 42；Opt-out 9；候選 131。
合成結果	完成聯絡 90；預約 35；到店核銷 27；同次產生額外新付款 5。
應如何解讀	27 個預付核銷放入 Prepaid Consumption Lane；只有 5 筆新的有效付款可以計入 New Paid。

案例 9：Message 篩選後先做合規 Cohort 草稿

企業背景	CRM 團隊在 Message 頁按分店、會員組別、未活躍日數及消費條件選出 120 名會員。
原有痛點	匯出後先發現部分人已拒收、已有未來預約或仍在舊 Call List。
SRP 操作	勾選會員 →「建立業績引擎 Cohort」→ Preview selected／eligible／excluded → 確認建立 draft。
合成 Preview	Selected 120；Eligible 88；Excluded 32（Opt-out 12、Future Booking 14、Active Call List 6）。
目前邊界	系統只建立獨立 Cohort 草稿；未有 Cohort 列表、詳情或直接轉 Program／Task 的 UI，亦未保存完整 Message filter snapshot。
應如何介紹	可介紹為「先做排除並保存草稿」，不可講成「一按立即派工」。

05 · 選型比較 · SRP 的定位

SRP 唔係要取代所有工具，而係補上「由洞察到執行結果」的一層

工具類型	通常擅長	常見斷點	SRP 業績驅動功能補上的部分
CRM／會員系統	保存會員資料、標籤、備註	知道客人係邊個，但未必知道今日最應做咩	Signal、Opportunity、Priority、Next Action、Task
BI／Dashboard	報表、趨勢、結果分析	看出下跌，但缺少負責人、SLA 及行動閉環	Program、Assignment、Due、Outcome、Run
群發／Marketing Automation	大量發送訊息、Campaign	容易把「符合條件」當「應該聯絡」，亦未必考慮前線容量	Suppression、Cooldown、Frequency Cap、Daily Capacity、人工確認
一般 Task 工具	分派、截止日、完成狀態	任務與會員、預約、到店、付款及業務訊號分離	Opportunity Detail、Source Timeline、Attribution、Pipeline
單純 Call List	提供聯絡名單	結果代碼、下一步、重複聯絡及收入結果不一致	Outcome Validation、Follow-up、Opt-out、Result Breakdown

SRP 的差異化唔係「有 AI」三個字，而係 6 個營運連接

訊號連接工作唔只顯示分析，而係形成 Opportunity 及 Task。

工作連接會員事實詳情有 Evidence、Suppression、Timeline 及 Customer Summary。

派工連接容量每日／每人上限、SLA、Escalation 及派工策略。

接觸連接合規Opt-out、Future Booking、Program Conflict、Manual WhatsApp。

結果連接付款Direct／Assisted／Observed 分開，Refund 及 Prepaid 有清晰口徑。

每次執行連接下一輪學習Program Version、Run、Retry、Breakdown 及 Health。

老闆應該點判斷值唔值得導入？

先揀一個高頻、可控、資料足夠的問題
例如 Lead SLA、二訪或 90 日沉睡；唔好第一日同時開晒所有 Program。
確認前線真實容量
每日實際可以完成幾多 Call／Follow-up，先設定 Daily Task Cap 及 Staff Cap。
先做 Preview／Pilot
檢查 Candidates、Excluded、Data Quality，再用一間分店或小批量開始。
同時看營運與結果指標
完成率、逾期、拒收、預約、到店、付款要一齊看；唔好只看 Call 數。
決定是否擴大
如果結果差，先找樽頸；可能需要改訊號、名單品質、容量、話術或服務流程，而唔係盲目擴量。

建議導入方法：由一個問題開始，而唔係一次過改晒公司

階段	重點工作	管理層驗收	唔應該做
準備期	確認資料表、權限、分店範圍、Opt-out、Booking Status、測試帳號及合成資料。	功能關閉時舊流程不受影響；UAT 畫面可讀取。	未確認資料品質就開 Runner。
Preview／Shadow	建立一個 Program 草稿，只做 Preview；檢查候選、排除、每日工作量及樣本。	店長確認名單有業務合理性；排除規則符合公司政策。	為咗候選數好看而關閉 Opt-out／Future Booking。
單店 Pilot	選一間店、少量人員、每日容量上限；記錄所有 Task Outcome。	逾期率、完成率、拒收率、Booking／Arrival 正常；無大量投訴或重複聯絡。	只追求 Call 數，忽略結果品質。
擴大執行	按分店／員工容量逐步擴；建立 Program 版本及固定 Weekly Review。	各店口徑一致；Run／Health 可追蹤；負責人清晰。	將一間店參數直接複製到所有店而不調整。
量度與學習	看 Direct／Assisted／Observed；有條件時建立 holdout；比較 Program／Signal／Shop。	知道哪一段改善、哪一段仍是樽頸；決定保留、調整或停止。	將所有期間付款都當作 Program 功勞。

老闆應要求團隊每週交代的 12 個指標

候選數有幾多人符合訊號，不等於一定要全部聯絡。

排除數及原因有幾多人因 Opt-out、未來預約、衝突或品質被保護。

建立工作數真正進入執行隊列的 Task，而唔係原始大名單。

完成率Completed Tasks ÷ 已到期應處理 Tasks；需配合狀態口徑。

逾期率Overdue Active Tasks ÷ Active Tasks；反映容量及管理問題。

成功接觸率有效接觸 ÷ 已嘗試聯絡；錯誤聯絡資料要另列。

拒收率Opt-out ÷ 已接觸；突然上升要檢查名單及話術。

預約率Bookings ÷ 合資格或已接觸人數；報告要寫清楚分母。

到店率Arrivals ÷ Bookings；用來分辨問題係邀約定履約。

Direct／Assisted Paid按證據層級分開的已付款結果。

Prepaid Consumption顯示服務履約，但不可放入新增現金。

Run／Data Health資料新鮮度、失敗、Partial、Retry 及渠道就緒。

導入風險、系統控制及客戶仍要負責的事

風險	SRP 現有控制	客戶仍需決定／執行
資料不完整或過期	Preview、Data Quality、Health、Detector Error、Run 狀態。	修正會員／預約／付款來源資料，制定資料負責人。
一次產生過多工作	Daily Task Cap、Staff Task Cap、Daily Capacity。	按實際人手設定容量，店長每日處理逾期。
重複或不合適聯絡	Future Booking、Opt-out、Program Conflict、Cooldown、Frequency Cap。	定義公司接觸政策、文案審批及客訴流程。
自動發送出錯	WhatsApp 目前只做 Manual Draft／Handoff。	員工發送前核對對象、內容、同意及時機。
權限過闊	Menu、Detail Permission、Shop Scope、Member Visibility。	按角色配置最小必要權限並定期覆核。
兩人同時修改	Lock Version／版本衝突檢查。	遇到衝突先重新載入，唔好用舊畫面覆蓋。
錯誤估算或過度歸功	Opportunity、Direct、Assisted、Observed、Incremental 分開。	財務及管理層確認報告口徑；未有 holdout 不宣稱增量。
預付核銷重複算收入	Prepaid Consumption Lane 及 paid rollup 排除。	培訓使用者分清履約、到店及新付款。
員工為完成 KPI 亂選結果	結果代碼、必填原因、必填下次跟進及 Audit Trail。	抽查備註及業務事件，避免只考核 Task 數量。
Pilot 無人持續管理	Run、Task、SLA、Health 提供可見性。	指定 Sponsor、Program Owner、店長及每週 Review 節奏。

咩情況下唔應該急住導入？

如果會員、預約、付款或 Opt-out 資料長期不完整；公司無人負責每日 Task；前線完全無容量；或管理層只想一次性大量發訊息，而唔打算記錄結果及處理排除，應先處理基本營運問題。 SRP 可以令工作更可見，但唔會代替服務質素、員工訓練、資料治理及管理責任。

06 · 產品架構

由數據到收入結果：一條完整工作鏈

1. 發現訊號逾期 Lead、取消預約、到期、流失

2. 人審揀路建議 → Accept → Command

3. Execute 草稿只建 Growth Program Draft

4. BG 人手發佈submit／approve／publish／resume

5. 檢視結果Pipeline、付款歸因、健康度

三個互相配合的部分

戰略中心（決策台） 系統自動分析判斷：數據可信度、收入機會、已實現實收、增量卡（未就緒顯示「尚未可驗證」）、建議路線。人只選擇（Accept／Dismiss）同執行（Execute）。Execute 只建立 Growth Program 草稿，不會自動派工或自動 Publish。

戰略中心 · 執行 真正執行工作的主畫面（選單仍叫 Business Growth Center）：Opportunity、Task、Pipeline、Program、Run、Result、Health。任務由 Program Runner 及既有 detectors 產生；Publish 必須人手。

Message → Cohort 草稿 將 Message 已篩選的會員先做合規 Preview，再建立獨立 Cohort 草稿。目前尚未有 Cohort 接駁 Program／Task 的管理 UI。

重要：戰略中心負責「揀路同執行草稿」；「戰略中心 · 執行」負責 Publish、派工同結果。兩者唔係同一個分頁，截圖時要分開介紹。技術路徑仍係 dashboard_new 與 marketing/business_growth。

07 · 使用角色

唔同崗位，各自睇到最需要嘅工作

老闆／管理層看戰略中心三張卡、建議品質及實際結果；避免將估算當收入。人只揀路同 Execute。

區域經理按分店檢視 Opportunity、Pipeline、Program 成效及負責人 SLA。

店長建立／管理 Program、指派機會、跟進逾期工作、平衡每日容量。

前線顧問集中處理自己的 Task，記錄結果、建立下次跟進、手動 WhatsApp 交接。

行銷／CRM由 Message 篩選會員，先做合規排除並保存獨立 Cohort 草稿，供後續人工規劃。

營運／數據人員看 Run、資料品質、來源健康、Opt-out 及手動 WhatsApp 模式。

建議責任分工（RACI）

系統要真正落地，必須先決定「邊個負責」，唔可以只安裝功能就當完成。

工作	主責（R）	最終負責（A）	需要諮詢（C）	需要知會（I）
選擇 Pilot 問題及成功標準	營運負責人	老闆／Sponsor	店長、CRM、財務	前線、IT
設計 Program 規則及容量	營運／CRM	營運負責人	店長、Data／IT	前線
Accept 建議、建立 Command	獲 Decide 權限者	店長／營運	管理層	前線
Execute Command（只出 Draft）	獲 Execute 權限者	營運負責人	店長	BG 發佈者
Pause／Stop Command	獲 Stop 權限者	營運負責人	店長	前線
審批及啟用 Program	獲授權發佈者（不可與建立者同一人）	營運負責人	店長、合規／私隱負責人	老闆、前線
每日指派及處理逾期	店長	區域／營運經理	前線	老闆
完成 Task 及記錄結果	前線顧問	店長	CRM／營運	區域經理
監察 Run／Data Health	Data／IT	系統負責人	營運	店長、管理層
核對收入及增量口徑	財務／分析	管理層	營運、Data	店長
每週 Review 及決定擴大／停止	營運負責人	老闆／Sponsor	全部相關角色	受影響團隊

08 · 真實可用範圍

目前版本：邊啲畫面可以真實截圖？

功能	狀態	目前實際情況
戰略中心分頁	功能開關＋專屬權限	真實 UI：目前位置／數據可信度、三張分開的指標卡、建議列表（可翻頁）、Accept／Dismiss、Command Center。顯示名係「戰略中心」；權限 detail 英文名不變（例如 Strategy Performance View）。
戰略中心 · 執行	有完整前端介面	8 個分頁，按權限顯示操作按鈕。頁面標題顯示「戰略中心 · 執行」；URL 仍係 `marketing/business_growth`。
Message 建立 Cohort 草稿	功能開關＋權限	真實按鈕、Preview 確認框及成功訊息；未有 Cohort 管理／派工 UI。
Mobile Growth Task Inbox	功能開關後可展示	目前只顯示健康狀態及「唯讀預覽」提示，未有任務操作列表。
Strategy Command Center	A1 人工閘（旗標＋權限）	可截圖：列表 WHAT／HOW／WHY、Preview／Execute／Pause／Stop／Retry。Execute 成功只顯示草稿 Program ID，不會自動 Publish／派 Task／發 outbound。
策略 Drilldown／Scenario／Planning／Learning	後端已備，UI 未上線	不可寫成現場操作步驟。
Program 審批拒絕	後端端點已有，UI 無按鈕	現有列表可提交、啟用、暫停、結束；不可教使用者在畫面按「拒絕」。
SMS／Email Review	Builder 可選，工作 UI 未完整	Program Builder 有渠道選項，但「我的工作」無 SMS／Email 專用操作流程。
Lumi Token 手動發放	後端已有，UI 無入口	不可當作收件箱或 Task 內現有按鈕介紹。
Inbox 進階篩選	API 支援較多條件	前端目前只顯示 Shop、Program、Signal、Stage、Status、Search。

截圖人員請留意（A1）：Command Center 僅在 strategy_command_center_enabled 及專屬 detail 權限下可見。 Execute 只建立 Program 草稿，畫面不可宣稱「已派 Task」或「已增加收入」。A2 自動 Publish／outbound 仍屬 roadmap，不可教成現況。

08B · 開通說明（必讀）

點解預設唔開？邊度開？邊啲有專屬 UI？

戰略中心 A1 刻意預設關閉。原因唔係未完成，而係安全：未準備資料結構、未授權、未做現場驗收之前，正式環境唔應自動出現接受／執行，亦唔應自動產生 Program 草稿。系統會自動分析，但唔會自動執行。

一句講清楚：而家有冇「全部設定都有專屬 UI」？

項目	有冇專屬設定畫面？	而家點開／點設定
戰略中心總開關、Workspace、Command Center 旗標	有產品內開通面板	New Dashboard → 戰略中心（旗標關時仍可見開通檢查表）；有 Policy Manage 可直接儲存三個安全旗標。後備：IT Asset → System Parameter（module=`strategy_performance`）。
Business Growth / Runner / Autonomy 等危險旗標	無專屬設定頁（刻意）	仍用 System Parameter（module=`business_growth`／`strategy_performance`）。A1 階段唔應喺 UI 一掣開 Runner／Autonomy。
Strategy Performance 細部權限	有 UI	權限設定 → New Dashboard（path `dashboard_new/index`）勾 detail。
New Dashboard「戰略中心」操作畫面	有 UI	旗標＋權限開咗之後，先喺 New Dashboard 見到分頁、建議、Command Center。
戰略中心 · 執行（日常操作）	有 UI	選單顯示「戰略中心 · 執行」。對應開關由實施團隊協助打開，預設關閉。
Autonomy／Runner／Cron 自動派工	刻意關閉	驗收階段保持關。唔好打開自動駕駛或自動派工做截圖捷徑。

第一次用嘅入口：請由 New Dashboard → 戰略中心 開始。呢個分頁會教你「自動分析 vs 人手執行」係咩、點開安全旗標、點用 Accept／Execute，以及點解 Autonomy／Runner 被鎖定。 Execute 之後先去「戰略中心 · 執行」處理草稿 Program。

開通步驟（照次序做）

準備資料結構（實施團隊）：建立所需設定，預設關閉新功能，不會覆蓋貴店已有值，亦不會自動授權。
授權：權限設定 → 搵 New Dashboard → 至少勾：
- Strategy Performance View：進入工作區
- Strategy Performance Policy Manage：可喺產品內開通面板改旗標（建議給 IT／營運負責人）
- 以及 Decide／Command View／Execute／Stop（按需要）
改完要重新登入。
開旗標（二選一）：
- 推薦：新儀表板 → 戰略中心開通面板 → 勾選工作區與指揮中心 → 儲存
- 後備：由實施／IT 在系統資訊協助打開對應開關
暫時保持關閉：自動駕駛、自動派工、實驗分派、建議解釋擴充。
去畫面驗：同一分頁就緒後會進入戰略中心決策台。Execute 成功只應見到草稿 Program ID。

見唔到畫面時點排查

症狀	最常見原因	去邊度查
New Dashboard 完全冇戰略中心分頁	workspace 旗標未開，或 View 無權限	System Parameter：`enabled`＋`strategy_performance_workspace_enabled`；權限：View
有分頁，但冇 Accept／Execute	Command Center 未開，或缺 Decide／Execute 權限	`strategy_command_center_enabled=1`；權限 Decide／Execute；重新登入
撳 Execute 403／失敗	CSRF、旗標、分店範圍、或 recommendation 已過期	重新整理頁面；確認分店權限；睇錯誤 reason
Execute 成功但以為已派工	誤解 A1 行為	只會建 draft Program；要另由獲授權人去 Growth Publish／Run

截圖 EN-01｜System Parameter 開旗標
IT Asset → System Parameter，篩選／搜尋 module=strategy_performance，標示 enabled、strategy_performance_workspace_enabled、strategy_command_center_enabled 三行 value=1。

截圖 EN-02｜權限 detail
權限設定 → New Dashboard，勾起 Strategy Performance 相關 detail；遮住真實員工姓名。

截圖 EN-03｜New Dashboard 開通後
戰略中心分頁同時見到三張卡、建議路線、Accept／Dismiss（如有權限）及 Command Center 區塊。

09 · 截圖前準備

開始操作之前，先完成呢份檢查表

呢一節係交畀實際操作及截圖人員。未完成前置設定，畫面可能完全看不到，或者只見空列表。

使用 UAT／示範環境
不要直接在正式環境建立示範 Program、Task 或 Cohort。 資料庫 Migration 已由負責人確認並執行
本教學不要求操作人員自行跑 migration。 戰略中心開關已開
到 IT Asset → System Parameter，module=strategy_performance：enabled=1、strategy_performance_workspace_enabled=1；若要示範 Accept／Execute，另開 strategy_command_center_enabled=1。詳見 08B。保持 recommendation_explain_enabled=0 除非要示範解釋掣。 Business Growth 已在 UAT 啟用
business_growth.enabled=1，帳號可進入 marketing/business_growth/index。如要示範真正 Program Run，另需由負責人確認 runner_enabled=1；只做 Builder／Preview 時不要為截圖開 Runner。 測試帳號已有所需細部權限
New Dashboard 下 Strategy Performance View／Decide／Command View／Execute／Stop（按教學需要）；Business Growth 相關 detail。改完重新登入。 準備去識別化示範資料
會員姓名、電話、電郵、員工姓名及金額須使用合成資料或遮罩。 瀏覽器縮放 100%
建議桌面寬度至少 1440px；先關閉通知及其他不相關分頁。

建議截圖帳號權限

教學用途	所需權限
看戰略中心分頁	Strategy Performance View
Accept／Dismiss 建議	Strategy Performance Recommendation Decide
睇 Command Center	Strategy Performance Command View
Execute／Retry Command	Strategy Performance Command Execute
Pause／Stop Command	Strategy Performance Command Stop
看「戰略中心 · 執行」頁面	Business Growth Center View
開始機會／做 Task／記結果	Business Growth Task Execute
指派機會	Business Growth Task Assign
建立／修改 Program	Business Growth Program Manage
啟用／暫停／結束 Program	Business Growth Program Publish
手動 Run／Retry	Business Growth Program Run
查看收入結果	Business Growth Performance View＋Member Spending View
匯出結果	Business Growth Export
Message 建立 Cohort	Program Manage＋Task Assign＋Business Growth 選單權限

08C · 人審閉環與安全閘

固定主鏈：建議 → 人 Accept → Command → 人 Execute → Draft → 人 submit／approve／publish

戰略中心支援人員決策，不是自動駕駛。分析由系統自動做；選擇同執行由人做。 A1 永遠只產出計劃與草稿；真正派工、聯絡客人、Publish Program 仍在「戰略中心 · 執行」，而且必須由獲授權人員完成。

步驟	誰做	畫面會發生甚麼	不會發生甚麼
睇 Readiness／建議	管理層／店長	看到數據可信度、建議路線、影響區間、統計證據（churn／需求／產能只作 why，唔當保證收入）	不會自動選路或派工；開頁唔會對全會員即時跑 logistic
Accept	有 Decide 權限的人	建立可見 Command（command_ready）	不會建立 Program、不會 Publish
Preview／Pause／Resume／Stop	Command View／Stop 權限	Command 分「進行中」與「已完成／終止」；Stop 後可再 Accept	Pause 不是刪除；Stop 不會自動再開 outbound
Execute／Retry	Command Execute 權限	只建立 Growth Program Draft，並可 deep-link 到 BG	不會派 Task、不會 WhatsApp／SMS、不會自動 Publish
BG submit／approve／publish	Program Manage／Publish（SoD）	人手審批後才成為可跑的 Program	建立者不可自己 Publish（SoD）

Day-1 三開關 vs 鎖定自動化

類型	項目	預設	有冇產品內 UI
Day-1（可開）	`enabled`、Workspace、Command Center	關	有：開通面板（需 Policy Manage）
可選、預設關	`recommendation_explain_enabled`、`experiment_assignment_enabled`	關	無產品內切換；開咗先有解釋掣／holdout assign。UAT 預設唔開
鎖定（無 UI）	`automation_unlock`、Autonomy、Growth Runner	關	無切換；開咗亦不應當成現況教學

安全閘：CSRF（同分頁可重用、失效只重試一次）、分店 scope fail-closed、Publish SoD、稽核寫入失敗即擋操作、Runner 另要 business_growth.enabled＋runner_enabled＋automation_unlock。 DLQ／partial resume 只處理可安全續跑的執行，不會跳過人審。

08D · 效能、完整性與操作安全

今次決策台實際改咗咩（唔誇大）

機會卡完整性收入機會改用全量 active signal 聚合（分店＋playbook），唔再只加總列表前 10 條建議。

已實現實收卡有 Business Growth Performance View＋Member Spending View 時，讀 Growth 歸因 rollup（direct＋assisted、扣 refund、排除 prepaid／observed）。mixed_currency 則不顯示數字。

增量卡隱藏規則未有 quality=ready 且 lift 非空、且 program shop_scope 覆蓋目前已選全部分店（或 selection_mode=all）時，UI 顯示「尚未可驗證」，唔出假數。就緒後只取最新一條，唔加總多個 program。

建議分頁列表 server pagination；開頁唔拉全量 grain。建議生成時附 churn／7 日需求／capacity 作統計證據（badge 仍係 descriptive）。

開頁效能Readiness 用 scoped EXISTS／watermark／短 TTL；churn 只喺 generate persist，禁止每次開 tab 對全會員即時 logistic。

解釋／實驗旗標「解釋呢條建議」同 holdout assign 預設關；開咗先有。Execute 仍然只出 Draft。

財務口徑不變：Direct／Assisted／Observed 分開；refund 從付款淨額扣減；prepaid consumption 不計入新增實收。三張卡 forbid_sum，不可相加。Retention 預設關閉。相關性 ≠ 因果。

限制與開通清單（仍要營運／IT 做）

由實施團隊準備資料結構（含偵測、保留、解釋與實驗開關定義）；本輪介紹不會代你執行。
授予新儀表板戰略中心及業務增長細部權限；升級不會自動授權。
在開通面板打開第一天需要的工作區開關；自動駕駛、建議解釋擴充與實驗分派維持關閉。
用固定劇本驗：大店機會卡、建議翻頁、停止→再接受→執行→草稿、增量顯示「尚未可驗證」、結果翻頁／匯出。

10 · 管理層教學

戰略中心決策台：開分頁 → 讀位置 → 讀三卡 → 揀建議 → Execute → Draft

管理人喺呢個畫面只做兩件事：選擇（Accept／Dismiss）同執行（Execute）。分析、排序、影響區間由系統預先算好。Execute 只會得到 Growth Program 草稿，之後要到「戰略中心 · 執行」繼續人審 submit／publish。

前置：帳號要有 New Dashboard 選單權限；模組總開關及 Workspace 開關必須已開。如果開關未開，「戰略中心」分頁會完全隱藏。畫面提示：「揀路線，然後執行。系統唔會自己發佈或派工。」

進入「New Dashboard」
由系統選單打開 New Dashboard，先確認頁面頂部可見分店選擇器及 Workspace 分頁列。

截圖 SP-01｜入口全景
保留頁面標題、分店選擇器及完整分頁列；用框標示「戰略中心」（LG key 仍係 Strategy Performance）。不要截到真實會員資料。
選擇要分析的分店
在頂部 dashboard_power 分店選擇器選擇示範分店。切換分店後，當前分頁會重新載入相應資料。

截圖 SP-02｜選擇分析範圍
截入分店選擇器已選值，但請使用「示範分店 A」等合成名稱。
點擊「戰略中心」
分頁初次打開會顯示骨架載入（skeleton），然後呈現目前位置／數據可信度、三張分開的指標卡、建議列表及（開通後）Command Center。開頁唔會對全會員即時跑 churn 模型。

截圖 SP-03｜載入狀態（可選）
只在要製作完整操作手冊時截；銷售介紹可略過。

第一步：先確認「目前位置」可信唔可信

「目前位置：數據可信度」會顯示資料狀態，以及可用 Signal、Baseline、Capacity 記錄數。如果狀態係「需要注意」或「尚未就緒」，代表部分導航依據不足；應先處理資料來源或容量資料，唔應只因為畫面有收入機會就立即擴大行動。產能未知時，建議優先分會下降並提示，但唔封鎖人選擇。

數據已就緒

核心資料檢查已通過，但仍要看各個 coverage 是否符合該 Program 需要。

數據需要注意

資料可部分使用，但有 stale、capacity unknown 等降級原因。

數據尚未就緒

核心 schema／lifecycle 等條件不足，應先修復資料基礎。

Signal Records

可供建議／機會識別的訊號記錄數。

Baseline Records

可用歷史轉化基線記錄數。

Capacity Records

可用產能記錄數；為 0 時不應聲稱已完成容量導航。

截圖 SP-04｜戰略中心「目前位置」
保留標題、說明、資料狀態及三張 Coverage 卡；如有降級，照實截圖並說明需要先處理資料。

戰略中心戰略執行 — 電腦戰略中心 · 戰略執行

戰略中心決策台：顯示目前位置、三張 Coverage 卡、建議路線及執行動作。

第二步：讀懂三張指標卡（不可相加）

卡片	代表意思	介紹時應點講
收入機會	由全量 active signal（分店＋playbook）影響中位數加總的描述區間，唔係列表前 10 條建議加總。	「用來比較優先次序，不是已收到的錢。」
已實現新增實收	有 Performance View＋Spending View 時，讀 Growth 歸因 rollup：direct＋assisted，扣 refund，排除 prepaid／observed。	缺權限時顯示「—」；mixed_currency 不顯示數字。真正明細仍可到「戰略中心 · 執行」成果／歸因核對。
已驗證增量淨實收	要有合格 holdout 實驗（quality=ready 且 lift 非空、shop_scope 覆蓋目前已選全部分店或 selection_mode=all）先可顯示；只取最新一條，唔加總多個 program。	未就緒顯示「尚未可驗證」，不要自行加上示例數字或宣稱已有增量結果。

截圖 SP-05｜三張指標卡
必須同時保留「三類數字分開、不可相加」的提示。增量未就緒要截到「尚未可驗證」，不可 P 成金額。

第三步：揀一條建議（選擇）

建議列表欄位：Playbook、收入驅動、目前樽頸、影響範圍、品質、動作。超過一頁時有上一頁／下一頁（server pagination）。展開詳情可見 bottleneck、限制、guardrails，以及統計證據提示（churn／需求／產能只作 why，唔保證 uplift）。

Playbook

代表建議類型，例如 lead_sla、service_due、inactive_90。

收入驅動

路線想改善的業務環節，例如 lead_to_paid、service_due_repeat。

目前樽頸

令整條收入路徑受限制的問題代碼。

影響範圍

由低至高的歷史估算區間，用於判斷優先級。

品質

資料是否足夠；quality 不是 ready 時 Accept 路徑會 disable。

Accept／Dismiss

同一個畫面的選擇動作。有待審建議時，主 CTA 係 Accept；Dismiss 係次動作。

畫面會明確提示：揀路線，然後執行。系統唔會自己發佈或派工。Accept 之後先有 Command；「解釋呢條建議」掣只在 recommendation_explain_enabled=1 時出現，預設關，只讀、不可代替 Accept。

截圖 SP-06｜建議路線
選擇至少有 2–3 條建議的示範分店。保留表頭、用法說明、Accept／Dismiss（若已開通）及完整一行；有翻頁就截 pager。不要將未開通權限的按鈕 P 成已存在；不要把解釋掣當預設畫面。

第四步：Execute（執行，只出 Draft）

有 ready Command 時，主 CTA 轉為 Execute。Pause／Stop／Retry 係次動作。Command 分「進行中」與「已完成／終止」。Execute 成功只顯示草稿 Program ID 及 deep-link（tab=programs&program_id&from=strategy_performance），文案唔講「已派工」。

截圖 SP-07｜Command Center
開通後截「進行中」與「已完成／終止」分組、四語狀態、hold_until、Preview／Execute／Pause／Resume／Stop／Retry。

截圖 SP-08｜Execute 後 Draft
必須見到草稿連結；不可改寫成「已派工」或「已增加收入」。下一步係開「戰略中心 · 執行」由另一授權人 submit／approve／publish（SoD：建立者不可自己 Publish）。

空資料／錯誤情況點處理？

冇建議時會顯示空狀態：可截作 empty state 教學。
冇 shop scope 或載入失敗時會顯示錯誤區塊：先檢查帳號分店範圍及 feature flag。
CSRF 失效時畫面會用四語提示並自動重試一次；不要叫使用者改資料庫。
未開 Command Center 或缺 Decide 權限時，Accept／Execute 會隱藏：以開通面板檢查表為準。
按鈕點擊後會 loading＋disable，防止重複提交。

11 · 執行中心教學

戰略中心 · 執行：由機會到結果的主工作區

呢度係日常執行核心（頁面標題顯示「戰略中心 · 執行」；URL 仍係 marketing/business_growth）。頁面頂部有「處理今日工作」主按鈕，並提供八個分頁：總覽、機會收件箱、我的工作、流程管道、Program／建立器、執行紀錄、成果／歸因、設定／健康狀態。

總覽畫面會顯示甚麼？

區塊	內容	管理用途
未完成機會	仍在 open／qualified／assigned／engaged／interested／booked／arrived／snoozed 的 Opportunity。	了解目前工作池有幾大。
今日到期工作	今日需要處理而仍未完成的 Task。	店長晨會安排人手。
有興趣等待預約	已到 interested，但未正式 booked。	找出「有意向但未落約」的樽頸。
已預約等待到店	已 booked，但未有 arrival。	留意提醒、No-show 及履約。
已完成到店機會	value class 屬 visit opportunity 並完成的機會。	看產能／到店挽回，不直接當新收入。
預付消耗	使用已付款療程／權益的結果。	看服務履約，同新增實收分開。
直接／輔助實收	有 Performance View＋Spending View 權限時才顯示。	按證據級別看付款結果。
流程漏斗	各 pipeline stage 的數量；階段可點入收件箱。	快速找出堆積位置。
訊號分佈	每個 signal、value class、數量及 won count。	了解目前主要機會來源。
獲派員工 SLA	員工 ID、active／overdue／completed task。	看工作是否集中或長期逾期。

由選單進入戰略中心 · 執行
打開路徑 marketing/business_growth/index。畫面頂部應見標題「戰略中心 · 執行」、功能說明及「處理今日工作」按鈕。

截圖 BG-01｜執行工作區首頁 Hero
完整保留標題、功能簡介、「處理今日工作」及下方八個分頁。

FIG-ops-02-workbench

電腦執行工作區首頁

執行工作區首頁 Hero：完整標題、功能簡介、「處理今日工作」及下方八個分頁入口。
確認手動 WhatsApp 提示
畫面明確提示 WhatsApp 為手動交接草稿。系統不會在背景自動發送，員工仍要在 WhatsApp 確認。

截圖 BG-02｜合規提示
突出「手動 WhatsApp」提示，產品介紹應將此表述為「保留人手最後確認」。
閱讀總覽指標
總覽會載入指標卡、Pipeline Funnel、Signal Breakdown 及 Assignee SLA。先用呢張圖講「管理層一眼睇晒工作量、來源及逾期情況」。

截圖 BG-03｜總覽全景
截入一排指標卡及三個分析區塊；示範資料要包含至少兩種 signal 及兩名負責人。

12 · 店長教學

機會收件箱：搵出今日最值得處理的人

「機會收件箱」支援按分店、Program、Signal、Pipeline Stage、狀態及關鍵字篩選。每條 Opportunity 會按權限提供操作圖示。

列表欄位	點樣理解
優先度	用於排序工作先後；不代表成交機率承諾。
會員／Lead	被評估的會員或潛在客；顯示內容受會員可見性權限控制。
分店	Opportunity 所屬店舖。
訊號原因	為何會進入收件箱，例如 90 日未回店、Lead SLA 逾期。
價值分類	new_revenue、visit_opportunity 或 prepaid_consumption。
階段	目前在 Opportunity、Interested、Booked、Arrived 等流程位置。
信心	資料及規則對該訊號的品質提示。
到期／時長	幾時應處理，用於 SLA 及逾期管理。
負責人	目前 owner／assignee。
最近接觸	避免未理解近期活動就重複聯絡。
下一步行動	系統建議的工作類型或後續動作。

點「機會收件箱」分頁
先不填篩選條件，按「搜尋」，確認列表能正常載入。

截圖 OP-01｜Opportunity 列表
保留篩選列、列表表頭及操作欄；電話、姓名需遮罩。
使用 Signal 或狀態縮窄名單
例如輸入 service_due，或者選擇一個 Pipeline Stage，再按「搜尋」。

截圖 OP-02｜篩選後結果
要同時截到已輸入的條件及縮窄後列表，方便讀者理解篩選作用。
按眼睛圖示查看詳情
詳情 Drawer 會顯示：可解釋證據、排除檢查、客戶摘要、來源時間線、建議行動、未完成任務及歸因結果。

截圖 OP-03｜Opportunity 詳情
優先截「可解釋證據」及「建議行動」，用來說明系統有保留訊號來源、時間線及相關結果。部分內容目前可能以結構化資料／JSON 形式顯示，不應形容成成熟自然語言 AI 解釋。
按需要開始跟進、延後、關閉或指派
- 播放圖示：開始跟進。
- 時鐘圖示：設定延後到期時間及原因。
- 叉號圖示：關閉機會，並填寫關閉原因。
- 人像加號：輸入負責員工 ID 作指派。
截圖 OP-04｜指派視窗
截「指派」Modal、員工 ID 欄及確認按鈕。

截圖 OP-05｜延後視窗
截「延後至」及「原因」欄，說明工作唔會因暫時未處理而消失。

操作按鈕受細部權限控制。只得 View 權限的帳號仍可看詳情，但不會看到開始／延後／排除／指派按鈕。

13 · 前線教學

我的工作：員工每日可以照住做

「我的工作」只列出當前登入員工的工作，避免前線面對全公司名單。可按狀態、今日到期／逾期及工作類型搜尋。

優先度

協助前線先處理較重要或較急的工作。

會員／Lead

工作對象；敏感資料按權限顯示。

工作類型

例如 call、manual_whatsapp、followup。

狀態

待處理、處理中、等待客戶等。

到期／時長

用來篩今日到期及已逾期。

下一步行動

前線應該做的具體方向。

由首頁按「處理今日工作」
系統會切換至「我的工作」。亦可直接點該分頁，再將到期條件選成「今日到期」或「已逾期」。

截圖 TK-01｜今日工作列表
截入狀態及到期篩選器、「重新整理」按鈕、工作列表與操作欄。
按播放圖示「開始工作」
當工作狀態為 pending／assigned 時會看到「開始工作」。成功後列表重新整理，狀態改為「處理中」。

截圖 TK-02｜工作由待處理轉為處理中
建議 cap 操作前及操作後各一張；兩張使用同一 Task ID。
按剔號記錄結果
「記錄結果」視窗可選：
- 無人接聽（no_answer）
- 感興趣（interested）
- 沒興趣（not_interested）
- 聯絡方式錯誤（wrong_contact）
- 稍後回電（call_back）
- 拒絕聯絡（opt_out）
- 已完成（completed）
如選「無人接聽」或「稍後回電」，必須填寫「下次跟進時間」；「聯絡方式錯誤」或「拒絕聯絡」需要在備註提供原因。

截圖 TK-03｜記錄結果視窗
截完整結果下拉、備註、下次跟進時間及「記錄結果」按鈕。
建立下一次 Follow-up
按時鐘圖示，選擇「下次跟進時間」，確認後系統建立 Follow-up。

截圖 TK-04｜建立 Follow-up
用未來日期，確保日期及時間清晰可讀。
手動 WhatsApp 交接（只限相關 Task）
當 Task 類型為 manual_whatsapp，會顯示 WhatsApp 圖示。點擊後打開手動草稿連結；員工要自行檢查內容及按發送。

截圖 TK-05｜手動 WhatsApp 提示
只截 SRP 內提示及按鈕；不要截真實 WhatsApp 對話或電話號碼。

14 · Program Builder 教學

用 7 個步驟建立一個可管理的增長 Program

Program 唔等於立即發訊息。它先定義目標、候選客訊號、排除規則、工作容量、派工方式、接觸渠道及歸因窗口，再 Preview 候選人數及排除情況。

建議第一次截圖使用簡單「90 日未活躍客人召回」示例。所有員工 ID、Shop ID、金額及會員資料必須使用 UAT 合成資料。

截圖人員可照填的完整合成示例

以下數值只為令整套截圖使用同一個 Program，並非所有企業都應採用的營運政策。真正上線前，SLA、容量、冷卻期、分店及員工範圍必須由客戶營運負責人確認。

Builder 步驟	欄位	截圖示例值	白話解釋
1｜目標與模式	Program 名稱	2026Q3 示範店｜90 日沉睡召回	列表會顯示的名稱。
	Objective	`winback_reactivation`	用來表示本 Program 目標係重新啟動沉睡會員。
	Mode	`continuous`	持續按規則掃描新符合條件的人；Runner 仍由獨立開關控制。
	Shop Scope	`101,102`	純合成 Shop ID，操作帳號必須有相應分店權限。
	Start At	2026-08-07 09:00	示範生效時間。
	End At	2026-12-31 23:59	示範完結時間。
2｜訊號	Signal	`inactive_90`	只勾「第一級未回店」，避免所有訊號同時啟用。
	Inactive First Threshold	`90`	約 90 日無近期付款活動才成為候選。
	Minimum Data Quality	`ready`	示範要求資料品質達可用狀態。
3｜排除及保護	Future Booking	勾選	已有未來正常預約的人不再召回。
	Opt-out	勾選	拒收／退出聯絡的人不進入工作。
	Program Conflict	勾選	避免同一會員同時進入衝突 Program。
	Service Recovery	勾選	未解決服務問題時先補救，唔急住銷售。
	Cooldown Hours	`72`	至少相隔 72 小時先再次接觸。
	Frequency Cap	`2`	指定窗口最多接觸兩次。
	Cap Window Hours	`168`	以七日作示範頻率窗口。
4｜評分及容量	Daily Task Cap	`40`	整個 Program 每日最多產生 40 個工作。
	Staff Task Cap	`8`	每位員工每日最多 8 個工作。
	Minimum Score	`0.35`	低於示範優先分數的人暫不進工作。
5｜指派及 SLA	Strategy	`holder_first`	優先交回原有負責人。
	SLA Hours	`24`	指派後 24 小時內開始處理。
	Escalation Hours	`48`	48 小時仍未處理就列入升級關注。
	Staff IDs	`1001,1002,1003`	純合成員工 ID。
	Daily Capacity	`15`	示範團隊每日可承接容量。
6｜接觸方式	Channels	`call`、`manual_whatsapp`	電話及人工 WhatsApp 草稿；不表示自動發送。
6｜接觸方式	Lumi Page	Off	本召回示例不建立 Lumi Page。
7｜歸因及預覽	Direct Window	`7` 日	示範直接證據的可接受時間距離。
	Assisted Window	`30` 日	示範輔助接觸窗口。
	Schedule	`0 9 * * *`	示範排程表達式；真正 cron 仍需維運人員確認及啟用。
	Timezone	`Asia/Hong_Kong`	避免排程因時區錯誤在不合適時間執行。

「Program／建立器」分頁 →「建立 Program」
只有 Business Growth Program Manage 權限先會看到建立按鈕。

截圖 PG-01｜Program 列表與建立按鈕
保留狀態、模式、搜尋及建立按鈕。
步驟 1：目標、模式及分店範圍

Program 名稱
例：示範－90 日未活躍會員召回

Objective
使用可識別代碼，例如 winback_reactivation

模式
continuous／scheduled／one_off

Shop Scope
輸入有權限的 Shop ID；多個 ID 以逗號分隔

開始／結束
按示範期間設定，結束時間必須晚於開始時間

截圖 PG-02｜Builder 第 1 步
所有必填欄已填；清楚截到上方 1–7 步導覽。
步驟 2：訊號及資料品質
勾選 inactive_90，並設定 threshold_days。其他可選訊號包括 interest_unconverted、booking_recovery、treatment_balance、service_due、second_visit、spend_drop、lead_sla 等。

截圖 PG-03｜訊號選擇
只勾本示例真正使用的訊號，避免教學畫面所有選項都勾上。
步驟 3：受眾及排除規則
建議示範勾選「排除未來預約」、「排除 Opt-out」及「Program 衝突」，再設定 Contact Cooldown／Frequency Cap。

截圖 PG-04｜保護規則
重點框出 Future Booking、Opt-out、Cooldown、Frequency Cap，呢張圖最能建立客戶信任。
步驟 4：評分及容量
設定每日 Task 上限、每位員工上限及最低優先分數。目的係避免一次產生過多工作，超過前線實際能力。

截圖 PG-05｜每日容量控制
使用合理示範數字，例如每日 30、每人 8；不要當作所有客戶的建議標準。
步驟 5：派工策略及 SLA

Holder First
優先交給原有手持／負責人。

Round Robin
按輪流方式分配到指定員工。

Shop Team
交由分店團隊處理。

SLA／Escalation
定義幾多小時內要跟及幾時升級。

截圖 PG-06｜派工及 SLA
要截到已選策略、員工 ID、SLA 小時及每日容量。
步驟 6：接觸渠道
可選手動 Call、手動 WhatsApp、SMS Review、Email Review 及 Lumi。WhatsApp 模式只會產生手動草稿，不會自動發送。

截圖 PG-07｜接觸渠道
示範選「手動 Call」＋「手動 WhatsApp」，並保留畫面上的人工確認提示。
步驟 7：歸因窗口及 Preview
設定 Direct Window、Assisted Window、Schedule Expression 及 Timezone，再按「預覽」。

Preview 會顯示候選人數、排除人數、預計每日 Task 及資料品質。首次 Preview 如 Program 未儲存，系統會先建立草稿。

截圖 PG-08｜Preview 結果
截入四張 Preview 指標卡及樣本列；確保候選與排除都有數字。
儲存、提交審批、啟用
按「儲存」後 Program 為 draft。列表中的操作視狀態及權限顯示：
- draft：編輯、複製、提交審批。
- pending_approval：有 Publish 權限者可啟用。
- active：可暫停、結束；有 Run 權限可手動執行。
- paused：可重新啟用或結束。
截圖 PG-09｜Program 狀態操作
用同一個示範 Program，截到狀態及右側可用操作圖示。

15 · CRM 交接教學

由 Message 篩選會員，建立獨立 Cohort 草稿

呢個入口適合行銷／CRM 已經用 Message Filter 揀出一批會員，先做合規排除並保存 Cohort 草稿。目前 Cohort 與 Business Growth Program／Task 之間尚未有可操作的 UI 串接，因此不能描述為「一按即派工」。

前置：manual_cohort_enabled=1，並有 Business Growth 選單、Program Manage 及 Task Assign 權限。開關關閉時按鈕完全不顯示。

進入 Message 會員篩選頁
按教學情境設定篩選條件，再執行搜尋。確認列表已有會員。

截圖 CH-01｜Message 篩選條件
截條件區及結果數量；所有會員資料需遮罩。
勾選要處理的會員
至少選擇數名示範會員；未選會員時按鈕會提示「請選擇會員」。
按「建立業績引擎 Cohort」
按鈕會暫時 disabled 並顯示 loading，系統先做 Preview，不會立即建立 Cohort。

截圖 CH-02｜「建立業績引擎 Cohort」按鈕
同時截入已選會員及按鈕位置，方便操作人員定位。
閱讀 Preview 確認框
確認框會顯示 selected、eligible、excluded。排除邏輯包括 Opt-out、未來有效預約及仍有效的舊 Call List。

截圖 CH-03｜Cohort Preview
截完整三個數字及「確認建立 Cohort 草稿？」提示。
確認建立草稿
按確認後系統只建立狀態為 draft 的 Cohort，成功訊息顯示 Cohort ID。取消則不建立；目前畫面沒有 Cohort 列表、詳情頁或「轉為 Program／Task」按鈕。

截圖 CH-04｜建立成功
截到「已建立 Cohort 草稿 #ID」；ID 可保留 UAT 示例值。

呢個功能不會改寫原有 Message 發送流程；它只新增「先 Preview、再保存 Cohort 草稿」的選擇。前端目前固定以空白 filter hash 及空 filter snapshot 建立草稿，所以不可宣稱可由 Cohort 追溯完整 Message 篩選條件。

16 · 結果及維運教學

Pipeline、Run、結果與健康度：完整檢視執行情況

Pipeline：機會而家去到邊？

Pipeline 顯示機會在不同階段的數量，並獨立顯示「預付核銷」lane，避免將已收過的預付消耗當作新增收入。

階段由已核實業務事件推進，而唔係由員工手動宣稱「已成交」。點擊某個階段後，系統會切到「機會收件箱」並帶入相應 Stage 篩選。

截圖 RV-01｜Pipeline 全景
必須截到主 Pipeline 及 Prepaid Consumption Lane 的說明。

Runs：Program 每次執行是否成功？

可按 Program、狀態、開始／結束日期搜尋。Run 狀態包括 queued、running、partial、completed、failed、skipped；可重試的失敗 Run 會顯示 Retry。

欄位	用途
執行 Run Key	用來識別及防止同一執行被重複處理。
Program 名稱	知道由哪套規則產生今次 Run。
類型	例如 manual 或 scheduled。
狀態	queued／running／partial／completed／failed／skipped。
開始時間／需時	判斷是否卡住或耗時異常。
數量摘要	候選、建立、排除等執行統計。
偵測器錯誤	指出哪個 detector 或資料來源出問題。

截圖 RV-02｜Run 歷史
準備至少一筆 completed 及一筆 failed／partial 合成資料，展示系統有可追溯性。

結果與歸因：活動有冇帶來實際結果？

有 Performance View＋Spending View 權限時，可按日期及 Program／Signal／Shop／Assignee／Channel 維度查結果。列表使用伺服器分頁；匯出讀全量聚合，不會靜默截斷。

Direct

有直接證據連到該機會／行動的結果。

Assisted

該工作有協助作用，但未必是唯一原因。

Observed

觀察到同期間結果，不併入 attributed total。

Incremental

只在合格實驗完成後顯示；未 ready 時隱藏。

結果欄位	管理含義
Breakdown	按 Program、Signal、Shop、Assignee 或 Channel 比較。
Direct Paid	有直接來源證據連到 Opportunity／Task 的付款。
Assisted Paid	窗口內有已確認接觸、但無更強直接來源的付款。
Observed Paid	同期觀察到但未有已確認接觸證據；不加入 attributed total。
Bookings	相關預約數，唔等於已到店或已付款。
Arrivals	已核實到店數。
Prepaid Consumption	已付款療程／權益的使用次數，唔係新增現金。

截圖 RV-03｜結果與歸因
保留日期、Breakdown 選擇、指標卡及歸因定義。若 Incremental 隱藏，不要自行加圖或數字。

設定與健康度：系統係咪準備好？

Health 分頁顯示 Program／資料來源／Runner 等健康資訊，並固定展示 WhatsApp 為 Manual Draft、Never Sent。

Enabled

Business Growth 總開關是否開啟。

Shadow Mode

是否只觀察而避免正式派工。

Runner Enabled

Program Runner 是否已由維運人員啟用。

Reconciliation

結果對帳程序是否準備好。

Data Foundation

資料是否 stale／degraded，以及相關原因。

Last Successful Run

最後一次成功執行時間。

Failure Alerts

連續失敗或需注意的 Run。

WhatsApp Mode

現時為 manual_draft，automatic=false。

截圖 RV-04｜健康度及 WhatsApp 模式
截健康卡及手動 WhatsApp 說明，用於介紹安全控制。

17 · 建議示範流程

由零開始，做一場 15–20 分鐘完整產品示範

以下次序適合銷售介紹、內部培訓及之後按步 cap 圖。所有示範應使用同一間 UAT 分店及同一個 Program 名稱。

用 SP-01／SP-04／SP-05／SP-06 開場
先介紹「戰略中心：系統自動分析，人只選擇同執行」，再確認數據可信度、三張卡不可混加、揀一條建議 Accept。
切到 BG-01／BG-03
展示 SRP 不只睇數，還有 Opportunity、Task、Pipeline 及 SLA。
用 PG-01 至 PG-08 建立 Program
以「90 日未活躍會員召回」示範 7 步 Builder 及 Preview。
用 OP-01 至 OP-05 做店長操作
篩選機會、看證據、指派一筆 Opportunity。
轉用前線帳號做 TK-01 至 TK-04
開始任務、記錄 interested 或 call_back、建立下次 Follow-up。
用 RV-01 至 RV-04 收尾
展示 Pipeline、Run、結果分類及健康度，重申 WhatsApp 手動確認及 prepaid 分流。

銷售講法建議：「SRP 唔係幫你一次過打更多客，而係幫你用正確理由、在正確時間，將正確客人交畀正確員工，並保留每一步結果。」

18 · FAQ

採購決策與操作時最常遇到的問題

採購前應先問清楚

我買的是整套 SRP，還是獨立業績引擎模組？

本文件只描述現有產品功能及操作，未包含商業授權組合。正式報價時應由供應方清楚列明：包含哪些 SRP 模組、分店／用戶範圍、導入服務、培訓、維護及後續支援，不能由本教學自行假設。

SRP 會唔會自動幫我增長營業額？

不會。戰略中心只提供可解釋建議與人審閉環：系統自動分析，人選擇同執行。Accept 只建立 Command；Execute 只建立 Program 草稿；Publish、派 Task、聯絡客人仍要人手。系統不保證收入上升，Incremental 必須有合格對照先可顯示。唔好講「全自動增長」。

現有 CRM、Message、Call List 或 Excel 要即時停用嗎？

不需要一開始全部取代。建議選一個 Program 做 Pilot，並行比較名單品質、SLA、結果紀錄及管理成本。Message 現有發送流程亦保持不變；Cohort 只是額外草稿入口。

最少需要哪些資料？

視 Signal 而定。一般需要可信的會員／Lead、分店、預約狀態、到店／療程、付款及 Opt-out 資料。service_due 需要足夠歷史服務樣本；spend_drop 依賴期間彙總；資料不足時不應勉強啟用。

由開始導入到第一個 Program 要幾耐？

本文件不承諾固定日數。時間取決於 migration、資料品質、權限、Program 規則、UAT、前線容量及內部審批。較安全做法是按「Readiness → Preview／Shadow → 單店 Pilot → Review → 擴大」逐階段驗收。

收費、試用、合約期及服務 SLA 是甚麼？

呢啲屬商業條款，現有程式碼及本 H5 無足夠證據，必須由正式報價、服務合約及支援文件回答。本介紹不應自行填寫價錢、上線時間、uptime 或支援承諾。

單店是否值得用？

如果單店已有一定會員／交易歷史、多位前線、固定跟進場景及管理責任，仍可能有價值；如果資料量很少、每日只需人手處理幾個客、亦無人負責 Task，導入效益可能有限。應先用一個小 Pilot 評估。

如何計算 Pilot 是否值得繼續？

先在上線前記錄同口徑 baseline，再比較執行、轉換、財務及風險指標。可供管理討論的簡化公式是：Pilot ROI =（經確認的額外毛利或可量度節省 − 導入及營運成本）÷ 導入及營運成本。未有合格對照時，歸因實收不應直接當作因果增量。

上線前應記錄哪些 Baseline？

至少包括：每週候選量、漏跟／逾期率、平均首次跟進時間、成功接觸率、預約率、預約到店率、Opt-out／投訴、前線每日容量、相同場景的付款結果及資料缺失率。所有分母、期間及分店範圍要固定。

收入沒有明顯增加，是否代表 Pilot 失敗？

不一定。第一階段亦可驗收逾期下降、重複聯絡下降、資料品質改善、結果紀錄完整、預約到店流程改善及前線採用率。但如果長期只有工作量增加、無營運或客戶結果改善，就不應盲目擴大。

操作及目前版本限制

點解 New Dashboard 冇「戰略中心」分頁？

總開關或 Workspace 開關未開，或者功能資料表未準備好，又或者未有 Strategy Performance View 權限。呢個分頁在關閉時係完全隱藏，屬正常安全設計。開啟方法見 08B：IT Asset → System Parameter（module=strategy_performance）＋權限設定。顯示名係「戰略中心」，權限 detail 英文名不變。

點解增量卡顯示「尚未可驗證」而唔係金額？

增量只在實驗 quality=ready、absolute_lift 非空、且 program shop_scope 覆蓋目前已選全部分店（或 selection_mode=all）時先顯示；只取最新一條，唔加總。未達標就顯示「尚未可驗證」，避免把估算當因果。已實現實收卡則在有 Performance View＋Spending View 時讀 Growth rollup；缺權限顯示「—」；mixed_currency 不顯示數字。

點解策略建議列表冇 Accept／Execute？

需要同時開啟 Strategy Performance／Command Center 旗標，並授予專屬 detail 權限（例如 Recommendation Decide、Command Execute）。未授權時 UI 隱藏動作、後端回 403。即使有權限，Execute 也只建立 Growth Program 草稿，不會自動 Publish 或派 Task。逐步開通見 08B。

點解 Execute 只出 Draft？

這是產品契約：分析自動、執行唔自動。Execute 只建立 Growth Program 草稿並可 deep-link 到「戰略中心 · 執行」。Publish、派 Task、outbound 必須由另一授權人完成（建立者不可自己 Publish）。

「解釋呢條建議」點解睇唔到？

旗標 recommendation_explain_enabled 預設 0。開咗先出現掣；只讀既有建議內容，不可寫入、不可代替 Accept／Execute。UAT 預設唔開，唔好當現況教學必截圖。

點解唔預設開埋？係咪所有設定都有 UI？

預設關閉係 fail-closed 安全設計，避免未 UAT 就自動出現 Execute／草稿。Day-1 三旗標有開通面板；解釋／實驗 assign／Autonomy／Runner 冇產品內一掣全開。權限同操作畫面就有 UI。

點解 Business Growth 某啲按鈕唔見咗？

按鈕會按細部權限及資料狀態顯示，例如只有 draft 才有提交審批；只有 active Program 才有手動 Run。

點解記錄 no_answer／call_back 時不能提交？

必須填寫下一次跟進時間，確保工作有下一步而唔係無聲消失。

系統會自動發 WhatsApp 嗎？

目前係 Manual Draft／Manual Handoff。系統打開草稿，最後內容及發送由員工確認。

Message Cohort 點解排除咗部分人？

系統 fail-closed 檢查 Opt-out、未來有效預約及舊 Call List，以減少重複聯絡及合規風險。

預付療程核銷會計成新增收入嗎？

不會。Pipeline 有獨立 Prepaid Consumption Lane，結果匯總亦不會將 prepaid consumption 當 new paid。

19 · 截圖交付清單

建議最終截圖編號及用途

EN-01System Parameter 開 strategy_performance 旗標

EN-02New Dashboard Strategy Performance 細部權限

EN-03開通後 New Dashboard 戰略中心全景

SP-01New Dashboard 入口及「戰略中心」分頁

SP-04戰略中心「目前位置」及數據可信度

SP-05三張 Executive 指標卡＋不可相加；增量未就緒顯示「尚未可驗證」

SP-06建議路線＋Accept／Dismiss（開通後）；有則截分頁

SP-07Command Center 分組＋Pause／Resume／Stop／Retry

SP-08Execute 後 Draft deep-link（from=strategy_performance），不可寫成已派工

BG-01「戰略中心 · 執行」首頁、「處理今日工作」及八個分頁

BG-03總覽指標、Pipeline、Signal、SLA

OP-01Opportunity 篩選及列表

OP-03Opportunity 可解釋詳情

OP-04指派員工視窗

TK-01「我的工作」今日到期列表

TK-03記錄任務結果視窗

TK-04建立下次 Follow-up

PG-02Program Builder 第 1 步

PG-03訊號選擇

PG-04受眾排除及保護規則

PG-06派工策略、SLA、容量

PG-08Program Preview 指標

CH-02Message「建立業績引擎 Cohort」入口

CH-03Cohort Preview 確認框

RV-01Pipeline＋Prepaid Lane

RV-03結果與歸因

RV-04Health＋Manual WhatsApp 模式

每張圖交付前檢查：沒有真實姓名、電話、電郵、會員編號、員工個資、正式金額或環境網址；圖中按鈕及標題必須與當前版本一致；不要以設計稿冒充系統畫面。