mcpField
T
team-performance-dashboard

team-performance-dashboard

github.com/lagrowthmachine营销与增长4585 次安装3 周前更新
代码仓库

关于 team-performance-dashboard

team-performance-dashboard 是面向销售负责人的技能,可用用户自己的 La Growth Machine 数据生成每周交互式团队仪表板。它按发送者展示回复与转化表现,并提供回复质量分析和辅导建议。

主要功能

  1. 01按发送者汇总回复与转化表现
  2. 02生成四个标签页的交互式仪表板
  3. 03分析回复质量与异议模式
  4. 04支持分批分析对话并累积结果
  5. 05可选择设置每周刷新

适用场景

  1. 01每周查看销售团队表现
  2. 02发现回复后未转化或趋冷的线索
  3. 03将有效活动模式用于团队辅导
  4. 04分析回复对话并查看响应时间

MCP 相关

该技能依赖 La Growth Machine MCP 获取用户连接的数据,也可检测 CRM、Airtable 和 Stripe 等 MCP。它根据可用数据生成仪表板;不会使用其他用户的数据。

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/lagrowthmachine/gtm-system --skill team-performance-dashboard

安装后在 Claude Code 中输入/team-performance-dashboard确认已加载。

附带文件assets/dashboard-template.htmlREADME.md

详细介绍

团队绩效仪表板

根据用户自己的 La Growth Machine (LGM) 数据,生成自己的团队绩效仪表板:一个包含四个标签页的实时成品,并按发件人身份(销售代表)排名。此技能完全自包含——环境检测、数据提取、评分、分类、模式挖掘和仪表板填充所需的每条规则都写在下面。除交接部分内嵌的通用技能下载链接表外,不引用任何其他文档。

要完成的工作

每周向销售负责人展示谁获得的回复最多,谁带来的实际转化最多,以及原因;指出哪些热门潜在客户正在失去热度;并说明如何将优秀营销活动的做法推广给表现落后的销售代表——用于辅导,而不是排名施压。

三条始终适用的硬性规则

  1. 只展示下载用户自己的数据。 只能从该用户已连接的 MCP 中提取数据。绝不引入其他人或本技能作者的数字、销售代表姓名、潜在客户、营销活动名称、回复或示例。模板初始为空;运行时用用户的实时数据填充。如果无法提取某个值,就呈现文档规定的空状态——绝不使用占位数字,也绝不从其他地方借用数值。
  2. 排名用于展示,辅导不用于惩罚。 销售代表按绩效排序,建议中可以指出某个成功模式来自哪位销售代表(“借鉴 {rep} 的营销活动做法”)。这是供管理者使用的内部工具,因此这种透明度是有意为之。底线是:绝不把表现不佳者描述成失败者——低于账户平均水平的销售代表应得到“这是经过验证的改进方法”,而不是“你落后了”。不得为了照顾情绪而隐藏任何销售代表。
  3. 输出必须是实时、可交互的成品——绝不能是保存的 .html 文件,也绝不能是原始代码块。 这是最常见的失败:切勿将填充后的 HTML 写入磁盘文件后就停止,也不要将它粘贴为围栏代码块。必须通过当前环境提供的任何成品 / 画布 / 实时预览机制发布,让用户获得渲染完成、可点击的仪表板,并能够打开和交互(排序表格、切换标签页、点击“修复”)。在 claude.ai 和 Claude Code 中,这是 Artifacts/画布界面;在没有成品界面的纯终端环境中,请说明这一点,并提出改为在浏览器中打开渲染后的 HTML——但默认且正确的输出是实时成品,而不是文件。不要硬编码特定工具名称;使用现有的成品功能。刷新时,更新现有成品,不要新建成品。assets/dashboard-template.html 仅作为构建源文件——在内存中填充其中唯一的 {{DASHBOARD_DATA}} 标记,然后实时渲染结果。

