「客户写了——你就保存了」听起来像现成系统，实为自动化幻觉。没有集成，号码只躺在 WhatsApp 聊天记录里——无日期、来源、状态，与上百条无法区分。如何把入站对话变成真实结构化记录，而非一个月后需手动翻找的条目。
「写了就保存」暗示 WhatsApp 自建名单库。并非如此：入站消息只是对话，直到你配置机制将其转为结构化记录。「聊天里有联系人」与「库里有带历史的联系人」——流失线索 vs 运转中的漏斗。
之前：
每条入站对话已是温联系人。如何自动导出所有来信号码到结构化库。
之后：
每条入站对话是温联系人的原料。要成为库而非仅聊天历史，需集成：WABA 与 webhook + CRM，或普通 WhatsApp Business App 的第三方方案。无此步号码留在 messenger 内，首次清理聊天即丢失。
之前（隐含）：
入站联系人赋予无时间限制的群发权利。
之后：
入站联系人开启 24 小时免模板回复服务窗。此后非免疫——只是更高起点信任；不相关重复触达仍会投诉，与任何名单相同——见群发封禁机制。
| 场景 | 工作方式 | 风险 |
|---|---|---|
| WABA + webhook + CRM | Meta 服务器每次入站向你的 URL 发 JSON（wa_id、资料名、时间戳） |
官方，风险最低 [✓] |
| WhatsApp Business App + CRM 连接器 | 第三方连接器（HubSpot、Zoho、Bitrix24 类）经 QR 或号码连接，入站建卡 | 半官方，取决于集成商 |
| WhatsApp Web 解析器 / Baileys / msgstore.db | 从 JID、本地库或浏览器扩展提取号码 | 灰色，号码与数据均有风险 |
官方 WABA 入站包结构有文档：号码、资料名（push name，非证件名）、文本、时间戳自动到达——CRM 无需客服建卡。普通 WhatsApp Business App 无 Meta 级自动化——需 HubSpot、Bitrix24 类集成商。
Bitrix24：联络中心 → 虚拟 WhatsApp → 开放线路 → 指定负责人 → 连接。HubSpot/Zoho 类 CRM：市场应用、扫 QR 或号码登录，再选线索分配——管道、阶段、指定经理。非一次性导出——每条新入站自动建卡的常驻通道。
若需恢复已有入站聊天历史——若起初未配 webhook，Meta 无官方追溯导出工具。企业须手动补：手机 设置 → 导出联系人 → CSV，或第三方解析器与浏览器扩展从聊天/群组历史抓号——与自动化方法图中的灰色方案同类。
专家投放广告要求 WhatsApp 发送口令。WABA 侧配 webhook：收到口令即自动进 CRM，带来源标签、日期并自动发指南。一周名单增至 3400。一月后重复触达：0 封禁、22% 成交。
表明： 入站瞬间自动记录来源与标签省去人工分拣，重复触达可量化。未证明： 任何 niche 均保证或任意重复量均 0 封——单案例，非通用规范。
反面：店铺在普通 WhatsApp Business App 收集入站，脚本导出 Excel。三月后对同批 1500 号用廉价点击器激进折扣群发——无文案随机化、高速发送。尽管温库，第 400 条封禁。两案： 库温不取消发送速度与质量要求——不同风险层。
裸号码——数月后几乎无用。卡片最低字段：
messenger 营销专家建议在 wa.me/?text=... 链接嵌入 UTM——入站瞬间自动记录来源与兴趣类别，无需客服手标。
「客户写了就自动进库」 错。无 CRM 集成或 webhook，联系人仅在 WhatsApp 聊天历史，易丢。
「保存号码就够」 不完整。无日期、来源、状态，记录很快成无法分群的废行。
「入站联系人赋予无时间限制群发权」 错。仅确认客户最后消息后 24 小时服务窗——此后更高起点信任，非免疫。
「记录入站必须用 WABA」 不准。普通 WhatsApp Business App 有半官方 CRM 集成路径，但 WABA 仍是最可预测、有文档的官方选项。
「随时可官方导出全部历史来信者」 未证实。Meta 无官方历史入站联系人追溯导出——须在历史堆积前解决。
入站咨询仍只沉在 WhatsApp 聊天里——先做一项集成（WABA 或 CRM 连接器）并强制字段：日期、来源、状态。比事后用解析器捞丢失名单省时间。
实践规则：
客户主动找你是礼物。没有日期、来源和状态，你会第二次弄丢他。
