核心用法
Lead Inbox Automator 是一个面向销售场景的自动化技能，主要解决线索捕获后的数据管理与自动跟进问题。其核心工作流分为四步：首先通过 createLead()() 将潜在客户信息录入 Supabase 数据库，同时触发 Make.com 的 Webhook 发送自动回复邮件；随后可通过 getAutomationStatus()() 验证邮件发送状态；在人工跟进阶段，使用 updateStatus()() 更新线索状态（如标记为"qualified"），并用 addConversation()() 记录沟通内容；最后通过 listLeads()() 和 getLead()() 进行线索筛选与详情查看。
该技能采用双表结构存储数据：leads 表保存客户基本信息与元数据，conversations 表记录完整的沟通历史，支持 inbound/outbound/automated 三种消息方向标识。
显著优点
1. 开箱即用的自动化闭环：无需自行搭建邮件服务，通过 Make.com 集成即可实现"捕获-确认-跟进"的自动化流程，大幅降低销售团队的响应延迟。
2. 灵活的数据扩展能力：custom_fields 和 metadata 两个 JSON 字段允许存储任意业务数据，适应不同行业的线索信息采集需求。
3. 内置防重复机制：24 小时内的邮箱去重逻辑有效避免同一客户的重复录入，减少数据清洗成本。
4. 多租户数据隔离：通过 org_id 字段实现组织级别的数据隔离，适合 SaaS 化部署或多团队共用场景。
5. 清晰的会话追踪：conversations 表的 direction 字段明确区分自动回复、人工回复和客户消息，便于后续分析各渠道的转化效果。
潜在缺点与局限性
1. 外部服务强依赖：核心功能依赖 Supabase 和 Make.com 的可用性，任一服务中断都会导致线索捕获或自动回复失败，且缺乏本地降级方案。
2. 邮件能力受限：自动回复仅支持基础触发，无法直接在技能内定制邮件模板、A/B 测试或发送时机策略，需完全依赖 Make.com 的配置。
3. 权限模型粗放：要求使用 Service Role Key 而非 Anon Key，意味着该密钥拥有数据库完全访问权限，一旦泄露后果严重，且无法通过 RLS 进行细粒度控制。
4. 缺乏实时通知机制：没有 WebSocket 或回调机制通知新线索到达，需要主动轮询 listLeads()() 或依赖外部系统。
5. 数据合规责任转移：虽然技能本身不存储数据，但用户需自行确保 Supabase 实例符合 GDPR 等法规要求，对于缺乏合规经验的团队存在隐患。
适合的目标群体
- 中小销售团队：需要快速上线、预算有限，不愿自建 CRM 系统的团队
- SaaS 产品运营：希望将产品内用户行为自动转化为销售线索的产品经理
- 数字营销机构：管理多个客户项目，需要 org_id 隔离的多租户场景
- Clawd 生态用户：已在使用 Clawd 代理平台，希望扩展销售能力的现有用户
不适合对数据主权要求极高的大型企业、需要复杂邮件营销编排的市场团队，以及缺乏 Supabase 运维经验的技术薄弱团队。
使用风险
1. 密钥泄露风险：Service Role Key 的泄露将导致整个数据库暴露，建议配合密钥管理服务使用并定期轮换。
2. 性能瓶颈：Supabase 免费 tier 有连接数和 RPS 限制，高并发场景下可能出现自动化触发延迟或失败。
3. 数据丢失风险：Make.com 的 Webhook 调用失败不会自动重试（需自行在 Make 中配置），极端情况下可能导致客户未收到自动回复。
4. Schema 变更兼容性：若用户自行修改 leads/conversations 表结构，可能导致技能报错，升级时需谨慎。