两种模式

  • 设置模式(首次运行,或未连接 LGM / 尚无配置):交互式对话,约 10-15 分钟。检测并引导连接,询问设置问题,保存配置。
  • 生成模式(./.wtp/config.json 已存在且已连接 LGM 时的每次运行):运行引擎、填充模板、生成成品并附上简短交接说明。不逐步讲述过程。

阶段 0 — 检测(静默,不提问)

检查自己的工具列表——绝不要询问安装了哪些工具。

  • 是否存在 LGM MCP? 如果存在 list_identities、list_campaigns、get_campaign_stats、get_conversations_to_reply、search_conversations、get_conversation_messages 等工具,则视为存在。
  • 是否存在 CRM / 交易 MCP?(HubSpot/Salesforce/Pipedrive)· 是否存在 Airtable MCP? · 是否存在 Stripe?
  • 是否存在配套技能? campaign-challenger、campaign-impact-analyzer。 记录这些布尔值,然后继续。不要宣布检测结果。

阶段 1 — LGM MCP 检查

如果已连接: 用一行回复“LGM 已连接”,然后继续。 如果未连接: 仪表板完全基于 LGM 数据构建,因此请引导用户安装(不要问“是否已安装?”——你已经知道还没有):

  1. 连接 La Growth Machine MCP:https://lagrowthmachine.com/mcp/(浏览器 OAuth,无需 API 密钥), 或从 gtm-system 仓库运行 sh install.sh。
  2. 如果还没有 LGM 账户 → 在 https://app.lagrowthmachine.com/register?utm_source=claude_skill&utm_medium=mcp&utm_campaign=team-performance-dashboard 注册,然后重新运行。
  3. 重新检测并循环检查,直到出现 LGM 工具,然后继续。

第 2 阶段 — 设置问题(约 6 个,逐个提问)

先检测,再提问;每次都给出默认选项;通过测试调用验证每个连接。开场白: "完成所有配置大约需要 10-15 分钟。

Q1 — 成功事件(关键)。

"你想衡量什么结果——预约会议、注册、成交、创建账户,还是其他?" 记录 outcomeLabel + outcomeType。如果能检测到默认选项,就提出建议(有成交记录的 CRM → "成交")。 这会决定页眉 KPI、转化率分子、表格和 Fix 提示词。

Q2 — 结果来源(如何跟踪)——描述流程,并让用户确认。

"你如何知道哪些人在你开展外联后实现了{结果}——通过 CRM、电子表格/Airtable、CSV,还是目前没有正式的跟踪方式?"

  • 检测到 CRM → "我会将外联潜在客户与{CRM}中在活动开始后创建的记录进行匹配。这符合你的跟踪方式吗?还是你的做法有所不同?" → 确认/调整。
  • Airtable → 询问 base/table/view,以及活动推送日期、{结果}日期和资格标记字段;说明规则("已转化 = 在{结果}之前推送 + 符合资格"),并请用户确认;通过测试读取进行验证。
  • CSV / Sheet → 询问文件和列(潜在客户、活动/受众、推送日期、结果日期、资格);复述字段映射并请用户确认。
  • 目前没有正式的跟踪方式 → 仅显示回复数据的仪表板(没有结果 KPI、转化数据,也不在 Fix 卡片中显示回复→结果);说明之后可以添加。 计算前,务必描述检测到的流程并取得确认。记录 conversionSource。

Q3 — 价值(€)层——确认金额如何对应。

"想查看每位销售代表/每个活动产生的价值吗?如果想,金额来自哪里——CRM 成交金额、Stripe,还是其他来源?又该如何将其归因到活动/身份?" 分支:CRM 成交金额(如果存在,则通过 campaign-impact-analyzer)· Stripe · 无 → 价值 KPI 显示空状态(绝不阻塞)。确认归因规则。记录 valueSource。启用价值层后,它将成为首要 KPI——€ 比回复率和数量更能反映实际情况。

Q4 — 当前工作范围。

