📊 项目快照
所有人都该看的核心数字
9
Sub-agent
3
渠道独有模块
9
Lark 表(Leads + Partners 拆分)
5
Dedup 防御层
4
触发源
3
人工介入点
我们做了个 9-agent 系统跑渠道招募 — Apollo 那一套 + 渠道独有的赋能/联合销售/返佣 3 个模块。
所有数据写 Lark 多维表格 — 你 / 团队 / 老板打开 Lark App 立刻看到全部数据。
Leads 表(700 条,追踪中) 和 Partners 表(1 条,真合作 MOA+) 拆开 — Partners 表的记录数 = 真合作伙伴数,不是 raw qualifications。
人只在 3 个地方介入:Tier S 审核、大额返佣、锁单冲突。其他全自动。
端到端已跑通 — 846 真候选(8 国:US/UK/CA/CN/MY/ES/AU/JP)+ 700 leads + 完整数据契约。
所有数据写 Lark 多维表格 — 你 / 团队 / 老板打开 Lark App 立刻看到全部数据。
Leads 表(700 条,追踪中) 和 Partners 表(1 条,真合作 MOA+) 拆开 — Partners 表的记录数 = 真合作伙伴数,不是 raw qualifications。
人只在 3 个地方介入:Tier S 审核、大额返佣、锁单冲突。其他全自动。
端到端已跑通 — 846 真候选(8 国:US/UK/CA/CN/MY/ES/AU/JP)+ 700 leads + 完整数据契约。
视角 1 · 高层架构 老板 / 投资人
谁跟谁说话 · 渠道差异化在哪 · 自动化范围多大
flowchart TB
subgraph Triggers["⚡ 触发源"]
T1[每周一定时扫]
T2[Signal: 拿融资 / 招 BD / 开新区]
T3[渠道经理手动启动]
T4[Partner 回复 / 反报客户]
end
subgraph Core["🤖 9-Agent 核心(Claude Code)"]
direction TB
A1[1 · Sourcing
发现潜在 partner] A2[2 · Qualifying
评 Tier S/A/B/C] A3[3 · Outreach
多步序列起草] A4[4 · Meeting
brief + 通话总结] A5[5 · Partner CRM
生命周期管理] A6[6 · Analytics
漏斗 + 异常] A7[★ 7 · Enablement
渠道商赋能
渠道独有] A8[★ 8 · Co-sell
联合销售 + 锁单
渠道独有] A9[★ 9 · Commission
返佣计算
渠道独有] A1 --> A2 --> A3 --> A4 --> A5 A5 --> A7 & A8 A8 --> A9 A6 -.监控.-> A1 & A2 & A3 end subgraph Knowledge["📚 Knowledge Hub"] K1[产品矩阵
5 模块] K2[渠道政策
返佣/锁单/折扣] K3[ICP 画像] K4[客户案例] end subgraph Data["📋 数据底座 — Lark Base (9 表)"] D1[Candidates 38
raw 池] D2[★ Leads 28
追踪中] D3[★ Partners 0
真合作 MOA+] D4[Outreach Drafts 10] D5[Meetings · Opportunities · Commissions] D6[Review Queue · Activities] D7[(SQLite 备份)] end subgraph External["🌐 外部系统"] E1[Apollo / LinkedIn] E2[Gmail / SMTP] E3[Calendly] E4[Otter / Fireflies] E5[Quickbooks / Xero] end subgraph Visibility["👀 团队可见层"] V1[Lark Web] V2[Lark Mobile App] V3[Kanban / Gallery / Form 视图] end subgraph Humans["👥 人类协作"] H1[渠道经理
审批 Tier S/A] H2[Finance Controller
审 > $10k] H3[渠道 GM
裁决冲突] end Triggers --> Core Core <--读取--> Knowledge Core <--lark-cli 读写--> Data Core <--调用--> External Core <--审批/告警--> Humans Data --实时同步--> Visibility Visibility -.编辑.-> Data classDef channel fill:#fef3c7,stroke:#d97706,stroke-width:2px classDef trigger fill:#dbeafe,stroke:#2563eb classDef ext fill:#f3e8ff,stroke:#9333ea classDef hum fill:#fee2e2,stroke:#dc2626 classDef vis fill:#dcfce7,stroke:#16a34a,stroke-width:2px class A7,A8,A9 channel class T1,T2,T3,T4 trigger class E1,E2,E3,E4,E5 ext class H1,H2,H3 hum class V1,V2,V3 vis
发现潜在 partner] A2[2 · Qualifying
评 Tier S/A/B/C] A3[3 · Outreach
多步序列起草] A4[4 · Meeting
brief + 通话总结] A5[5 · Partner CRM
生命周期管理] A6[6 · Analytics
漏斗 + 异常] A7[★ 7 · Enablement
渠道商赋能
渠道独有] A8[★ 8 · Co-sell
联合销售 + 锁单
渠道独有] A9[★ 9 · Commission
返佣计算
渠道独有] A1 --> A2 --> A3 --> A4 --> A5 A5 --> A7 & A8 A8 --> A9 A6 -.监控.-> A1 & A2 & A3 end subgraph Knowledge["📚 Knowledge Hub"] K1[产品矩阵
5 模块] K2[渠道政策
返佣/锁单/折扣] K3[ICP 画像] K4[客户案例] end subgraph Data["📋 数据底座 — Lark Base (9 表)"] D1[Candidates 38
raw 池] D2[★ Leads 28
追踪中] D3[★ Partners 0
真合作 MOA+] D4[Outreach Drafts 10] D5[Meetings · Opportunities · Commissions] D6[Review Queue · Activities] D7[(SQLite 备份)] end subgraph External["🌐 外部系统"] E1[Apollo / LinkedIn] E2[Gmail / SMTP] E3[Calendly] E4[Otter / Fireflies] E5[Quickbooks / Xero] end subgraph Visibility["👀 团队可见层"] V1[Lark Web] V2[Lark Mobile App] V3[Kanban / Gallery / Form 视图] end subgraph Humans["👥 人类协作"] H1[渠道经理
审批 Tier S/A] H2[Finance Controller
审 > $10k] H3[渠道 GM
裁决冲突] end Triggers --> Core Core <--读取--> Knowledge Core <--lark-cli 读写--> Data Core <--调用--> External Core <--审批/告警--> Humans Data --实时同步--> Visibility Visibility -.编辑.-> Data classDef channel fill:#fef3c7,stroke:#d97706,stroke-width:2px classDef trigger fill:#dbeafe,stroke:#2563eb classDef ext fill:#f3e8ff,stroke:#9333ea classDef hum fill:#fee2e2,stroke:#dc2626 classDef vis fill:#dcfce7,stroke:#16a34a,stroke-width:2px class A7,A8,A9 channel class T1,T2,T3,T4 trigger class E1,E2,E3,E4,E5 ext class H1,H2,H3 hum class V1,V2,V3 vis
要点: 黄色 3 个 agent (Enablement / Co-sell / Commission) 是渠道独有 — Apollo 没有。
绿色「团队可见层」是关键差异化 — Lark Base 同时是数据底座 + 团队看板,渠道经理 / 老板 / 财务都能在 Lark App 直接看到 + 改数据,不需要任何额外 dashboard。
人类只在 3 个地方介入。
视角 2 · 端到端时序 销售 / 渠道经理
跟一个真实 partner 从被发现到首次返佣 · 你只做 3 件事
sequenceDiagram
autonumber
participant Cron as ⏰ 定时器
participant S as 1·Sourcing
participant Q as 2·Qualifying
participant O as 3·Outreach
participant CM as 👤 渠道经理
participant P as 📧 Partner
participant M as 4·Meeting
participant CRM as 5·CRM
participant Co as 8·Co-sell
participant Com as 9·Commission
Cron->>S: 周一 09:00 扫加州 POS 集成商
S->>S: WebSearch + Apollo + 协会名录
S->>CRM: 写入 5 个 candidates
S->>Q: 触发 qualifying
Q->>Q: ICP 5 维度评分
Q->>CRM: 1 个 S, 4 个 A
Q->>O: 触发 outreach
O->>O: 读 KB + 生成个性化 4-step
O->>CRM: 写 drafts (PENDING)
O->>CM: 🚨 Tier S 待审
CM->>O: 批准 step 1
O->>P: 📧 邮件 step 1 (Day 0)
Note over O,P: Day 2 LinkedIn · Day 5 follow-up
P->>O: 📨 "感兴趣,周三聊"
O->>M: 触发 meeting
M->>M: 生成 brief
M->>CM: 📋 brief + 会议邀请
CM->>P: 30 分钟 Zoom
P->>M: 通话录音
M->>M: 抽取 intent + next step
M->>CRM: lifecycle: LEAD → MOA
Note over P,Co: 几周后 partner 报备 Bertucci's
P->>Co: 客户报备
Co->>CRM: 锁单 60 天
Co->>Co: 生成 deck + quote
Note over Co,Com: 联合销售,成交
Co->>CRM: stage = WON
CRM->>Com: 触发 commission
Com->>P: 📄 月度对账单 PDF
渠道经理只做 3 件事: 审 Tier S 邮件、开会议、收 partner 反馈。其他全自动 — 邮件起草 / brief 写作 / 会议总结 / 返佣计算 / 对账单生成。
典型 partner 旅程: 周一进系统 → Day 8 内回复 → Day 30 内开会 → 60 天签 MOA → 90 天内首单。
视角 3 · Partner 生命周期 产品 / 运营
阶段流转规则 · 关键转化点
stateDiagram-v2
[*] --> CANDIDATE: sourcing 入库
CANDIDATE --> QUALIFIED: qualifying 评 tier
CANDIDATE --> BLOCKED: 冲突/重复
QUALIFIED --> LEAD: 进入 outreach 队列
LEAD --> LEAD: 多步序列触达
LEAD --> MOA: meeting intent ≥ 4 + MOA 签
LEAD --> CHURNED: 90 天无回复
LEAD --> NOT_INTERESTED: 明确拒绝
MOA --> PILOT: 首个客户进 pilot
MOA --> CHURNED: 60 天无 opportunity
PILOT --> ACTIVE: 首单成交 → commission
PILOT --> CHURNED: pilot 失败
ACTIVE --> ACTIVE: 续约 + 新 opp
ACTIVE --> CHURNED: 90 天无出单
CHURNED --> LEAD: 复活
BLOCKED --> [*]
NOT_INTERESTED --> [*]
关键转化点: LEAD → MOA(取决于邮件文案 + brief 质量),MOA → PILOT(取决于 enablement 培训),PILOT → ACTIVE(取决于 co-sell 锁单 + 产品交付)。Analytics agent 监控每一段转化率,异常自动告警。
视角 4 · 数据模型 工程师
8 张 Lark 表 · 所有 agent 共用的 single source of truth · 同时是团队界面
erDiagram
CANDIDATES ||--o| LEADS : "qualifying ⬆"
LEADS ||--o| PARTNERS : "★ MOA signed ⬆"
LEADS ||--o{ OUTREACH_DRAFTS : "received emails"
LEADS ||--o{ MEETINGS : "first meetings"
PARTNERS ||--o{ MEETINGS : "ongoing meetings"
PARTNERS ||--o{ OPPORTUNITIES : "registers"
PARTNERS ||--o{ COMMISSIONS : "earns"
PARTNERS ||--o{ ACTIVITIES : "logged"
CANDIDATES ||--o{ REVIEW_QUEUE : "dedup_suspect"
OPPORTUNITIES ||--o{ COMMISSIONS : "generates"
CANDIDATES {
text Candidate_Name
text Domain
text Normalized_Name
select Status "NEW/QUALIFIED/BLOCKED/DUP"
number Employees_Est
}
LEADS {
string Lead_ID PK "LD-001..N"
select Engagement_Status "CANDIDATE/LEAD/ENGAGED/READY_FOR_MOA/DROPPED"
select Tier "S/A/B/C/BLOCKED"
select Type
number Score
text Domain
datetime Last_Touched
text Last_Touch_Note
}
PARTNERS {
string Partner_ID PK "PRTN-001..N"
select Lifecycle_Stage "MOA/PILOT/ACTIVE/CHURNED"
select Tier
select Type
text Domain
datetime Last_Touched
}
OPPORTUNITIES {
string Opportunity_ID PK
string Partner_ID FK
select Stage "REGISTERED/QUALIFIED/PILOT/WON/LOST/EXPIRED"
number Estimated_ARR
datetime Locked_Until "60-day lock"
}
COMMISSIONS {
string Commission_ID PK
string Partner_ID FK
text Period "2026-06"
number Amount
select Status
}
关键变化: Candidates → Leads → Partners 是三段式流转。
Partners 表只能从 Leads 升上来(MOA 签了之后),其他 agent 不能直接写 Partners。
数据契约由 Lark 表权限 + agent.md 双重保障。
关键: 这不是 ER 图 — 这是 Lark Base 真实的 8 张表(可以现在打开 Lark 看)。
所有 select / number / datetime 字段在 Lark 里都是原生可视化(下拉 / 进度条 / 日历)。
🆕 Partner 定义 + 7 阶段生命周期 产品语义核心
什么算「真 Partner」 · raw qualifications 不算 · 数据契约
严格定义
Partner = 跟我们建立了正式合作关系(签 MOA 或更后)的合作机构。
在那之前都叫 prospect / lead / candidate。
完整 7 阶段流转
flowchart LR
C[1 · CANDIDATE
raw 发现] --> L[2 · LEAD
评分+人审] L --> E[3 · ENGAGED
有互动] E --> M[4 · MOA ⭐
真 Partner 起点] M --> P[5 · PILOT ⭐
客户试点] P --> A[6 · ACTIVE ⭐
有出单] A --> A A --> CH[7 · CHURNED
90 天无出单] classDef raw fill:#f4f4f5,stroke:#a1a1aa classDef tracking fill:#dbeafe,stroke:#2563eb classDef partner fill:#fef3c7,stroke:#d97706,stroke-width:3px classDef end_ fill:#fee2e2,stroke:#dc2626 class C,L,E tracking class M,P,A partner class CH end_
raw 发现] --> L[2 · LEAD
评分+人审] L --> E[3 · ENGAGED
有互动] E --> M[4 · MOA ⭐
真 Partner 起点] M --> P[5 · PILOT ⭐
客户试点] P --> A[6 · ACTIVE ⭐
有出单] A --> A A --> CH[7 · CHURNED
90 天无出单] classDef raw fill:#f4f4f5,stroke:#a1a1aa classDef tracking fill:#dbeafe,stroke:#2563eb classDef partner fill:#fef3c7,stroke:#d97706,stroke-width:3px classDef end_ fill:#fee2e2,stroke:#dc2626 class C,L,E tracking class M,P,A partner class CH end_
每个阶段:谁判断、自动/人审、写哪张表
| # | 阶段 | 定义 | 判断 | Lark 表 |
|---|---|---|---|---|
| 1 | CANDIDATE | sourcing 抓到的 raw 数据 | 🤖 sourcing 自动 | Candidates |
| 2 | LEAD | 评分通过 + 渠道经理人审 | 👤 渠道经理 | Leads (Engagement=LEAD) |
| 3 | ENGAGED | ≥ 1 次双向互动 | 🤖 outreach 检测回复 | Leads (ENGAGED) |
| 4 ⭐ | MOA | 签了合作意向书 ✨真 Partner | 👤 渠道经理 + 法务 | Partners (MOA) |
| 5 ⭐ | PILOT | 1+ 客户进 pilot | 🤖 cosell 自动 | Partners + Opportunities |
| 6 ⭐ | ACTIVE | 首单成交持续出单 | 🤖 commission 自动 | Partners + Commissions |
| 7 | CHURNED | 90 天无出单+无沟通 | 🤖 partner-crm 自动 | Partners (CHURNED) |
为什么拆 Leads / Partners 两张表
| 之前(混在 Partners) | 现在(拆开) |
|---|---|
| Partners 表 701 条 = raw qualifications + 追踪中 + 真合作(全混一起) | Leads 表 700 条 = 追踪中(raw / 评分 / 互动) Partners 表 1 条 = 真合作 MOA+ |
| 老板看 Partners=28 以为有 28 个真合作伙伴 ❌ | 老板看 Partners=0 立刻明白:还没真签过 ✓ |
| outreach 可能给已 MOA 的伙伴重发"招募"邮件 | outreach 只读 Leads,Partners 不接受招募外联 |
数据契约:
len(Partners 表) = 真合作伙伴数 — 不再被 raw 数据污染。
qualifying agent **不能写 Partners 表**;只有 meeting agent 在 MOA 签署后才创建 Partners 记录。
🆕 Dedup 5 层防御 数据质量核心
为什么每次扫不会重复入库 · 实测准确率 100%
flowchart TD
Raw[Raw candidate
来自 Apollo/LinkedIn/WebSearch] L1{Layer 1
Authoritative ID
crunchbase / linkedin_urn} L2{Layer 2
Domain 归一化
cbsnorthstar.com} L3{Layer 3
Normalized name
去 Inc/LLC/标点} L4{Layer 4
Fuzzy match
+ 行业后缀剥离
相似度 ≥ 0.85} L5{Layer 5
Business rules
子域/HQ/champion 邮箱} Merge[🟦 MERGE_EXISTING
累加 source] Review[🟧 SUSPECT_REVIEW
进人审队列] Block[🟥 SKIP_BLOCKED
已 BLOCKED 跳过] Insert[🟩 INSERT
真新候选入库] Raw --> L1 L1 -->|命中| Merge L1 -->|miss| L2 L2 -->|命中| Merge L2 -->|miss| L3 L3 -->|命中| Merge L3 -->|miss| L4 L4 -->|相似度 ≥ 0.85| Review L4 -->|miss| L5 L5 -->|命中 BLOCKED| Block L5 -->|全部 pass| Insert classDef merge fill:#dbeafe,stroke:#2563eb,color:#1e40af classDef review fill:#fed7aa,stroke:#ea580c,color:#9a3412 classDef block fill:#fecaca,stroke:#dc2626,color:#991b1b classDef insert fill:#bbf7d0,stroke:#16a34a,color:#166534 class Merge merge class Review review class Block block class Insert insert
来自 Apollo/LinkedIn/WebSearch] L1{Layer 1
Authoritative ID
crunchbase / linkedin_urn} L2{Layer 2
Domain 归一化
cbsnorthstar.com} L3{Layer 3
Normalized name
去 Inc/LLC/标点} L4{Layer 4
Fuzzy match
+ 行业后缀剥离
相似度 ≥ 0.85} L5{Layer 5
Business rules
子域/HQ/champion 邮箱} Merge[🟦 MERGE_EXISTING
累加 source] Review[🟧 SUSPECT_REVIEW
进人审队列] Block[🟥 SKIP_BLOCKED
已 BLOCKED 跳过] Insert[🟩 INSERT
真新候选入库] Raw --> L1 L1 -->|命中| Merge L1 -->|miss| L2 L2 -->|命中| Merge L2 -->|miss| L3 L3 -->|命中| Merge L3 -->|miss| L4 L4 -->|相似度 ≥ 0.85| Review L4 -->|miss| L5 L5 -->|命中 BLOCKED| Block L5 -->|全部 pass| Insert classDef merge fill:#dbeafe,stroke:#2563eb,color:#1e40af classDef review fill:#fed7aa,stroke:#ea580c,color:#9a3412 classDef block fill:#fecaca,stroke:#dc2626,color:#991b1b classDef insert fill:#bbf7d0,stroke:#16a34a,color:#166534 class Merge merge class Review review class Block block class Insert insert
实测结果 — 7 raw → 3 入库 + 3 跳过 + 1 人审
| Raw 输入 | Action | Layer 命中 | 相似度 |
|---|---|---|---|
| Acme POS, LLC + domain | MERGE | 2 · domain | 1.00 |
| Pacific Retail Systems Inc | MERGE | 3 · normalized name | 1.00 |
| Example Hospitality Tech | MERGE | 3 · normalized name | 1.00 |
| AcmePOS Hospitality | SUSPECT | 4 · fuzzy + 行业剥离 | 0.96 |
| Lakeside Consulting | INSERT | — | — |
| Pretsl | INSERT | — | — |
| Craftable Integration Services | INSERT | — | — |
关键洞察: 同一公司可能以 4 种变体出现 — "Acme POS" / "Acme POS, LLC" / "AcmePOS" / "AcmePOS Hospitality"。Layer 1-3 抓硬重复(100% 准确),Layer 4 fuzzy + 行业后缀剥离抓软重复并进人审 — 准确率高且永不污染主表。
scripts/dedup.py 是可复用模块,所有 agent 入库前都调它。
🆕 Lark Base 集成 数据底座 + 团队看板
为什么所有数据在 Lark · 8 张表怎么映射 9 个 agent · 团队怎么用
核心理念:数据底座 = 团队可见层
传统做法:数据库(SQLite/Postgres)+ 单独建 dashboard(Metabase/Retool)给团队看 — 两层维护成本。
我们做法:Lark 多维表格同时是数据库和团队界面。agent 写 Lark = 数据库 + dashboard 同时完成。
flowchart LR
A[9 个 agent] -->|lark-cli
user 身份| L[(Lark Base
8 张表)] L --> W[Lark 网页] L --> M[Lark 手机 App] L --> K[看板视图
Kanban by Tier] L --> G[画廊视图
Gallery] L --> F[表单视图
Form 收集] W -.编辑.-> L M -.编辑.-> L classDef agent fill:#fef3c7,stroke:#d97706 classDef lark fill:#dcfce7,stroke:#16a34a,stroke-width:3px classDef view fill:#dbeafe,stroke:#2563eb class A agent class L lark class W,M,K,G,F view
user 身份| L[(Lark Base
8 张表)] L --> W[Lark 网页] L --> M[Lark 手机 App] L --> K[看板视图
Kanban by Tier] L --> G[画廊视图
Gallery] L --> F[表单视图
Form 收集] W -.编辑.-> L M -.编辑.-> L classDef agent fill:#fef3c7,stroke:#d97706 classDef lark fill:#dcfce7,stroke:#16a34a,stroke-width:3px classDef view fill:#dbeafe,stroke:#2563eb class A agent class L lark class W,M,K,G,F view
9 张表 × 9 个 agent 矩阵
| Lark 表 | 字段 | 当前条数 | 谁写 / 谁读 |
|---|---|---|---|
| Candidates | 9 | 38 | 写: sourcing / 读: qualifying(raw 池) |
| ★ Leads(新) | 15 | 28 | 写: qualifying / 读: outreach + meeting(追踪中) |
| ★ Partners | 14 | 0 | 写: meeting(MOA 后) / 读: cosell+commission+enablement(真合作) |
| Outreach Drafts | 6 | 10 | 写: outreach / 读: meeting |
| Review Queue | 7 | 0 | 写: sourcing (dedup 4 层) / 改: 渠道经理人审 |
| Meetings | 13 | 0 | 写: meeting / 读: partner-crm |
| Opportunities | 11 | 0 | 写: cosell / 读: commission / analytics |
| Commissions | 10 | 0 | 写: commission / 读: analytics |
| Activities | 8 | 0 | 写: enablement / partner-crm / analytics(通用日志) |
★ 关键拆表: 之前 Partners 表混着「raw qualifications」和「真合作」— 现在拆成 Leads(追踪中)和 Partners(真合作 MOA+)。
Partners 表的记录数 = 真合作伙伴数,不再被 raw 数据污染。
3 种工具的分工
| 工具 | 角色 | 用法 |
|---|---|---|
| lark-cli | 主力(批量 / 复杂 / 测试) | lark-cli base +record-batch-create ... |
| lark-mcp | (待 OAuth) 单条 CRUD 友好 | agent tool call |
| SQLite | 备份 + dedup 内部索引 | 性能 / 离线 |
关键差异化: 不需要单独的 Web Dashboard。agent 跑完工作流的同时,Lark Base 自动成为团队界面 — 渠道经理在 Lark App 看 Partners 的 Kanban,老板在 Lark 网页看 Commissions 表,Tier 评分错了直接改单元格。0 行 dashboard 代码,完整 BI 体验。
决策点矩阵 合规 / 财务
哪些必须人审 · 哪些自动 · 红线在哪
| 决策点 | 谁做 | 规则 |
|---|---|---|
| Tier S 邮件外发 | 👤 渠道经理 | 100% 人审 |
| Tier A 邮件外发 | 🤖 自动 + 👤 抽检 | 抽检 10% |
| Tier B 邮件外发 | 🤖 全自动 | 任何 reply 升级 |
| 折扣超 tier 上限 | 👤 Finance | 一律升级 |
| 返佣 > $10k 单笔 | 👤 Finance Controller | 强制审批 |
| 锁单冲突 | 👤 渠道 GM | 2+ partner 报同客户必裁决 |
| 客户邮箱域名 = partner 域名 | 👤 渠道 GM | 反作弊升级 |
| Champion 离职检测 | 🤖 sourcing 找替补 | 自动 + 通知 CM |
| Reply rate 下降 30% | 🤖 outreach 重写 | 自动 + 告警 |
| Tier S 30 天 stale | 🤖 告警 + 👤 跟进 | 每周一健康检查 |
vs Apollo · 核心差异 对外讲故事
为什么不直接用 Apollo · restosuite 渠道版的差异化
| 维度 | Apollo | restosuite 渠道版 |
|---|---|---|
| 目标对象 | 直接客户(餐厅) | 渠道合作机构 |
| Hook 重点 | 产品 demo / 功能 | 合作机会 / 返佣 / 客户复用 |
| 生命周期 | LEAD → MEETING → DEAL | LEAD → MOA → PILOT → ACTIVE |
| 独有模块 | — | Enablement Co-sell Commission |
| 审批门 | 弱 | 强(Tier S 必审 + $10k 必审 + 冲突必裁决) |
| 数据源 | 主要 Apollo DB | Apollo + LinkedIn + Crunchbase + 行业协会 |
| 团队可见层 | 需登录 Apollo | Lark App / Web — 渠道经理本来就在用 |
| 移动端 | Apollo App | Lark App(已装) |
| 看板 / Form / 画廊 | 有但少 | Lark 原生 + 0 代码 |
📦 当前项目状态
已交付的产物 · 文件结构 · 端到端 demo 结果
已交付文件:
restosuite-channel-agent/ ├── 25+ 文件 · ~5,000 行 ├── .claude/agents/ ✓ 9 个 sub-agent (全部用 Lark) ├── .claude/skills/ ✓ recruit-partners 主 workflow ├── .claude/memory/ ✓ icp.md / products.md / channel-policy.md │ ✓ lark-tables.md (8 张表 ID + 字段映射) ├── data/partners.sqlite ✓ SQLite 备份 (15 表) ├── drafts/PRTN-001..005/ ✓ 5 封个性化邮件草稿 ├── scripts/dedup.py ✓ 5 层去重模块 (可复用) ├── scripts/serve.py ✓ 本地预览 server ├── docs/architecture.html ← 你正在看的 └── docs/USER_MANUAL.html ✓ 操作说明书
Lark Base (主数据底座 · 9 张表):
渠道拓展 CRM (XXXXXXXX-internal-base) ├── Candidates 846 条 (raw 池 — 8 国:US/UK/CA/CN/MY/ES/AU/JP) ├── ★ Leads 700 条 (追踪中 — S 14 / A 459 / B 210 / OOR 17,659 待人审) ├── ★ Partners 1 条 (真合作 MOA+ — Summit Integrations ✓干净) ├── Outreach Drafts 10 条 (PENDING_APPROVAL · 代表性草稿) ├── Review Queue 18 条 (模糊待审重复) ├── Meetings 0 条 (等首场会议) ├── Opportunities 0 条 ├── Commissions 0 条 └── Activities 0 条 (通用日志)
最近更新 — Leads / Partners 拆分 + 纽约 sourcing:
- 🆕 拆 Leads / Partners 两张表 — Partners 表只放真合作 MOA+,Leads 装追踪中
- 纽约 10 个真实渠道 sourcing 完成(NYSRA / Summit Integrations / JK Consulting 等)
- 9 个 agent.md spec 全部更新数据契约 — qualifying 不能写 Partners
.claude/memory/lark-tables.md加入 Candidates → Leads → Partners 三段式流转图- 数据彻底干净:Partners 表 0 条 = 真 partner 数 0(不再误导)
端到端 demo 结果(已跑通):
| Tier | Partner | 分 | 关键理由 |
|---|---|---|---|
| S | Acme POS | 87 | 多 vendor + 多模块 integrator,完美 bundle |
| A | CRSI (SpotOn) | 83 | SpotOn 互补不冲突,Central CA fine dining |
| A | EHT | 82 | 2006 老牌,PM 全部餐饮一线背景 |
| A | Example POS CA | 82 | CA/AZ/NV 三州,loyalty 数据闭环 |
| A | Riverside Consulting | 74 | POS-agnostic 咨询,推荐方价值 |