官方文档 · 总入口 抖音开放平台
本清单以生活服务商家应用文档指引为总核对依据。各流程章节正文末尾附有「本章官方文档对照」入口;完整链接总表见文末「官方文档附录」。
Chapter 01 · Decisions
决策口径与目标
本次执行口径(会议结论落档)
会议决定:本期本清单只专注推进抖音团购核销接入(抖音直连)。美团侧已确认经 汇付天下 ISV 接入,由 戴凡 推进;美团落地细节不在本清单范围,另行补充。剑琅以技术服务商身份入驻抖音开放平台服务商平台(partner.open-douyin.com),创建第三方生活服务商家应用并申请到综行业解决方案(美业属丽人、到综类目),完成门店授权后,在剑琅联盟 APP 内实现「扫码 → 验券 → 核销 → 自动开单 → 业绩归因」。B 端 APP 仅手机端、无 PC 端,门店不开扫码枪,核销识码由店员用手机摄像头直接扫顾客手机屏幕上的抖音券码完成(复用 APP 已有扫码组件 + 手动输码兜底,详见 PRD A 组)。核销开单产生的顾客记录将通过手机号主键归入共享客户档案,为 C 端小程序「剑琅美遇」的记录查看与营销触达预留衔接(详见下方 B–C 联动卡片)。
M1 · 就绪里程碑
平台侧推进 + 开发接近完成
完成服务商入驻与对公认证、创建应用、提交到综解决方案申请;后端完成核销核心链路开发(mock/沙箱可联调)。
提示:平台能力认证审核约 10 个工作日,建议在启动后第 1 周内完成提交,预计第 3 周前后通过——M1 为尽力目标,平台环节若超时则顺延,开发工作不等待平台。
提示:平台能力认证审核约 10 个工作日,建议在启动后第 1 周内完成提交,预计第 3 周前后通过——M1 为尽力目标,平台环节若超时则顺延,开发工作不等待平台。
M2 · 上线里程碑
试点门店真实券可用
3-5 家试点门店完成抖音来客授权、完成真实团购券核销测试与平台验收,店员用剑琅联盟 APP 手机摄像头扫顾客屏幕核销真实券并自动开单可用(无 PC / 扫码枪);对账与退款回调随版本上线。
提示:预计启动后第 4-5 周前后达到,随平台审核与联调进度滚动刷新。
提示:预计启动后第 4-5 周前后达到,随平台审核与联调进度滚动刷新。
MVP 功能范围(本期全部纳入)
| 能力 | 说明 | 优先级 |
|---|---|---|
| 团购券扫码核销 | 验券准备 → 验券 → 自动开单 → 员工业绩归因;二维码短链转长链解析。纯手机端操作:店员用 APP 摄像头扫顾客屏幕券码(复用已有扫码组件),不依赖 PC / 扫码枪,手动输码兜底 | P0 |
| 撤销核销 | 误核销撤销(平台限制:核销后 1 小时内可撤) | P0 |
| 券状态查询 / 批量查询 | 核销异常场景定位与补处理 | P1 |
| 团购对账 | 平台账单 ↔ 剑琅开单比对、差异标记(首批可按日/周导出人工复核) | P1 |
| 信息同步回调 | 接收平台退款等通知(官方验收必接项),本地自动冲销 | 必接 |
| 次卡支持 | 多次卡按次核销 / 按次撤销(依赖门店是否售卖次卡商品,需专项测试) | P2 |
B–C 联动 · 剑琅美遇小程序(本期范围之外,方案预留)
产品矩阵定位:剑琅联盟 APP 为 B 端(门店经营 / 店务管理),剑琅美遇为与之关联对接的 C 端微信小程序(面向顾客);两端已共享同一会员 / 客户数据中心。本次抖音团购核销是「抖音公域客流 → 门店私域会员」转化的关键触点,C 端小程序作为承接方,本期不开发、按 后续迭代 预留方案与接口契约。
| 口径 | 说明 |
|---|---|
| 角色定位 | 抖音公域客流 → 剑琅美遇私域会员的转化承接:顾客名下核销 / 消费记录的 C 端可查,以及核销后的 营销触达(到店券、预约、次卡剩余与到期提醒)。不承接交易支付——资金结算仍走抖音平台直结,规避调研中「C 端支付信任度低」短板。 |
| 身份关联方案 | 两端共享同一客户数据中心,采用手机号为主键:店员 B 端核销 / 开单时按手机号登记或选择门店客户档案;顾客在剑琅美遇以微信手机号授权登录后自然归并到同一客户档案,即可查看名下核销记录与资产。 |
| 本期边界 | 小程序侧 UI / 功能均不占用本期(第 1-5 周)排期;本期仅在 B 端核销链路中预留「客户手机号登记」落库字段与数据契约,供后续小程序端直接消费同一档案数据。 |
| MVP 范围 | 小程序相关功能不在本期 MVP 表内;列为后续迭代功能清单(见本卡下方「小程序侧 · 后续迭代功能范围」),由独立产品 / 前端 / 后端同事负责排期。 |
小程序侧 · 后续迭代功能范围(无积分体系)
- 到店转化承接核销成功页 / 开单记录提供「去小程序领券」入口,引导顾客注册并发放门店优惠券(复用现有券体系)。
- 记录查看顾客查看名下抖音团购核销记录、对应开单 / 消费记录与券状态。
- 次卡与预约承接次卡剩余次数 / 到期提醒、到店预约入口;小程序内以卡券核销与储值为主(含再次到店触达)。
Chapter 02 · Timeline
总体排期与关键路径
启动时间待定,以「第 N 周」相对推进(启动后换算为具体日期);关键路径 = 平台审核(不可压缩),其余全部并行
第 1 周
启动入驻 + 材料前置 + 试点确认
启动后即提交服务商入驻与「生活服务商家应用代开发」能力认证;同时后端启动架构设计与 client_token 自测;产品确认 3-5 家试点门店清单与培训物料框架。
第 2 周(与 RTB 开发高峰周并行)
平台审核等待期 → 开发主力期
平台侧在审:开发不等待。客户端复用已有扫码组件开发手机摄像头识码 / 扫码页(含手动输码兜底、补光、失败引导);后端按 mock 契约先行开发验券 / 验券准备 / 撤销 / 券状态接口封装与自动开单联动(P0 主链路),client_token 用测试凭据验证。
M1 · 就绪里程碑(预计第 3 周前后)
对公认证 + 应用创建 + 解决方案申请/开通 + 主链路就绪
能力认证通过后立即完成对公认证(建议法定代表人支付宝人脸,实时完成);创建应用(1 工作日);提交到综解决方案(约 3 工作日)。后端完成核销主链路开发并进入联调。若平台审核超出预计周次,本里程碑的平台环节顺延,开发就绪不受影响。
第 4 周前后
门店授权 + 沙箱/测试商品联调 + 回调对账次卡开发
试点门店在抖音来客完成对剑琅应用授权,服务商侧确认授权关系并绑定 poi_id;联系抖音 BD 开白「测试商品」或使用测试账号完成真链路联调;完成信息同步回调、团购对账与次卡支持开发测试。
M2 · 上线里程碑(预计第 4-5 周前后)
3-5 家试点门店真实券上线
灰度 1 家 → 扩至 3-5 家;店员培训与客服 FAQ 就绪;对账报表上线。上线后运营复盘,确认是否进入全量推广与后续 SaaS 内嵌授权升级。
| 时间 | 平台侧(关键路径) | 后端 / 产品侧(并行,不等待平台) |
|---|---|---|
| 第 1 周 | 提交服务商入驻 + 能力认证(基础/经营信息) | 架构设计、接口契约梳理、试点门店清单确认、材料收集 |
| 第 2 周 | 能力认证审核中(约 10 工作日) | P0 主链路开发:客户端摄像头识码 / 扫码页(复用扫码组件)+ 后端验券准备/验券/撤销/状态 + 自动开单;与 RTB 批次错峰排期 |
| 第 3 周 | 对公认证 → 创建应用(1 工作日)→ 到综解决方案申请(约 3 工作日) | 主链路联调、异常/幂等场景;P1 开始(信息同步回调、对账) |
| 第 4 周 | 解决方案开通 → 门店授权 → 测试商品开白 | 回调 / 对账 / 次卡开发测试;真链路联调与内部验收 |
| 第 5 周前后 | 平台验收通过 | 试点门店灰度上线 → 3-5 家真券可用;培训与运营支持上线 |
| 后续迭代 | — | 小程序侧(剑琅美遇)排期另行立项;B 端手机号落库契约在本期主链路中已预留 |
Chapter 03 · RACI
责任分工(角色占位)
责任人待定,会上认领后填入
| 阶段 | 产品 | 客户端 / 前端 | 后端 | 测试 | 商务 / 法务 | 运营 / 客服 |
|---|---|---|---|---|---|---|
| 平台入驻与认证 | 配合 | - | - | - | 负责 | - |
| 应用创建与解决方案 | 配合 | - | 负责 | - | 配合 | - |
| 试点门店授权与绑定 | 配合 | - | 负责 | - | - | 负责 |
| 接口开发与联调 | 负责(流程与规则) | 负责(摄像头识码 / 扫码页) | 负责(实现) | 配合 | - | - |
| 测试与验收 | 配合 | 配合 | 配合 | 负责 | - | 配合 |
| 培训、上线与对账 | 配合 | - | - | 配合 | - | 负责 |
说明:「负责」为该项主要责任人;「配合」为提供输入或承接落地动作。客户端 / 前端为新增列,承接手机端摄像头识码与扫码页开发(复用 APP 已有扫码组件)。所有 占位角色 请在启动会上确认到具体人员,建议本项产品牵头、商务/后端双线执行,每周至少一次对齐会(与 RTB 例会合并)。
Chapter 04 · Product
产品经理交付物:PRD 与原型设计
P0 主链路 PRD 需在第 1 周末前定稿、支撑第 2 周开发启动;本章定义需覆盖的功能需求条目与原型页面,原型稿由产品经理产出(Figma 等工具),字段级细节在 PRD 正文展开
交付节奏与依赖
| 时间 | 交付物 | 依赖 / 对接 |
|---|---|---|
| 第 1 周 | 需求梳理 + 核销主链路原型 v0.5 | 与后端确认接口能力边界(验券结果字段、券信息展示口径) |
| 第 1 周末前 | 原型评审(内部 + 试点店长)+ PRD v1(主链路)定稿 | P0 开发(第 2 周)启动前交付,评审结论纳入 |
| 第 2 周 | 撤销 / 异常 / 业绩归因等补丁需求 | 与后端 P0 开发并行,不阻塞主链路 |
| 第 3 周起 | 对账 / 回调 / 次卡的 PRD 与原型 | 配合 P1/P2 开发批次,错峰排期 |
| M2 前后 | 店员操作手册与 FAQ 内容定稿 | 与运营协作输出,供门店培训使用 |
功能需求条目(PRD 需覆盖)
条目编号用于挂接后端交付项(P0/P1/P2)与 测试用例清单;范围以 决策口径 的 MVP 为准,次卡是否纳入取决于试点门店是否售卖次卡商品。
A · 核销主流程(店员端 APP)— P0
| 编号 | 需求要点(含状态 / 异常) | 对应原型页面 |
|---|---|---|
| R-01 | 核销入口:开单 / 收银页提供「抖音核销」,默认唤起手机摄像头识码(复用 APP 已有扫码组件,无 PC / 扫码枪),可切换手动输码兜底;相机无权限 / 离线需提示 | 核销入口 |
| R-02 | 扫码解析:摄像头识码读出短链不截断 → 转长链 → 调验券准备;识别失败给「调亮屏幕 / 避开反光」引导,可重扫或转手动输码;无可用券 / 券已过期给明确文案 | 扫码页 |
| R-03 | 验券结果:展示商品 / 面额 / 门店 / 有效期,次卡含剩余次数;业务失败(result≠0)按原因分类提示 | 验券结果页 |
| R-04 | 二次确认:展示待核销券 + 将自动生成的开单预览(价目项目 / 金额 / 默认员工),确认后才调核销 | 核销确认页 |
| R-05 | 核销成功联动:自动生成开单,可补充客户信息,按门店默认规则归因业绩 | 核销成功页 |
| R-06 | 幂等与重复:同券重复扫码仅核销一次;成功页含券码 / 平台单号并支持复制 | 成功 / 提示页 |
-
摄像头识码复用与体验(对应 R-01 / R-02,复用 APP 已有扫码组件)复用现有扫码组件:识别抖音券码短链文本,不做重复的识码 SDK 集成。识码页提供手电筒 / 补光开关(弱光、暗屏场景);识别失败给「调亮屏幕 / 避开反光 / 摘除手机膜」引导文案并可重扫;识别成功提供震动 + 提示音反馈便于连续快速操作(逐张核销,扫一张即进验券流程)。若复用组件已具备补光 / 提示音能力则直接随组件覆盖,不重复开发。
-
手动输码兜底(无 PC / 扫码枪时的备用入口)当顾客券码在他人手机、屏幕过暗或多次识别失败时,可切「手动输入券码」完成同样流程;输码页校验格式并提示可复制粘贴长链。
B · 撤销核销与异常边界 — P0
| 编号 | 需求要点(含状态 / 异常) | 对应原型页面 |
|---|---|---|
| R-07 | 撤销入口:核销记录详情可撤销;距核销 1 小时内可撤,超时置灰并引导平台客服流程 | 核销记录详情 |
| R-08 | 撤销冲销:撤销成功后开单作废 / 冲销、业绩回滚,并保留撤销流水 | 撤销结果提示 |
| R-09 | 异常处理:网络超时可安全重试(幂等);核销失败按原因分类提示并提供下一步指引 | 失败 / 异常提示页 |
C · 门店授权与映射(运营后台 / 店长端)— P1
| 编号 | 需求要点(含状态 / 异常) | 对应原型页面 |
|---|---|---|
| R-10 | 授权引导与状态:抖音来客手动授权步骤引导;状态机 = 未发起 / 待确认 / 已授权 / 已到期 | 门店授权列表 |
| R-11 | 门店映射:poi_id ↔ 剑琅门店绑定 / 解绑,授权到期提醒 | 门店映射配置 |
| R-12 | 权限与业绩:按门店配置核销范围与默认业绩归属规则,防止跨店核销 | 权限 / 归属配置 |
D · 团购对账(运营后台)— P1
| 编号 | 需求要点(含状态 / 异常) | 对应原型页面 |
|---|---|---|
| R-13 | 数据比对:平台账单与本地开单按 券码 / 金额 / 门店 / 时间 逐笔比对,支持按日 / 周批次 | 对账报表 |
| R-14 | 差异处理:差异自动标记并分类(缺本地单 / 金额不符 / 平台退款),人工确认流转 | 差异明细页 |
| R-15 | 报表导出:日期 / 门店 / 券码 / 商品 / 面额 / 状态 / 平台单号 / 剑琅单号 / 差异原因 | 报表导出 |
E · 信息同步回调(退款自动冲销)— 必接
| 编号 | 需求要点(含状态 / 异常) | 对应原型页面 |
|---|---|---|
| R-16 | 退款冲销:平台退款通知验签后本地自动冲销开单 / 更新券状态,写入退款流水 | 退款冲销记录 |
| R-17 | 可见性:店员开单记录显示冲销标识;运营后台可查询退款与冲销明细 | 记录标识 |
F · 次卡支持(视试点门店售卖情况,与后端确认)— P2
| 编号 | 需求要点(含状态 / 异常) | 对应原型页面 |
|---|---|---|
| R-18 | 按次核销:券信息展示总次数 / 已用 / 剩余;支持一次核销多份(可选份数) | 验券结果(次数选择) |
| R-19 | 按次撤销:撤销后剩余次数正确恢复;分门店结算门店不展示按次撤销(后端约束) | 撤销 / 记录详情 |
G · 小程序侧联动(剑琅美遇 · 后续迭代,本期仅落库契约)— 后续
| 编号 | 需求要点(含状态 / 异常) | 对应原型页面 |
|---|---|---|
| R-20 | 客户手机号登记:B 端核销 / 开单支持按手机号登记或选择客户档案;本期落库字段须与共享客户数据中心一致(手机号为主键) | 核销成功页(补客户信息) |
| R-21 | 小程序登录归并:剑琅美遇以微信手机号授权登录,命中同一客户档案即归并,查看名下抖音核销记录 | 小程序登录 / 记录页 |
| R-22 | 核销成功引导:核销完成页提供「去小程序领券 / 查看记录」入口(复用现有优惠券体系,无积分) | B 端成功页 + 小程序领券承接 |
| R-23 | 次卡与预约承接:小程序内查看次卡剩余 / 到期提醒、提供到店预约入口与再次到店触达 | 小程序次卡 / 预约页 |
原型页面清单(由产品经理产出)
| 端 | 原型页面 | 页面要点 / 状态说明 |
|---|---|---|
| 店员端 APP | 核销入口(开单页 / 收银台) | 入口位置与可用态;无权限 / 离线态提示 |
| 扫码 / 手动输码页 | 摄像头识码框 + 补光开关 + 失败引导文案;手动输码入口、取消返回(复用 APP 扫码组件样式) | |
| 验券结果页 | 券信息卡;可核销 → 去核销;失败 → 分类文案 + 返回 | |
| 核销二次确认页 | 开单预览 + 业绩归属展示;确认 / 取消 | |
| 核销成功页 | 券码 / 平台单号、补客户信息入口、完成返回 | |
| 失败 / 异常提示页 | 原因分类、重试按钮、客服引导 | |
| 核销记录详情 | 撤销按钮与剩余时限状态(1 小时内 / 已超时置灰) | |
| 次卡份数选择(可并入验券结果页) | 剩余次数展示 + 选择本次核销份数 | |
| 店长 / 店主端 | 授权指引页 | 跳转抖音来客完成授权的步骤说明 |
| 业绩归属默认配置 | 默认员工 / 归因规则设置(与 R-05、R-12 呼应) | |
| 运营后台 Web | 门店授权列表 | 授权状态(未发起 / 待确认 / 已授权 / 已到期)、到期提醒 |
| 门店映射配置 | poi_id ↔ 剑琅门店绑定 / 解绑(R-11) | |
| 对账报表页 | 汇总、筛选、导出(R-13 / R-15) | |
| 差异处理页 | 差异明细、确认 / 驳回流转(R-14) | |
| 退款冲销记录 | 退款 / 冲销流水查询(R-16) | |
| 剑琅美遇小程序(C 端 · 后续迭代) | 微信手机号授权登录 | 授权后归并共享客户档案;未授权仅浏览态提示(R-21) |
| 我的核销记录 | 名下抖音核销记录、对应开单 / 消费记录与券状态(R-21) | |
| 领券承接页 | 核销引导落地:到店券领取 / 我的卡券包;无积分体系(R-22) | |
| 次卡 / 预约页 | 次卡剩余与到期提醒、到店预约、再次到店触达(R-23) |
横切状态模板:空态 / 断网 / 超时 / 无权限 四类通用提示页建议统一设计,覆盖全部页面。
PRD 评审与验收要求
-
可追踪性PRD 条目带编号(R-xx),挂接后端交付项(P0/P1/P2)与 测试用例清单(Phase 5),任一改动可追溯到人 / 需求 / 用例。
-
必备覆盖重复核销幂等、异常与边界、退款回调冲销、撤销 1 小时时限、跨门店权限,缺一不可入审。
-
埋点建议核销入口打开率、验券结果分布、核销成功率、失败原因占比、撤销率,作为上线复盘与后续优化依据。另加「摄像头识码成功率 / 识别失败重扫率」:手机扫手机屏是本期关键体验点,用该指标评估贴膜 / 亮度 / 反光等场景是否影响核销效率,作为是否需补充硬件(蓝牙扫码枪)或强化引导的判断依据。
-
评审节奏主链路原型 v0.5 先内部评审 → 携试点店长确认 → 冻结后再进 P0 开发(第 2 周);P1/P2 需求随开发批次滚动评审,避免阻塞排期。
-
版本与变更PRD 记录版本与变更日志;平台规则变化(撤销时限、接口字段、费率)同步修订并通知后端 / 测试。
Chapter 05 · Phase 1
① 服务商平台入驻与资质认证
启动后第 1 周内完成提交;平台审核约 10 个工作日,是整个项目不可压缩的关键路径
前置材料清单(当天可备齐)
-
确定入驻主体与对公账户以营业执照主体为准(名称、统一社会信用代码需与法人主体一致);准备对公账户信息用于后续对公认证。
-
营业执照与盖章入驻函电子版营业执照需显示查询时间在 15 天内;入驻函需签字并盖章,盖章主体与入驻机构名称保持一致。营业执照扫描件尽量高清、无水印遮挡。
-
应用工具介绍材料认证「第三方应用代开发」能力需上传应用工具相关介绍(介绍剑琅联盟 APP:面向美业门店的 SaaS 收银管理系统,包含开单、核销等能力,服务场景需描述具体)。
-
法定代表人身份证与实名手机号用于对公认证的法定代表人/经营者人脸识别验证;提前确认其支付宝为本人实名且方便扫码。
-
应用图标(后续创建应用用)建议使用能展示剑琅品牌信息的图片,png / jpg / jpeg,尺寸 < 256×256 像素,≤ 120KB。
-
注册服务商平台账号访问抖音开放平台服务商平台(partner.open-douyin.com)注册账号;同时可先在开发者平台入驻指引确认材料要求。注册邮箱/手机建议使用公司公共账号,避免离职交接问题。
-
认证「生活服务商家应用代开发」能力登录服务商平台 → 控制台 → 「第三方生活服务商家应用」页面 → 认证「生活服务商家应用代开发」能力。在「认证服务能力-基础信息」页签填基础信息 → 下一步 → 「认证服务能力-经营信息」页签填经营信息并上传应用工具介绍 → 提交审核。
-
等待能力认证审核(约 10 个工作日)平台审核反馈通过站内通知;建议提交后即通过平台右下角「开发者助手 → 生活服务问答」留言确认进度,必要时请对接 BD 协助加速。审核期间后端同步开始开发,不空等。
-
完成对公认证(审核通过后立即)在「认证服务能力-对公认证」页签选择任一方式:法定代表人/经营者支付宝人脸识别(实时完成,推荐)或 平台打款验证(0-2 小时,48 小时内输入打款金额,仅 2 次机会)。也可选银行账户实名 / 客户打款 / 申请授权验证。若人脸与打款均不便,预先安排好法人配合窗口。
-
签署合作协议并确认可创建应用对公认证完成后,控制台出现「创建三方应用」入口即代表入驻完成。验收标准:可在「第三方应用」区域点击创建第三方生活服务商家应用。
Chapter 06 · Phase 2
② 创建应用与申请解决方案
依赖 Phase 1 完成(对公认证通过);应用审核约 1 个工作日,解决方案约 3 个工作日
-
创建「第三方生活服务商家应用」控制台 → 「第三方应用」→ 「创建三方应用」→ 选择「第三方生活服务商家应用」 → 填写应用名称、上传应用图标,勾选《生活服务技术服务商合作协议》→ 提交。等待审核(约 1 个工作日)。
凭证说明:创建成功后 APPID = ClientKey,AppSecret = ClientSecret。AppSecret 由服务端保管,严禁下发到 APP 端或写入前端代码。 -
申请「到综行业解决方案」权限进入目标应用详情 → 左侧「解决方案」→ 找到「到综解决方案」(覆盖休闲娱乐、丽人、运动健身等,剑琅美业门店属此类)→ 点击「申请开通」,建议「按能力开通」,勾选本期需要的能力:门店映射及匹配、团购核销、团购对账;其余(三方码、预置码、会员接入等)暂不开通。等待审核(约 3 个工作日)。
-
验证接口凭据可用解决方案开通后,调用
POST https://open.douyin.com/oauth/client_token/(grant_type=client_credential)获取access_token。client_token 有效期约 2 小时,需缓存并按期刷新。所有接口请求头需携带access-token,POST 接口另需content-type: application/json,域名统一https://open.douyin.com,路径以/结尾。 -
内部验收后端凭据获取成功、能列出目标解决方案已开通能力;如调用报「无权限/未获得该能力」,通过「开发者助手-生活服务问答」或对接 BD 核查权限状态。
Chapter 07 · Phase 3
③ 试点门店授权与绑定
首批 3-5 家已就绪意向门店;先走抖音来客手动授权(零开发),同时预留 SaaS 内嵌授权 SDK 升级内容
试点门店接入材料模板(运营收集)
| 字段 | 用途 | 填写 |
|---|---|---|
| 门店名称 / 剑琅门店 ID | 内部映射 | ____ |
| 营业执照主体与经营者 | 平台资质核验 | ____ |
| 抖音来客账号(可操作人) | 发起授权绑定 | ____ |
| 抖音门店 ID(poi_id) | 核销归属门店 | ____ |
| 是否售卖次卡商品 | 决定次卡专项测试范围 | 是 / 否 |
| 联系人 / 联系方式 | 培训与答疑 | ____ |
授权方式一:抖音来客手动授权(首批推荐,零开发)
-
门店侧发起授权门店运营/店长登录抖音来客 PC 端 → 左侧「店铺管理」→ 「服务方应用授权」→ 「服务商代理」页签 → 点击「新增授权」→ 搜索选择「剑琅联盟」应用、选择授权行业(到综)与授权范围 → 提交。
-
服务商侧确认授权剑琅登录服务商平台控制台 → 进入目标生活服务商家应用 → 左侧「授权管理」→ 查询并确认该抖音来客商户的授权关系。确认后即可为门店调通接口。
-
门店信息绑定通过「门店映射及匹配」能力获取/核对门店 poi_id;在剑琅后台建立「抖音门店 → 剑琅门店」映射,配置该门店允许的核销范围与默认业绩归属员工规则。
授权方式二:SaaS 收银系统内嵌授权(后续版本升级)
官方推荐方案:商家在剑琅联盟系统内即可完成授权,无需登录抖音来客。到综解决方案支持此方式,接入「能力授权 & 门店绑定 SDK」即可。体验好但需要额外开发量,与赶排期相悖,故本期不开发,作为 M2 上线后体验升级项排入迭代。落地时:门店在剑琅后台一键发起授权 → 跳转完成抖音授权 → 自动回调绑定 → 剑琅免登录服务商平台操作。
Chapter 08 · Phase 4
④ 开发与联调(客户端扫码 + 后端接口)
客户端复用已有扫码组件实现手机摄像头识码(无 PC / 扫码枪);后端做语言无关的接口层实现;P0 主链路优先,P1 回调对账次之,与 RTB 批次错峰排人
开发交付项与依赖
| 模块 | 内容 | 顺序 | 复用/依赖 |
|---|---|---|---|
| 客户端核销扫码页(APP) | 手机摄像头识码入口(复用 APP 已有扫码组件)+ 手动输码兜底 + 补光/引导/识别反馈;识码文本交后端适配层解析,不在端上解析券信息 | P0 | 复用现有扫码组件 / 扫码页 |
| 统一核销服务 | 封装验券准备 / 验券 / 撤销 / 券状态 / 批量查询,屏蔽平台差异(后续接美团时复用同一抽象层) | P0 | 新增服务模块 |
| 抖音对接适配层 | client_token 获取与刷新、短链转长链、SPI 签名校验、错误码映射、重试机制 | P0 | 复用现有 HTTP 网关 |
| 自动开单联动 | 核销成功 → 生成开单记录 → 关联价目表 → 员工业绩归因(可配置自动/手动确认);顾客手机号登记/选择写入共享客户档案(R-20,为小程序预留契约) | P0 | 复用现有开单服务 |
| 信息同步回调 | 接收平台退款/状态通知,验签后本地冲销/状态更新(官方验收必接) | P1 | 新增回调端点 |
| 团购对账模块 | 平台账单文件/接口 ↔ 本地开单比对,差异标记与提醒(首批按日/周) | P1 | 复用报表能力 |
| 门店授权管理 | 授权关系、poi_id 映射、核销范围、授权到期提醒 | P1 | 新增管理页 |
| 次卡适配 | 次数字段处理、一次核销多份、按次撤销 | P2 | 依赖试点有无次卡 |
关键实现要点(开发必读)
-
抖音券码必须先「验券准备」再「验券」验券准备与验券调用需一一对应;验券成功后原二维码失效。二维码扫出的是短链(如
https://v.douyin.com/xxxx,长度不固定、不要截断),需先 GET 转发为长链再解析券信息。 -
纯手机端摄像头识码(无 PC / 扫码枪)店员用 APP 手机摄像头扫顾客手机屏幕上的抖音券二维码。复用 APP 已有扫码组件,端上只负责把二维码识别成短链文本并上送,不在端上解析券信息(短链转长链、券信息解析统一在后端适配层完成)。关注扫手机屏体验:补光开关(暗屏)、失败引导(调亮 / 避开反光 / 摘除手机膜)、识别成功震动 + 提示音反馈;逐张核销,扫一张即进验券流程,不引入连续扫码。需在试点前用真实手机屏幕验证识码成功率(亮度 / 贴膜 / 曲面屏场景)。
-
验券结果要区分「业务失败」与「技术异常」官方要求对 result 字段做业务匹配:result 非 0 是业务提示(如券已使用、金额不符),不是技术异常,需按业务提示处理并提示店员;技术异常(网络/5xx)走重试。
-
幂等设计验券接口用
verify_token做短时幂等;撤销核销支持按次幂等(cancel_token,有效期 1 小时)。核销前先查券状态做预校验,避免本地与平台状态不一致。 -
撤销核销有 1 小时限制平台仅允许核销后 1 小时内撤销。产品上建议店员确认核销做二次确认弹窗,减少误操作;超时撤销只能走人工/平台客服流程。
-
信息同步回调验签抖音调用剑琅服务端接口时请求头带
x-life-clientkey、x-life-sign;验签规则:以 client_secret 开头,URL 参数按 key 字典序 +http_body(POST)串联,sha256 后比对。http_body 用原始 []byte 参与签名,勿反序列化后重序列化(会导致字段顺序变化验签失败)。 -
次卡字段验券准备返回
time_card(总次数/已使用次数);一次核销多份在encrypted_codes中传多个相同加密码;撤销按次数传times_card_cancel_count。注意:分门店结算场景不要传按次撤销相关字段。 -
密钥与安全ClientSecret / 密钥存服务端(环境变量或密钥管理),接口统一 HTTPS;日志脱敏,不落明文券码全量信息。
联调与错峰安排(与 RTB 批次并行预案)
| 时段 | 抖音接入开发内容 | 与 RTB 冲突点 | 预案 |
|---|---|---|---|
| 第 1 周 | 架构与接口契约、client_token 自测、mock 封装 | RTB 开单测试收尾 | 后端轻量投入,不与 RTB 高峰重叠 |
| 第 2 周 | P0 主链路开发:客户端手机摄像头识码 / 扫码页(复用扫码组件、手动输码兜底)+ 后端验券/核销/撤销/状态 + 自动开单 | RTB 批次开发高峰(提成/薪资/员工管理集中开发) | 抖音侧重第 2 周前、后段集中投入,避开 RTB 高峰周中段;客户端扫码页与后端接口可并行开发、接口契约先行 |
| 第 3 周起 | 联调 + 回调/对账/次卡(P1/P2) | RTB 进入测试期、压力下降 | 逐步加人,若 RTB 测试挤压则回调/对账延后不阻塞主链路 |
Chapter 09 · Phase 5
⑤ 测试、验收与试点上线
先用测试账号/测试商品完成真链路联调,再灰度真实券
测试方案(二选一或并用)
| 方案 | 操作 | 适用 |
|---|---|---|
| 测试账号 | 按官方指引获取测试 token,在沙箱/测试账号下联调接口 | 开发联调期 |
| 测试商品 | 提前联系抖音 BD 开通「测试商品」功能(开白),创建商品时活动投放限制选择「测试渠道」并填写测试用户 UID;仅测试人员能购买。UID 获取:抖音 App → 我 → 右上角设置 → 底部连续点击 Version → 查看 UserId | 真链路 / 门店验收期 |
测试用例覆盖清单
| 场景 | 用例 |
|---|---|
| 摄像头识码(手机扫手机屏) | 顾客手机屏幕正常亮度可识别;反光 / 贴膜 / 过暗时引导文案与补光生效并可重扫;识码成功震动 + 提示音 |
| 识码失败兜底 | 多次识别失败 → 提示切换手动输码;相机权限被拒 / 无相机 → 明确提示并引导开启权限或转手动输码 |
| 正常核销 | 验券准备 → 验券 → 自动开单 → 业绩归因,金额/门店/券码正确 |
| 异常券 | 已核销 / 已退款 / 过期 / 金额不符券:result 非 0 的业务提示正确展示 |
| 撤销 | 1 小时内撤销成功、状态回退;超过 1 小时撤销报错提示 |
| 幂等与并发 | 同一券快速重复扫码、并发核销,只产生一条开单 |
| 网络异常 | 接口超时/抖动后重试成功;重试不重复核销 |
| 退款回调 | 平台侧退款 → 回调收到 → 本地自动冲销(信息同步接口) |
| 次卡(如有) | 多次卡一次核销多份、按次核销、按次撤销,剩余次数正确 |
| 跨门店 | 非本店 poi 核销被拒绝 / 权限控制生效 |
| 客户落库契约(小程序预留) | 登记 / 选择手机号后客户档案正确落库且可被小程序端查询契约命中(R-20 数据契约校验) |
平台验收与上线要求(官方必检项)
- result 业务匹配验券 result 非 0 必须有对应业务处理,不可当纯异常。
- 重试机制抖音侧接口失败需有重试,针对服务抖动一般重试即可解决。
- 预校验核销前预查券状态,避免双方订单状态不一致。
- 信息同步接口必接避免平台强制退款而剑琅无感知。
- 上线检查灰度 1 家试点真券 → 全链路核对(核销记录/开单/对账)→ 扩至 3-5 家 → 平台侧确认应用可用状态。灰度前须在试点门店用店员真实手机完成摄像头识码验证(覆盖不同手机品牌 / 贴膜 / 亮度场景,确认不依赖 PC / 扫码枪)。
Chapter 10 · Phase 6
⑥ 门店培训、运营支持与对账
随 M2 试点上线同步就绪
| 事项 | 操作说明 |
|---|---|
| 店员培训 | 远程为主:录屏视频 + 图文手册 + 线上培训会(每店 1 次约 20-30 分钟);覆盖「用 APP 手机摄像头扫顾客手机屏幕上的抖音券码(无需扫码枪 / PC)、扫码框对准与补光、识别失败的处理(调亮屏幕 / 避开反光 / 转手动输码)、验券弹窗、确认核销、撤销、异常提示怎么处理」。 |
| 客服 FAQ | 客服团队承接核销问题与授权咨询;FAQ 覆盖:券核销失败常见原因、摄像头识别不到券码的排查(亮度 / 贴膜 / 反光 → 补光与手动输码)、撤销时限、次卡如何核销、平台佣金答疑(明确佣金是抖音经营成本,非剑琅收取)。 |
| 对账节奏 | 上线首周按日对账,稳定后按周;核销记录、开单记录、退款冲销逐笔核对,差异自动标记运营跟进。 |
| 试点复盘 | 收集门店反馈(核销流畅度、摄像头识码成功率与重扫率、自动开单准确率、业绩归因是否符合预期);确认是否进入全量推广,评估 SaaS 内嵌授权 SDK 升级排期。 |
| 小程序承接(后续迭代) | 核销客流向剑琅美遇小程序转化的运营物料(核销引导话术、门店推广物料、领券活动配置)在小程序迭代启动时由小程序侧运营 / 产品同事输出;本期无需门店执行,仅沉淀「顾客手机号」这一关联位。 |
Chapter 11 · API Notes
抖音核销接口速查
到综解决方案 · 团购核销能力;完整字段以官方文档为准(链接见附录)
验券准备 GET https://open.douyin.com/goodlife/v1/fulfilment/certificate/prepare/
参数:encrypted_data / code(券信息)、poi_id、account_id、can_verify
返回:verify_token、加密券码 encrypted_codes、次卡 time_card(总次数/已用)
参数:encrypted_data / code(券信息)、poi_id、account_id、can_verify
返回:verify_token、加密券码 encrypted_codes、次卡 time_card(总次数/已用)
验券核销 POST https://open.douyin.com/goodlife/v1/fulfilment/certificate/verify/
参数:verify_token(幂等)、poi_id、encrypted_codes / codes(三选一)、account_id、order_id(三方码必需)
次卡:一次核销多份 = list 传多个相同 encrypted_code
参数:verify_token(幂等)、poi_id、encrypted_codes / codes(三选一)、account_id、order_id(三方码必需)
次卡:一次核销多份 = list 传多个相同 encrypted_code
撤销核销 POST https://open.douyin.com/goodlife/v1/fulfilment/certificate/cancel/
参数:verify_id(核销唯一标识)、certificate_id、times_card_cancel_count / cancel_token(次卡按次撤销)
限制:仅核销后 1 小时内可撤销;成功判定 biz_code=0 且 gateway_code=0
参数:verify_id(核销唯一标识)、certificate_id、times_card_cancel_count / cancel_token(次卡按次撤销)
限制:仅核销后 1 小时内可撤销;成功判定 biz_code=0 且 gateway_code=0
凭证 POST https://open.douyin.com/oauth/client_token/(grant_type=client_credential)
公共头:access-token(client_token 值,约 2 小时有效)、content-type: application/json
SPI 回调头:x-life-clientkey / x-life-sign(sha256 验签)
公共头:access-token(client_token 值,约 2 小时有效)、content-type: application/json
SPI 回调头:x-life-clientkey / x-life-sign(sha256 验签)
开发时以官方接口文档为准,接口路径一律 HTTPS 且以 / 结尾。更多接口(券状态查询、批量查询、门店映射及匹配、团购对账)见下方附录链接。
Chapter 12 · Risks
风险与应对
平台能力认证审核超预期(关键路径)
审核约 10 工作日且为串行前置。应对:第 1 周内即提交;开发者助手留言 + 联系 BD 加速;后端开发全程不等待平台,用 mock 契约先行;M1 平台环节允许顺延。
后端资源与 RTB 上线批次冲突
提成 / 薪资 / 员工管理与抖音接入共用开发资源,且 RTB 有独立的上线批次时间要求。应对:抖音接入开发按第 1 周与第 3 周起两段错峰投入;主链路优先、回调/对账/次卡可后置;周会对齐 RTB 测试期排人。
真券测试需平台开白「测试商品」
未开白前无法用测试商品。应对:尽早联系 BD(建议第 3 周前后完成);先用测试账号 token 联调,开白后再做真实门店券验收;若迟迟不开白,用试点门店小额真实商品谨慎灰度。
门店授权配合度与材料不齐
应对:试点门店已确认就绪,但需提前收集抖音来客账号与 poi_id;运营在 Phase 3 前下发材料清单并设截止时间,商务备好《门店授权与服务协议》。
撤销核销 1 小时限制导致客诉
应对:核销确认加二次确认;店员手册/FAQ 明示撤销时限;超时撤销走平台客服流程(话术在 FAQ 中备好)。
无 PC / 扫码枪,手机识码受屏幕与环境影响
门店不开扫码枪,核销完全依赖店员手机摄像头扫顾客手机屏,存在贴膜 / 反光 / 低亮度 / 曲面屏识别失败风险。应对:复用成熟扫码组件 + 补光开关 + 失败引导文案;手动输码兜底保业务闭环;试点前用店员真实手机覆盖多机型验证识别率;客服 FAQ 沉淀排查话术。
平台政策 / 计费规则变动
应对:费率与规则以平台当期公示为准(文档中金额均为公开参考);预留适配层隔离平台差异;关注开放平台公告与开发者助手通知。
小程序承接边界被误纳入本期(范围蔓延)
应对:小程序侧(剑琅美遇)已明确排入后续迭代、不占本期资源;本期仅在 B 端预留手机号落库契约(R-20)。会议口径写明「本期不开发小程序 UI / 功能」,防止与 B 端核销主链路抢排期。
顾客不配合留手机号 → 影响后续归并
应对:本期手机号登记为「引导补充」而非强校验,店员可在核销成功页轻量补充;小程序归并支持后续由顾客在 C 端授权补全,避免核销环节强制留资造成客诉。
Chapter 13 · References
官方文档附录
| 文档 | 说明 |
|---|---|
| 生活服务商家应用文档指引 | 抖音开放平台·生活服务接入总入口(会议后确认的官方指引) |
| 技术服务商接入指南 | 服务商入驻 → 创建应用 → 解决方案 → 门店授权 → 测试验收全流程 |
| 技术服务商入驻指南 | 注册 / 能力认证 / 应用创建 / 解决方案开通的细化操作 |
| 入驻开发者平台 | 主体认证、对公认证(五种方式)说明 |
| 团购核销能力介绍 | 能力清单、次卡适配、撤销时限 FAQ |
| 验券准备接口 | prepare 接口参数与在线调试 |
| 验券接口 | verify 接口参数(verify_token / poi_id / 次卡) |
| 撤销核销接口 | cancel 接口参数与 1 小时限制说明 |
| 微信小程序 · 手机号快速验证(后续迭代用) | 剑琅美遇授权登录归并(R-21)依赖的微信能力;本期不接入 |
说明:本清单为《美团 / 抖音团购核销接入方案》的服务商(抖音直连)路径落地细化,仅覆盖抖音直连;美团已确认经汇付天下 ISV 接入(戴凡推进),美团落地另行补充。文档中平台审核时效、费率与接口能力均整理自抖音开放平台官方公开文档,实际以平台当期公示、审核结果与商务确认的最终口径为准。落地过程中如与平台实际流程不符,以官方文档与开发者助手答复为准并及时修订本清单。