"你现在正在积极跟进哪些活动——所有 RUNNING 活动,还是你关注的特定列表?" 默认:所有 RUNNING 活动。记录 activeRoutineCampaigns[]。(回复率按此范围统计;结果、转化和价值仍按整个账户统计,以便继续显示之前表现出色的活动。)

Q5 — 要纳入的身份。

"我会跟踪这些发件人:{发送和接收的消息均 >=1 条的身份}。有没有要排除的(例如测试账户)?" 默认:所有有实际活动的身份。记录 identities[] + excludedIdentities[]。

Q6 — 每周刷新(可选)。

"要设置一个例行任务,每周一刷新此仪表板(重新拉取 LGM、重新分类新回复、更新产物)吗?刷新按钮也可以按需触发。" 选择是 → 创建计划任务,并记录其 id 到 refreshTaskId。选择否 → id 留空;按钮会显示友好的提示消息。

(条件性)多工作区。 如果 list_workspaces 返回多个工作区,先询问要使用哪一个。

不需要提问的事项:

  • 基准值不询问——使用内置默认值:LinkedIn 回复率 >=25%,电子邮件回复率 >=6%(引擎中的观察/底线区间)。
  • 回复分类(基础处理)不询问——仪表板会根据活动统计数据快速构建,因此只需在后台分类少量样本(约 6-20 条近期回复)(使用轻量模型即可),为回复质量标签页提供基准。不要因大量分类处理而阻塞构建;更深入的分析将在下文第 5 阶段作为可选项提供。

Phase 3 — 构建

运行引擎 → 在内存中填入模板唯一的 {{DASHBOARD_DATA}} 标记 → 渲染为实时交互式产物(见硬性规则 3 — 这是必需的输出;不要保存为 .html 文件或粘贴代码块)。首次运行时创建产物,后续运行时更新现有产物。将本周的快照写入 ./.wtp/。在页眉中注明活动抽样覆盖范围 — 抽样时绝不能暗示覆盖了全部数据。

基础构建会计算与暂缓计算的内容(如实呈现空状态):

  • 回复率、接受率、已联系、待处理/积压 → 始终计算(成本低,数据来自活动统计)。
  • 结果、转化、价值 → 只要设置时配置了数据源,就在此处计算(E6)。仅在没有数据源时显示空状态。不要因为成本而跳过 — 这些是核心指标。
  • 回复中位数 → 暂缓到 Phase 5 获取数据时计算(需要每个对话线程的时间戳)。在基础构建中显示空状态;用户运行对话分析后即可填入。
  • 回复质量(分类/异议/最佳回复) → 现在用少量样本初始化,Phase 5 再深入分析。

Phase 4 — 交接

简短,不要逐步叙述。见下方的 ## 输出与 LGM 交接。最后提出 Phase 5 的选项。

Phase 5 — 深入分析回复(可选择、分档、增量式)

基础仪表板已就绪,但回复质量标签页(主要异议、竞争对手分析、处理得最好的回复、雷达图)的丰富程度取决于已分类的回复数量 — 基础分析只读取了少量回复。仪表板渲染后,提供分析更多对话的选项,让用户可以分批进行,并提前了解成本。可以这样说:

