lead-communication-history

潜在客户沟通历史

目标

根据已存储的消息正文和通话转录，回答与特定潜在客户相关的沟通问题，并准确说明渠道、方向和时间。不要用跨潜在客户的搜索预览或会议转录替代该潜在客户的沟通时间线。

工作流

1. 准确确定一个 lead_id。
   • 有当前潜在客户范围或明确 ID 时，使用该范围或 ID。
   • 否则，使用此人的姓名、电子邮件或电话号码调用 list_leads。
   • 如果仍有多个可能的潜在客户，请列出区分信息并询问用户要查询哪位；绝不要合并他们的历史记录。
2. 调用 get_lead_history 获取所需内容。
   • 对于所有支持的沟通渠道，传入 channel: "call,whatsapp,email,sms"。
   • 对于单个渠道，传入其准确的小写名称。
   • 查询最新内容时使用 order_by: "desc"；撰写按时间顺序排列的叙述时使用 order_by: "asc"。
   • limit 最大可设为 200。如果 pagination.has_more 为 true，且答案需要完整历史记录，则递增 offset 并继续查询，直到其为 false。
3. 根据返回的条目类型读取内容。
   • WhatsApp 和 SMS：type: "message"；读取 direction、content、附件、状态和 timestamp。
   • 电子邮件：读取 type: "email" 条目中的主题、正文和投递详情，以及 type: "message", channel: "email" 条目中的对话内容。根据方向、时间戳、存在时的提供商 ID、主题和正文核对重叠记录，避免将同一封邮件重复计数。
   • 电话：type: "call"；读取 summary 和 transcript。call_missed 条目没有对话转录。
   • 将 direction: "outbound" 视为 Nexor 或操作员发出的内容，将 direction: "inbound" 视为收到的潜在客户内容。
4. 仅在需要时使用相应的辅助工具。
   • 使用 search_conversations 搜索多个潜在客户，不要将其作为针对某一位潜在客户的证据：它返回有限的预览，且没有 lead_id 筛选条件。
   • 使用 list_transcripts，然后调用 get_transcript 获取已安排会议的转录。这些工具不会检索电话通话转录。
   • 用户询问已知消息或时间点附近的上下文时，在 get_lead_history 中使用 anchor_ts、before 和 after。
5. 根据检索到的证据作答。将沟通事件与沟通内容区分开来：先说明发生了什么，再说明实际说了什么。对重要陈述注明渠道、方向和时间戳。

防护措施

• 当 pagination.has_more 为 true 时，不得声称历史记录完整。
• 不要根据摘要、失败的通话、附件、空正文或截断／缺失的转录推断缺失内容。应说明哪些内容不可用。
• 不要把会议摘要称为电话通话转录，也不要把投递／打开事件称为电子邮件回复。
• 不要将未接通或无人接听的电话视为电话号码无效的证据。
• 严格限定租户和潜在客户范围。绝不要用一位潜在客户的沟通内容回答另一位潜在客户的问题。
• 这是只读工作流。除非用户另行请求，否则不要发送回复、修改潜在客户信息或启动／停止自动化。

输出

• 开篇直接给出答案或简明的时间线。
• 区分外发内容、收到的回复、通话转录陈述以及仅与投递有关的事件。
• 指明影响可信度的信息缺口，包括缺失的转录、空正文、未以文本呈现的附件或尚未读取的页面。