抖音来客 × 飞书客资同步

某医美连锁企业 2026.02 – 2026.03 交付 长期稳定运行

以前客资从广告后台到运营手里要隔上一天,现在几分钟就到;中间还被 22 次静默失败上过一课,从此这条链路失败必有人知道。

业务问题

企业在抖音投广告获客,线索(客资)落在抖音来客后台;但运营团队的工作台在飞书多维表格。每天人工导出、粘贴、核对——慢、易漏、没法关联广告数据算 ROI。

方案

一条全自动数据管道:抖音开放平台 API 拉取线索 → 解密 → 关联广告投放数据 → 写入飞书多维表格 → 定时增量同步 + 异常监控。运营团队从此只看飞书一个界面。

平台侧客资 手机号为密文 定时同步任务 分钟级 解密 + 广告数据关联 还原来源与花费 协作表格 销售直接跟进 异常监控告警 任一环节失败都会告警到人,不静默丢单——客资延迟从「天」级降到分钟级
整条链路只做一件事:让销售在分钟级看到能直接打的客资,且失败必然有人知道。

不性感但真实的坑

这类「数据打通」项目的难点全部藏在细节里:

  • 加密手机号解密——抖音对客资手机号加密,需要正确处理密钥和解密流程
  • IP 白名单的两层配置——开放平台和应用两层各有白名单,漏配一层接口就静默失败
  • 飞书字段类型陷阱——日期、公式、选项字段各有格式限制,写错类型不报错但数据不对
  • 「假成功」——飞书接口返回成功但数据实际没写入,必须回读校验
这个项目让我养成一条铁律:「看起来在跑」不等于「真的在工作」。上线后曾发现定时任务静默失败了 22 次而没有任何报警——从此所有自动化任务必须有可观测指标和失败告警,沉默的成功和沉默的失败在外观上是一样的。

结果

交付后长期稳定运行,客资从广告后台到运营工作台的延迟从「天」级降到分钟级,并且第一次让广告数据和到店转化能在同一张表里对上。

这类项目不性感,但它恰恰是企业最真实的需求形态:不是「上一个 AI」,而是把数据接通、把重复劳动消掉、让人只处理值得人处理的事。

相关复盘:《cron 静默失败了 22 次,我才明白什么叫「看起来在跑」》