“你的仪表板已上线。目前只分类了一小批回复,而且回复时间中位数尚未填入 — 计算它需要我读取你的对话线程。要我获取并分析更多对话吗?同一轮处理既能完善回复质量标签页,也能填入回复时间指标。 大致来说,50 个对话约需 15 分钟(令牌成本随数量增加),你可以选择一批:

  • 仅分析本周的回复(通常最快,也最相关)
  • 最近约 50 个(约 15 分钟)
  • 最近约 100 个(约 30 分钟)
  • 所有待回复的对话(数据量较大 — 我会分批处理,你可以随时停止) 或者暂时跳过,之后再回来处理。”
  • 获取数据一举两得。 对获取的每个线程,它都会 (a) 分类回复(E5),并且 (b) 读取消息时间戳,以计算每个身份首次回复后的回复时间中位数(E5 回复中位数规则,剔除最慢的 20%,并交叉核对状态)。因此,这一步既能填充回复质量标签页,也能填充回复时间 KPI/列。
  • 按选项确定获取范围:“本周” → search_conversations {leadReplied:true, since:<monday>};“最近 N 个” → 最新的 N 个已接收线程;“所有待回复的对话” → 分批翻页获取待回复队列。对于尚未加入 classifiedReplyIds 的每个线程,读取 get_conversation_messages,进行分类并记录时间戳,所选批次处理完毕后就干净地停止 — 用户可以重新运行以获取更多数据。
  • 不是 LGM 用户?使用他们导出的数据。 如果他们不使用 LGM(或想分析其他渠道),允许他们粘贴或上传对话导出文件(CSV 或文本:潜在客户、消息、方向、日期)。根据这些数据进行分类,使用相同的分类体系,并根据行数采用相同的分档。
  • 增量累积: 每批数据都会合并到快照的累积状态(objectionPlaybook、patternLibrary、雷达计数、classifiedReplyIds 跳过列表),并且更新现有实时产物 — 因此每次都会完善回复质量标签页,而且不会重复读取数据。分类循环使用经济型模型;更强的推理能力仅用于最佳回复评分。
  • 如实呈现: 如果某批数据中没有可评分的异议,就保留空状态 — 绝不捏造内容。

THE ENGINE(内联 — 完全照原文复现)

所有评分均为确定性的。百分比均为整数。文案中使用普通连字符,不使用 en dash。

E1. 拉取(团队范围 — 每个纳入的身份)

  1. list_identities → 解析纳入的身份 ID + 显示名称(也用于构建收件箱链接)。list_campaigns {status:"RUNNING"}(分页)→ 在每个 Campaign 上保留 identity{id, firstname, lastname} (Campaign 与身份的关联)。
  2. 每个 Campaign 调用 get_campaign_stats → 获取各渠道计数器。**控制成本:**如果 RUNNING Campaign 数量超过单次运行的处理能力,则对抽样对象拉取完整详情(每个身份至少 1-2 个,并优先选择各身份 replyRatePercent 最高和最低的 Campaign),其余对象使用 list_campaigns 的 replyRatePercent + leadsCount。在产物中说明覆盖范围(例如:“43 个 RUNNING Campaign,其中 17 个为完整详情”)——抽样时绝不能暗示覆盖了全部数据。
  3. 回复:调用 get_conversations_to_reply {identityIds:[...]} 获取待处理队列(读取 total 获取数量;拉取少量行以获取热门潜在客户的姓名)。分类和异议挖掘:抽样调用 search_conversations {leadReplied:true} → get_conversation_messages(实时,数量有限)。

标题基准:li_reply = Σ(li.replied)/Σ(li.sent) 和 em_reply = Σ(em.replied)/Σ(em.sent) 按有渠道数据的 Campaign 汇总,并分别与内置目标比较(linkedin_reply 良好值为 25 / 下限为 15; email_reply 良好值为 6 / 下限为 3)。blended_reply = 两个渠道合并计算的回复率,仅作背景参考,不设单独目标(不要臆造综合基准)。

E2. 规范化每个 Campaign(内置基准)

每个 Campaign:contacted、li:{accept, reply, csent, msent}|null、em:{sent, open, reply, bounce, atag}|null。各 KPI 区间(良好值、下限、方向):linkedin_acceptance (30,20,up)、 linkedin_reply (25,15,up)、email_open (60,45,up)、email_reply (6,3,up)、email_bounce (15,25, down)。MIN_SEND = 10 是 KPI 评分门槛;contacted < 20 的 Campaign 属于低样本(列出,但不评分)。zone(k,v):up → v>=good 时为绿色,v>=floor 时为黄色,否则为红色;down → 反向。

E3. 每个身份的汇总与排名

