化工作流實(shí)戰(zhàn):HubSpot / Salesforce / 調(diào)度工具 / Zapier 跨平臺(tái) Playbook 全解析(marketingskills 倉(cāng)庫(kù)))
AI 技能人工智能【免費(fèi)下載鏈接】marketingskillsMarketing skills for Claude Code and AI agents. CRO, copywriting, SEO, analytics, and growth engineering.項(xiàng)目地址https://gitcode.com/GitHub_Trending/mar/marketingskills點(diǎn)擊查看免費(fèi)下載本篇技術(shù)指南圍繞 marketingskills 倉(cāng)庫(kù)中 RevOps 技能模塊 的核心參考資料 automation-playbooks.md 展開(kāi)系統(tǒng)梳理 HubSpot、Salesforce、Calendly/SavvyCal 與 Zapier 四類平臺(tái)的自動(dòng)化工作流配方。你將掌握 MQL 告警與分配、SLA 升級(jí)、線索評(píng)分晉級(jí)、會(huì)議預(yù)訂通知、成交交接、失效商機(jī)告警、回收線索再培育等 18 套可落地的 Playbook 設(shè)計(jì)并理解如何在 CRM 中結(jié)合生命周期階段定義、路由規(guī)則與計(jì)分模型將其真正跑通。一、為什么 RevOps 需要「平臺(tái)級(jí)自動(dòng)化 Playbook」RevOps收入運(yùn)營(yíng)的核心目標(biāo)是把市場(chǎng)、銷售與客戶成功連成一臺(tái)統(tǒng)一的收入引擎。SKILL.md 中明確了四條核心原則單一事實(shí)來(lái)源以 CRM 為權(quán)威主數(shù)據(jù)源、先定義后自動(dòng)化先把階段定義、計(jì)分標(biāo)準(zhǔn)、路由規(guī)則寫清楚再建流程、度量每一次交接市場(chǎng)→銷售、SDR→AE、AE→CS 每道交接都要有 SLA 與追蹤機(jī)制、收入團(tuán)隊(duì)對(duì)齊三團(tuán)隊(duì)對(duì) MQL/SQL 的定義必須一致。這些原則落地到具體工具時(shí)就需要一份「平臺(tái)特定工作流配方」——即本文的主角 automation-playbooks.md。它把重復(fù)出現(xiàn)的業(yè)務(wù)模式MQL 分配、SLA 告警、成交交接……翻譯成 HubSpot Workflow、Salesforce Flow、調(diào)度工具集成與 Zapier 跨工具自動(dòng)化四類可直接照抄的配方并與 生命周期階段定義、路由規(guī)則、計(jì)分模型 三份兄弟文檔構(gòu)成完整閉環(huán)。二、HubSpot Workflow 配方8 個(gè)以下配方在 HubSpot 中通過(guò)Automation → Workflows構(gòu)建每個(gè)配方都給出觸發(fā)條件、動(dòng)作序列、期望結(jié)果與注意事項(xiàng)??山Y(jié)合倉(cāng)庫(kù)中 hubspot.md 記錄的關(guān)鍵對(duì)象Contacts/Companies/Deals與常用屬性lifecyclestage、hs_lead_status、dealstage等來(lái)映射字段。1. MQL 告警與分配要素內(nèi)容名稱MQL Notification and Task Creation觸發(fā)條件聯(lián)系人生肖屬性「Lifecycle Stage」變?yōu)椤窶arketing Qualified Lead」動(dòng)作① 在銷售團(tuán)隊(duì)中輪轉(zhuǎn)round-robin分配聯(lián)系人所有者 → ② 發(fā)送內(nèi)部郵件給所有者并附上線索上下文 → ③ 創(chuàng)建任務(wù)「Follow up with [Contact Name]」4 小時(shí)內(nèi)到期 → ④ 發(fā)送 Slack 通知到#sales-alerts頻道 → ⑤ 加入「MQL Follow-Up」序列如使用 HubSpot Sequences結(jié)果每個(gè) MQL 都被即時(shí)分配并帶明確 SLA注意事項(xiàng)設(shè)置 enrollment criteria排除已被銷售代表持有的線索關(guān)于 round-robin 的實(shí)現(xiàn)細(xì)節(jié)可參考 routing-rules.md 中的兩種做法一是直接用 HubSpot 自帶的 rotation 工具觸發(fā)「Lifecycle Stage 等于 MQL」選擇「Even distribution、skip unavailable owners」再加延遲與任務(wù)創(chuàng)建二是自定義 rotation創(chuàng)建數(shù)值屬性「Rotation Counter」按計(jì)數(shù)值分支到不同代表遞增計(jì)數(shù)到最大值歸零最后創(chuàng)建帶 SLA 截止時(shí)間的跟進(jìn)任務(wù)。2. MQL SLA 升級(jí)要素內(nèi)容名稱MQL SLA Breach Alert觸發(fā)條件「Lifecycle Stage」等于「MQL」且「Days since last contacted」大于 0.5即 12 小時(shí)動(dòng)作① 郵件提醒當(dāng)前所有者「SLA warning: [Contact Name] has not been contacted」→ ② 若 24 小時(shí)后仍無(wú)活動(dòng)告警銷售經(jīng)理 → ③ 若 48 小時(shí)后仍無(wú)活動(dòng)按輪轉(zhuǎn)規(guī)則重新分配所有者 → ④ 為新所有者創(chuàng)建任務(wù)「Urgent: Contact [Contact Name] — reassigned due to SLA breach」結(jié)果沒(méi)有任何 MQL 超過(guò) 48 小時(shí)無(wú)人跟進(jìn)注意事項(xiàng)排除 last activity type 為「Call」或「Meeting」的聯(lián)系人已在互動(dòng)中此配方與 lifecycle-definitions.md 中「MQL-to-SQL SLA」模板完全呼應(yīng)首次聯(lián)系目標(biāo) 4 個(gè)業(yè)務(wù)小時(shí)內(nèi)、資格判定 48 小時(shí)內(nèi)超時(shí)自動(dòng)升級(jí)到銷售經(jīng)理。建議在配方的「SLA 計(jì)時(shí)」基礎(chǔ)上疊加 routing-rules.md 中的速度響應(yīng)升級(jí)鏈5 分鐘提醒原代表 → 15 分鐘提醒后備代表 → 30 分鐘提醒經(jīng)理 → 60 分鐘重新分配。3. 線索評(píng)分更新與 MQL 晉級(jí)要素內(nèi)容名稱Auto-MQL on Score Threshold觸發(fā)條件聯(lián)系人屬性「HubSpot Score」大于等于 65動(dòng)作① 設(shè)置生命周期階段為「Marketing Qualified Lead」→ ② 設(shè)置「MQL Date」為當(dāng)前日期 → ③ 從市場(chǎng)培育工作流中抑制 → ④ 觸發(fā)配方 #1 的 MQL 告警工作流結(jié)果線索達(dá)到計(jì)分閾值后自動(dòng)晉級(jí)為 MQL注意事項(xiàng)添加現(xiàn)有客戶與競(jìng)爭(zhēng)對(duì)手的抑制列表閾值 65 分并非拍腦袋。參考 scoring-models.mdMQL 必須同時(shí)滿足「fit契合度 engagement參與度」例如 PLG 模型的 65 分閾值、Sales-Led 企業(yè)模型的 75 分閾值、中端混合模型的 60 分閾值。其中計(jì)分信號(hào)demo 請(qǐng)求 30、定價(jià)頁(yè)訪問(wèn) 20、試用注冊(cè) 25 等與負(fù)向信號(hào)競(jìng)爭(zhēng)對(duì)手域名 -50、學(xué)生郵箱 -30、垃圾投訴 -100都建議納入 HubSpot Score 的配置并遵循「季度校準(zhǔn)」節(jié)奏——用歷史成交數(shù)據(jù)驗(yàn)證模型能否識(shí)別過(guò)去的贏單。4. 會(huì)議預(yù)訂通知要素內(nèi)容名稱Meeting Booked Alert to AE觸發(fā)條件為聯(lián)系人記錄了會(huì)議活動(dòng)經(jīng) Calendly/HubSpot meetings動(dòng)作① 發(fā)送內(nèi)部郵件給所有者并附上會(huì)議詳情 → ② 更新聯(lián)系人屬性「Last Meeting Booked」為當(dāng)前日期 → ③ 若生命周期階段為「Lead」更新為「MQL」→ ④ 創(chuàng)建任務(wù)「Prepare for meeting with [Contact Name]」會(huì)議前 1 小時(shí)到期 → ⑤ 發(fā)送 Slack 通知到#meetings頻道結(jié)果AE 對(duì)每場(chǎng)會(huì)議都有完整上下文準(zhǔn)備注意事項(xiàng)在通知郵件中附帶近期頁(yè)面瀏覽與內(nèi)容下載記錄5. 成交交接至 CS要素內(nèi)容名稱Customer Onboarding Trigger觸發(fā)條件商機(jī)階段變?yōu)椤窩losed Won」動(dòng)作① 更新關(guān)聯(lián)聯(lián)系人的生命周期階段為「Customer」→ ② 設(shè)置「Customer Since」日期為當(dāng)前日期 → ③ 按細(xì)分/區(qū)域?qū)⒙?lián)系人所有者分配給 CS 團(tuán)隊(duì)成員 → ④ 為 CS 創(chuàng)建任務(wù)「Schedule kickoff call with [Company Name]」2 個(gè)業(yè)務(wù)日內(nèi)到期 → ⑤ 將聯(lián)系人加入「Customer Onboarding」郵件序列 → ⑥ 通知 CS 經(jīng)理 → ⑦ 從所有銷售序列中移除結(jié)果從銷售到客戶成功無(wú)縫交接注意事項(xiàng)在 CS 通知中包含商機(jī)備注、合同金額與關(guān)鍵干系人此配方與 lifecycle-definitions.md 中 Customer 階段的進(jìn)入動(dòng)作觸發(fā) onboarding 序列、分配 CS 經(jīng)理、安排 kickoff 電話、從所有銷售序列移除逐一對(duì)應(yīng)可直接照搬。6. 失效商機(jī)告警要素內(nèi)容名稱Pipeline Hygiene — Stale Deal Detection觸發(fā)條件商機(jī)屬性「Days in current stage」大于 [該階段平均天數(shù)的 2 倍]動(dòng)作① 郵件提醒商機(jī)所有者「Deal stale alert: [Deal Name] has been in [Stage] for [X] days」→ ② 創(chuàng)建任務(wù)「Update or close [Deal Name]」3 個(gè)業(yè)務(wù)日內(nèi)到期 → ③ 若 7 天后仍無(wú)更新告警銷售經(jīng)理 → ④ 加入「Stale Deals」儀表盤列表結(jié)果管線保持干凈、預(yù)測(cè)保持準(zhǔn)確注意事項(xiàng)按階段定制閾值Discovery14 天Proposal10 天Negotiation21 天7. 回收線索再培育要素內(nèi)容名稱MQL Recycling to Nurture觸發(fā)條件聯(lián)系人屬性「Sales Rejection Reason」有任意值動(dòng)作① 更新生命周期階段為「Recycled」→ ② 將參與度分?jǐn)?shù)重置為基線保留 fit 分?jǐn)?shù)→ ③ 加入「Recycled Lead Nurture」序列較低頻率→ ④ 設(shè)置「Recycle Date」為當(dāng)前日期 → ⑤ 設(shè)置重新觸發(fā)條件若 HubSpot Score 再次超過(guò)閾值重新觸發(fā) MQL 工作流結(jié)果被拒絕的線索獲得第二次機(jī)會(huì)且不堵塞管線注意事項(xiàng)單獨(dú)追蹤 recycled-to-MQL 轉(zhuǎn)化率指標(biāo)關(guān)于回收原因代碼lifecycle-definitions.md 提供了完整編碼體系FIT-01公司太小培育并在公司成長(zhǎng)后重新計(jì)分、FIT-02行業(yè)不符歸檔不回收、ENG-013 次嘗試無(wú)回應(yīng)90 天后回收培育、QUAL-02使用競(jìng)品被鎖定在續(xù)約前觸發(fā)等。回收培育序列建議雙周/月度低頻觸達(dá)、時(shí)長(zhǎng) 6 個(gè)月無(wú)參與則歸檔并以「demo 請(qǐng)求、定價(jià)頁(yè)回訪」等高意圖動(dòng)作作為再 MQL 觸發(fā)點(diǎn)。8. 線索活動(dòng)摘要要素內(nèi)容名稱Daily Lead Activity Summary觸發(fā)條件定時(shí)——每天本地時(shí)間 8:00 AM動(dòng)作① 篩選生命周期階段為「SQL」或「Opportunity」且過(guò)去 24 小時(shí)有網(wǎng)站活動(dòng) → ② 向每個(gè)線索所有者發(fā)送其線索活動(dòng)摘要郵件 → ③ 內(nèi)容包括訪問(wèn)過(guò)的頁(yè)面、下載的內(nèi)容、打開(kāi)/點(diǎn)擊的郵件結(jié)果銷售代表每天開(kāi)工即知哪些線索活躍注意事項(xiàng)只包含有意義的活動(dòng)排除單一首頁(yè)訪問(wèn)三、Salesforce Flow 等價(jià)實(shí)現(xiàn)4 套對(duì)于使用 Salesforce 的企業(yè)automation-playbooks.md 給出了與 HubSpot 配方一一對(duì)應(yīng)的 Flow 實(shí)現(xiàn)??山Y(jié)合 salesforce.md 中的關(guān)鍵對(duì)象Lead/Contact/Account/Opportunity/Case/Campaign與 SOQL 查詢能力來(lái)理解數(shù)據(jù)流。1. MQL 告警與分配Record-Triggered Flow要素內(nèi)容類型記錄觸發(fā)流Record-Triggered Flow對(duì)象Lead觸發(fā)條件Lead 字段「Status」變?yōu)椤窶QL」流程步驟① Get Records查詢自定義對(duì)象「Rep Assignment」獲取下一位可用代表 → ② Update Records將 Lead Owner 設(shè)為被分配代表 → ③ Create Records創(chuàng)建任務(wù)「Contact MQL: {Lead.Name}」到期時(shí)間 NOW 4 小時(shí) → ④ Action向新所有者發(fā)送郵件告警 → ⑤ Update Records更新「Rep Assignment」的 last-assigned 時(shí)間戳注意事項(xiàng)用自定義「Rep Assignment」對(duì)象維護(hù) round-robin 狀態(tài)這與 routing-rules.md 中「Salesforce 高級(jí)路由」的 Flow 方案一致Record-Triggered Flow 自定義「Rep Queue」對(duì)象查詢下一位代表 Decision 元素檢查可用性/容量/區(qū)域 創(chuàng)建帶 SLA 的任務(wù) 更新隊(duì)列記錄。2. SLA 升級(jí)Scheduled-Triggered Flow要素內(nèi)容類型定時(shí)觸發(fā)流Scheduled-Triggered Flow調(diào)度業(yè)務(wù)時(shí)間內(nèi)每 4 小時(shí)流程步驟① Get Records查找 Status MQL 且 LastActivityDate TODAY - 1 的 Lead → ② Decision線索是否超過(guò) 48 小時(shí)無(wú)活動(dòng)→ YES重新分配給下一位代表、創(chuàng)建緊急任務(wù)、告警經(jīng)理NO向當(dāng)前所有者發(fā)送提醒郵件注意事項(xiàng)與 Process Builder 配合實(shí)現(xiàn)初始分配時(shí)的實(shí)時(shí)告警3. 管線階段自動(dòng)化Record-Triggered Flow要素內(nèi)容類型記錄觸發(fā)流對(duì)象Opportunity觸發(fā)條件Stage 字段更新流程步驟① Decision判斷變更到了哪個(gè)階段 → ② 每個(gè)階段對(duì)應(yīng)動(dòng)作Discovery創(chuàng)建任務(wù)「Complete discovery questionnaire」Demo創(chuàng)建任務(wù)「Prepare demo environment」Proposal創(chuàng)建任務(wù)「Send proposal」 若 ACV $25K 告警 deal deskClosed Won觸發(fā) CS 交接創(chuàng)建 Case、分配 CS 所有者、發(fā)送歡迎郵件Closed Lost創(chuàng)建任務(wù)「Log loss reason」 加入贏/輸分析報(bào)告「ACV $25K 走 deal desk」與 SKILL.md 中 Deal Desk 章節(jié)的「ACV 超過(guò) $25K 即觸發(fā)非標(biāo)準(zhǔn)商機(jī)審查」閾值一致審批層級(jí)標(biāo)準(zhǔn)定價(jià)自動(dòng)通過(guò)、10–20% 折扣銷售經(jīng)理審批、20–40% 折扣 VP Sales 審批、40% 或自定義條款走 deal desk、多年期/企業(yè)級(jí)走財(cái)務(wù)法務(wù)可作擴(kuò)展參考。4. 失效商機(jī)檢測(cè)Scheduled-Triggered Flow要素內(nèi)容類型定時(shí)觸發(fā)流調(diào)度每天 7:00 AM流程步驟① Get RecordsDays_In_Stage Stage_SLA_Threshold 的未關(guān)閉 Opportunity → ② 循環(huán)處理創(chuàng)建任務(wù)「Update stale deal: {Opportunity.Name}」、發(fā)郵件給所有者、若 Days_In_Stage 2 倍閾值則發(fā)郵件給所有者的經(jīng)理 → ③ 更新自定義字段「Stale Flag」 true便于儀表盤可見(jiàn)四、Calendly / SavvyCal 調(diào)度集成模式調(diào)度工具是「會(huì)議預(yù)訂通知」「成交交接」等 CRM 配方的數(shù)據(jù)來(lái)源。倉(cāng)庫(kù)中的 calendly.md 提供invitee.created/invitee.canceled等 webhook 事件訂閱、scheduled_events/invitees查詢接口savvycal.md 則提供event.created/event.canceled事件與scheduling-links管理接口。輪轉(zhuǎn)會(huì)議調(diào)度Calendly 設(shè)置創(chuàng)建包含所有合格代表的團(tuán)隊(duì)事件類型分配方式「Optimize for equal distribution」可用性每位代表管理自己的日歷緩沖會(huì)議前后各 15 分鐘最短通知時(shí)間4 小時(shí)避免臨期預(yù)訂CRM 集成Calendly webhook 在預(yù)訂時(shí)觸發(fā)用 invitee 郵箱匹配 CRM 聯(lián)系人若聯(lián)系人存在 → 將會(huì)議分配給聯(lián)系人所有者已持有則覆蓋輪轉(zhuǎn)若為新聯(lián)系人 → 創(chuàng)建線索、按路由規(guī)則分配、記錄會(huì)議設(shè)置生命周期階段為 MQL會(huì)議 高意圖SavvyCal 設(shè)置相對(duì) Calendly 的優(yōu)勢(shì)基于優(yōu)先級(jí)的調(diào)度優(yōu)先某些時(shí)間段日歷疊加單視圖展示團(tuán)隊(duì)可用性每位代表的個(gè)性化預(yù)訂鏈接集成模式創(chuàng)建帶優(yōu)先級(jí)規(guī)則的團(tuán)隊(duì)調(diào)度鏈接預(yù)訂 webhook → Zapier/Make → CRM匹配或創(chuàng)建聯(lián)系人、分配所有者、創(chuàng)建任務(wù)發(fā)送含會(huì)議準(zhǔn)備材料的確認(rèn)信息按條件路由會(huì)議Booking form submitted ├─ Company size 500? (form field) │ ├─ YES → Route to enterprise AE calendar │ └─ NO ↓ ├─ Existing customer? (CRM lookup) │ ├─ YES → Route to account owners calendar │ └─ NO ↓ └─ Round-robin across SDR team這與 routing-rules.md 的核心原則一致——「先命中具體規(guī)則再回退到通用規(guī)則」并且支持按公司規(guī)模SMB 1–50 人 / 中端 51–500 人 / 企業(yè) 501–5000 人 / 戰(zhàn)略 5000 人構(gòu)建完整的分層路由樹(shù)。缺席No-Show工作流要素內(nèi)容觸發(fā)條件會(huì)議時(shí)間已過(guò)且 30 分鐘內(nèi)未記錄會(huì)議備注動(dòng)作① 等待會(huì)議時(shí)間后 30 分鐘 → ② 檢查是否記錄了電話或會(huì)議→ 是無(wú)操作否發(fā)送「Sorry we missed you」郵件 → ③ 創(chuàng)建任務(wù)「Reschedule with [Contact Name]」下一個(gè)工作日到期 → ④ 若第二次缺席標(biāo)記聯(lián)系人并告警經(jīng)理五、Zapier 跨工具模式6 個(gè)Zapier 是跨工具粘合劑將 CRM、Slack、郵件、廣告、分析平臺(tái)連接起來(lái)。倉(cāng)庫(kù)中的 zapier.md 顯示其 SDKzapier/zapier-sdk支持 8000 應(yīng)用集成Agent 可直接調(diào)用zapier.apps.hubspot().createContact()、zapier.apps.slack().sendChannelMessage()等方法也可用 WebhooksPOST https://hooks.zapier.com/hooks/catch/{webhook_id}/接收或發(fā)送數(shù)據(jù)。1. 新線索 → CRM Slack 任務(wù)要素內(nèi)容觸發(fā)條件新表單提交Typeform、HubSpot、Webflow動(dòng)作① 在 CRM 中創(chuàng)建/更新聯(lián)系人 → ② 用 Clearbit 富化如可用→ ③ 將富化數(shù)據(jù)發(fā)布到 Slack#new-leads→ ④ 在項(xiàng)目管理工具Asana、Linear中創(chuàng)建任務(wù)2. 會(huì)議預(yù)訂 → CRM 準(zhǔn)備郵件要素內(nèi)容觸發(fā)條件新的 Calendly/SavvyCal 預(yù)訂動(dòng)作① 查找或創(chuàng)建 CRM 聯(lián)系人 → ② 更新生命周期階段為 MQL → ③ 向被分配代表發(fā)送準(zhǔn)備郵件含 CRM 鏈接、LinkedIn 主頁(yè)、近期活動(dòng)→ ④ 創(chuàng)建會(huì)前任務(wù)3. 成交 → Onboarding 技術(shù)棧要素內(nèi)容觸發(fā)條件CRM 商機(jī)階段變?yōu)椤窩losed Won」動(dòng)作① 在 CS 工具Vitally、Gainsight、ChurnZero中創(chuàng)建客戶記錄 → ② 加入 onboarding 項(xiàng)目模板 → ③ 通過(guò)郵件工具發(fā)送歡迎郵件 → ④ 創(chuàng)建 Slack 頻道#customer-[company-name]→ ⑤ 在 Slack 中通知 CS 團(tuán)隊(duì)4. 線索計(jì)分 → 跨工具同步要素內(nèi)容觸發(fā)條件CRM 線索分?jǐn)?shù)跨越 MQL 閾值動(dòng)作① 更新?tīng)I(yíng)銷自動(dòng)化平臺(tái)狀態(tài) → ② 加入再營(yíng)銷受眾Facebook、Google Ads→ ③ 觸發(fā) SDR 外呼序列 → ④ 在分析工具M(jìn)ixpanel、Amplitude中記錄事件5. SLA 違規(guī) → 多渠道告警要素內(nèi)容觸發(fā)條件CRM 任務(wù)逾期MQL 跟進(jìn)任務(wù)動(dòng)作① 發(fā)送 Slack DM 給代表 → ② 發(fā)送郵件給代表 → ③ 若逾期 2 小時(shí)Slack DM 給經(jīng)理 → ④ 若逾期 4 小時(shí)通過(guò) webhook 回寫 CRM 重新分配6. 每周管線摘要要素內(nèi)容觸發(fā)條件定時(shí)——每周一 8:00 AM動(dòng)作① 查詢 CRM 獲取管線摘要總價(jià)值、新商機(jī)、失效商機(jī)、預(yù)期成交→ ② 格式化為摘要 → ③ 發(fā)布到 Slack#sales-team→ ④ 向銷售管理層發(fā)送郵件摘要六、從 Playbook 到收入引擎銜接三份關(guān)鍵定義automation-playbooks.md 中的所有配方都不是孤立腳本它們的正確運(yùn)行依賴 RevOps 模塊內(nèi)三份定義文檔生命周期階段定義為配方提供字段依據(jù)。例如配方 #1 的「Lifecycle Stage MQL」需要 Subscriber/Lead/MQL/SQL/Opportunity/Customer/Evangelist 各階段的進(jìn)入與退出標(biāo)準(zhǔn)配方 #5 的「Customer」階段進(jìn)入動(dòng)作直接決定交接內(nèi)容回收原因代碼體系FIT-01 到 QUAL-03是配方 #7 判斷是否回收、如何回收的輸入。路由規(guī)則為分配類配方提供算法。round-robin 的跳過(guò)不可用代表、按配額達(dá)成加權(quán)、分配計(jì)數(shù)每周/每月重置ABM 場(chǎng)景下目標(biāo)賬戶域名匹配直接路由到賬戶所有者Tier 1 戰(zhàn)略賬戶響應(yīng) SLA 1 小時(shí)、Tier 2 4 小時(shí)、Tier 3 當(dāng)日速度響應(yīng)鏈5 分鐘 → 15 分鐘 → 30 分鐘 → 60 分鐘可直接內(nèi)嵌到配方 #1/#2。計(jì)分模型為配方 #3/#7 提供閾值與信號(hào)。fit 維度公司規(guī)模、行業(yè)、職位、技術(shù)棧、參與維度demo 請(qǐng)求、定價(jià)頁(yè)、試用與負(fù)向信號(hào)競(jìng)品域名、學(xué)生郵箱、垃圾投訴共同決定 MQL 閾值校準(zhǔn)節(jié)奏按業(yè)務(wù)類型區(qū)分PLG 每月、中端季度、企業(yè)季度到半年。三份文檔 本 Playbook 的組合使用路徑是先用生命周期定義統(tǒng)一階段口徑 → 用計(jì)分模型定 MQL 閾值 → 用路由規(guī)則定分配算法 → 最后按本 Playbook 把上述邏輯編碼為 HubSpot Workflow / Salesforce Flow / Zapier 自動(dòng)化——這正是 SKILL.md 中「Define Before Automate」原則的完整落地順序。七、落地檢查清單在復(fù)制任一配方前建議完成以下核對(duì)依據(jù) SKILL.md 的 RevOps 度量?jī)x表盤基準(zhǔn)SLA 是否顯式MQL 首次聯(lián)系 ≤ 4 業(yè)務(wù)小時(shí)、資格判定 ≤ 48 小時(shí)、SQL 轉(zhuǎn) Opportunity ≤ 5 業(yè)務(wù)日MQL-to-SQL 率基準(zhǔn) 30–50%SQL-to-Opportunity 50–70%。路由是否有回退每個(gè)分配類配方都要有 fallback owner未分配線索會(huì)快速冷卻并浪費(fèi)管線。計(jì)分是否含負(fù)向信號(hào)沒(méi)有負(fù)向計(jì)分的模型會(huì)讓不合格線索漏過(guò)。交接是否可度量每次交接市場(chǎng)→銷售、SDR→AE、AE→CS都有 SLA、追蹤機(jī)制與負(fù)責(zé)人。速度是否被優(yōu)先5 分鐘內(nèi)響應(yīng)資質(zhì)概率最高routing-rules.md 中有詳細(xì)速度-轉(zhuǎn)化對(duì)照告警與升級(jí)鏈應(yīng)優(yōu)先于其他非關(guān)鍵動(dòng)作。數(shù)據(jù)是否單一來(lái)源CRM 作為權(quán)威主數(shù)據(jù)源調(diào)度工具、營(yíng)銷自動(dòng)化、CS 工具都向 CRM 同步或經(jīng) Zapier 回寫。按照 SKILL.md 的輸出規(guī)范落地交付物應(yīng)包含生命周期階段文檔、計(jì)分規(guī)格、路由規(guī)則文檔、管線配置與指標(biāo)儀表盤規(guī)格——五份文檔每份都可獨(dú)立實(shí)施本 Playbook 即為其中「管線配置與自動(dòng)化觸發(fā)」的直接參考實(shí)現(xiàn)。贊分享AI 技能人工智能【免費(fèi)下載鏈接】marketingskillsMarketing skills for Claude Code and AI agents. CRO, copywriting, SEO, analytics, and growth engineering.項(xiàng)目地址https://gitcode.com/GitHub_Trending/mar/marketingskills點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Cal.diy 與 Zapier 集成實(shí)戰(zhàn)指南用 8000 應(yīng)用自動(dòng)化你的日程調(diào)度工作流Cal.diy 與 Zapier 集成實(shí)戰(zhàn)指南用 8000 應(yīng)用自動(dòng)化你的日程調(diào)度工作流 Cal.diy本項(xiàng)目倉(cāng)庫(kù)內(nèi)置了與 Zapier 的官方集成用后端前端企業(yè)應(yīng)用Garak 命令行一次跑通單命令完成一輪 LLM 漏洞掃描Garak 命令行一次跑通單命令完成一輪 LLM 漏洞掃描 接手一個(gè)新模型、上線前想確認(rèn)它有沒(méi)有明顯的安全缺口時(shí)你其實(shí)只需要敲一條 Garak 命令行命令。人工智能大模型模型評(píng)測(cè)紅藍(lán)對(duì)抗提示詞注入防護(hù)模型安全AI 安全治理利用DeepSeek-Coder-V2實(shí)現(xiàn)代碼智能化的完整指南利用DeepSeek Coder V2實(shí)現(xiàn)代碼智能化的完整指南 DeepSeek Coder V2是一款革命性的開(kāi)源代碼智能模型它打破了閉源模型在代碼智能領(lǐng)域人工智能大模型代碼模型DeepSeek創(chuàng)作聲明:本文部分內(nèi)容由AI輔助生成(AIGC),僅供參考