每个纳入的身份(至少有 1 次发送且至少有 1 次收到,才会显示;其他身份列入脚注):

  • 回复率 = 该身份活跃常规 Campaign 中 Σ(replied)/Σ(contacted),按量加权(标题指标)。LinkedIn 接受率、email 回复率也按相同方式汇总。
  • 待处理数 = 每个身份待处理队列中的 total。
  • 账号平均值 = 全账号范围 Σ(所有 replied)/Σ(所有 contacted);代表高出或低于 ±3 个百分点即视为高于或低于平均值。
  • 结果(SU/会议/交易)、转化率(产生该结果的 Campaign 中,结果 ÷ contacted;已退役 Campaign 的数量为估算值时标记 *)、价值(€)——均按全账号范围计算。只要配置了相应来源(见 E6),基础构建就会计算这些指标——绝不能因成本原因跳过。
  • 中位响应时间不会在基础构建中计算(需要按会话拉取时间戳)。它会在第 5 阶段的会话获取中补充(见 E5 / Phase 5);在此之前显示为空状态。此处可通过低成本的待处理队列总数获取积压量(每位代表的待处理数量)。
  • 按回复率降序排列所有代表(徽章 #1..#n)。跨身份建议应在落后代表的最佳模式来自其他身份时,注明来源代表。优先参考该代表自身的内部差异。

E4. 模式挖掘(营销活动侧 + 回复侧)

按驱动回复 KPI 的表现对账号内的营销活动进行排名;取排名靠前的一部分,以及最有力的同身份内部对比(同一销售代表自己的营销活动之间差异越大,越能作为可靠依据)。阅读排名靠前和对比营销活动的 templates[].newHtml;描述开场结构(引用了什么、长度/语气、CTA)。跳过完全由变量组成或空白的模板(没有可供归纳的固定文案)。为每种模式命名,标记为营销活动侧或回复侧;尽可能说明其提升幅度(以同一发件人的对比为准);设定置信度(高 = 重复验证 2 次以上和/或已证明对冷受众有效;中 = 仅对暖受众有效;推断性 = 单一结果且受众因素造成混杂——请注明)。将每个红色/黄色营销活动与素材库匹配 → 给出“应用此模式”的建议 + Fix 提示词。将模式持久化保存到快照中;随周数推移强化或衰减。

E5. 回复质量 + 响应时间中位数(主要来自第 5 阶段的抓取)

基础构建会用一个很小的样本初始化此项;丰富版本则来自第 5 阶段的对话抓取。同一批抓取的对话线程兼用于分类和响应时间分析。

  • 分类:将每个抽样对话线程归为五种类型之一:HOT(明确提出通话/会议/定价请求)、CURIOUS(积极参与,没有异议)、OBJECTION、FIRM_NO、WRONG_FIT。 在抽样查看异议前,先筛选出 OBJECTION——随机抽取的 RECEIVED 对话线程大多会显示为 CURIOUS/HOT。
  • 异议子类型:使用 objection-analyzer 技能定义的九个规范 ID:competitor_in_place / feature_gap / tried_before / price_budget / timing / value_doubt / process_authority / scope_mismatch / channel_trust。请使用这些准确的 ID,以便两个技能针对相同数据报告相同的异议子类型分布。如果已安装该技能,其 references/objection-taxonomy.json 是事实来源,其中也包括别名。
  • 迁移旧快照。 此分类体系推出前积累的状态包含 equipped、wrong_person 和 segment_fit。加载时进行映射——将 equipped 映射为 competitor_in_place,另外两个映射为 WRONG_FIT——否则雷达图和优先级表会把旧标签和新标签显示为代表同一情况的两行。
  • 异议是仍在积极沟通的人提出的阻碍。 主动取消自身资格的人属于 WRONG_FIT,而非异议——这包括联系人不对、细分市场不对、职位级别太低以及求职者。单独统计 WRONG_FIT,绝不计入异议占比:它是目标定位信号,而非辅导信号。EQUIPPED 不是单独的类别,而是 competitor_in_place 异议。
  • 主要异议 = 样本中最常见的异议子类型 + 一句辅导指南 + 应带给团队的内容。雷达图 = 五种类别的分布。优先级表 = 异议(制作话术/竞品对比卡)、被提及最多的竞品(来自 competitor_in_place 异议,样本量足够时)、不匹配对象占比(目标定位信号)、AI 语气提示。
  • 处理最佳的回复 = 按 9 个维度的评分标准为抽样的 OBJECTION 回复打分(语气匹配/回应消息内容/长度相称/最多一个问题/不含禁用短语/不强势推销/资源优先级正确/不令人毛骨悚然/符合流程,每项 0-3 分,且总分 >=22/27),并将得分最高的一条作为“照着写”的示例。绝不编造示例——如果没有符合条件的回复,就如实说明。这与 objection-analyzer 技能使用的九个评分维度、相同顺序和相同门槛一致,因此在一个技能中评分的回复也可沿用于另一个技能。该技能的 references/coaching-rubric.md 中列出了各项 0-3 分的评分标准。
  • AI 语气提示属于营销活动文案(Playbooks 标签页),而非回复处理。
  • 响应时间中位数(根据第 5 阶段抓取的对话线程计算,而非基础构建) = 按身份统计,计算潜在客户发来消息后,销售代表在首次回复之后作出的下一次回复之间的时间中位数;根据用户选择分析的对话线程中的消息时间戳计算,并剔除响应最慢的 20%(这部分长尾大多是被遗忘的潜在客户)。将剔除的长尾与每位潜在客户的 LGM 状态(get_lead_logs)交叉核对:未完成资格判定 + 状态冷淡 → 可能是疏忽(作为积压事项显示);已完成资格判定且不感兴趣/已终止 → 合理结案。随着各批次数据到来,该指标会填充响应时间中位数 KPI/列。

E6. 转化追踪 + 价值(基础构建版 — 配置了来源时必须提供)

如果在设置时配置了转化/价值来源(Q2/Q3),则必须在基础构建版中计算结果、转化和价值,不能为了节省成本而延后或跳过;它们是此仪表盘的核心内容。 仅在未配置来源时显示空状态。

  • 从已配置的来源(CRM / Airtable / CSV)提取“在 {outcome} + 合格之前推送到某个营销活动”的数据;按营销活动/受众分组 → 根据实际结果为营销活动排名,而不只是看回复率。具体字段/逻辑以用户在设置时(Q2)描述并确认的内容为准——将其视为用户的流程,而非固定结构。
  • 价值 = 按用户确认的规则(Q3),将配置的金额归因到营销活动/身份。当价值层启用时,它就是核心 KPI。
  • 阅读转化率最高的营销活动背后的几段真实对话,为回复跟进模式提供依据(如实报告——有时,坚持跟进比回复处理技巧更重要)。

E7. 快照 — ./.wtp/snapshot-<YYYY>-W<ww>.json

本周状态(覆盖写入):按身份汇总、待处理队列、标题、热门潜在客户、周环比变化。 累积状态(加载、合并并持久化 — 绝不覆盖):patternLibrary[]、objectionPlaybook[]、classifiedReplyIds[](跳过列表)。在一个 ISO 周内可安全合并(计数只增不减)。至少保留 5 周的数据以分析趋势。


填充契约

读取 assets/dashboard-template.html。该模板完全由一个注入对象渲染 — 将单个令牌 {{DASHBOARD_DATA}} 替换为下方规定结构的 JSON 对象,然后将结果渲染为实时交互式产物(硬性规则 3 — 不能是保存的文件,也不能是代码块)。所有用户文本(代表姓名、营销活动名称、潜在客户消息)都必须进行 HTML 转义。每个字段均由引擎填充;省略字段或将字段留空,即可显示其文档所述的空状态(例如,没有 value → 价值 KPI 显示“连接 CRM / Stripe”)。

{
  "weekLabel": "Jul 20, 2026", "lastUpdated": "Jul 20, 2026", "refreshTaskId": "",
  "outcomeLabel": "Signups",
  "kpis": { "value": "€120k"|null, "outcome": 23, "hotPipeline": 6,
            "liReply": 20, "liZone": "yellow", "emReply": 3, "emZone": "red", "medianResp": "1.7d" },
  "coverage": "43 RUNNING campaigns, 17 in full detail",
  "hotLeads": [ { "wait":"9d", "owner":"{rep}", "lead":"{name}", "msg":"{signal}" } ],
  "speed": { "median":"1.7d", "backlog": 6, "note":"..." },
  "insights": [ "..." ],
  "team": [ { "name":"{rep}", "contacted":71, "accept":56, "reply":40, "replyZone":"green",
              "emailReply":null, "awaiting":829, "medResp":"0.9d", "outcome":1, "conv":1.4,
              "convApprox":false, "value":"€8.9k"|null, "lowSample":false } ],
  "fixes": [ { "who":"{rep}", "flag":"red"|"yellow", "stat":"...", "headline":"...", "context":"...",
               "improveReply":"{prompt+install link}", "improveConv":"{prompt+install link}" } ],
  "playbook": { "aiCallout":"..."|null,
                "channels":[ {"chan":"email"|"linkedin","title":"...","rows":[{"what":"...","metric":"...","up":true}],"empties":["..."],"conf":"..."} ],
                "patternsCampaign":[ {"name":"...","conf":"high","lift":"...","desc":"...","excerpt":"...","meta":"..."} ],
                "patternsReply":[ {...} ] },
  "quality": { "principalObjection": {"type":"...","desc":"...","team":"..."} | null,
               "radar": [ ["Hot",8], ["Curious",25], ["Objection",18], ["Firm no",4], ["Wrong fit",6] ],
               "priority": [ {"cat":"...","pr":"hi"|"mid"|"lo","prl":"...","todo":"..."} ],
               "bestReply": {"label":"...","text":"...","meta":"..."} | null }
}

收件箱链接(热门潜在客户):在填充时构建为 https://app.lagrowthmachine.com/inbox?ID=ALL&ST=REPLIED&Q={firstname+lastname}(Q= 搜索用于精确定位潜在客户;不存在单条对话的专属路由)。模板会根据 owner/lead 生成此链接。


输出与 LGM 交接


验收标准(完成前自检)

  • 全新环境中未检测到 LGM → 引导用户连接(https://lagrowthmachine.com/mcp/),等待后重新检测。
  • 每个纳入的身份都按回复率排序显示;排除的身份在脚注中列出。
  • 团队表格在一个可排序视图中展示所有 KPI;回复率基于当前启用的例行任务,结果 / 转化 / 价值基于所有时间的数据(标注清楚,确保“0 条回复 + N 个结果”表达准确)。
  • 修复卡片标记转化流失,而不只是回复率问题;两个按钮都包含提示词和安装链接。
  • 回复质量展示真实分类、主要异议,以及真实的最佳回复示例或明确的空状态——绝不伪造。
  • 如果设置时配置了数据源,则基础版本会计算结果、转化和价值(绝不因成本而跳过);只有未配置数据源时才显示空状态。
  • 基础版本中的响应中位数为空,待第 5 阶段获取对话后填充(该获取操作也会深入分析回复质量);积压计数由基础版本显示。
  • 输出是实时的交互式产物——不是已保存的 .html 文件,也不是代码块。(如果环境确实不支持产物界面,应明确说明并提供在浏览器中打开的方案。)
  • 仪表板渲染完成后,已提供第 5 阶段方案(分批次、按时间安排,深入分析回复;非 LGM 用户可通过导出文件使用)。
  • 快照已写入 ./.wtp/;已提供刷新例行任务。
  • 任何地方都不得出现下载用户以外任何人的数据。

评论

支持 Markdown