新会员系统 PRD

一、项目背景

1.1 现状

• 现有服务号"是她"，已在客总管（武汉力格软件）上运行会员体系
• 客总管年费约 3000 元/年
• 客总管与欧普 ERP 之间的会员基础信息（姓名/手机/生日）已同步
• 不同步的部分：各类优惠券数据全在客总管，且导出困难

1.2 痛点

1. 优惠券数据被锁在客总管，无法导出（券模板 + 已发放未使用券实例）
2. 客总管券系统本身也不好用
3. 不想再用 SaaS（有赞/微盟/银豹一概不考虑），要省钱 + 数据自主
4. 团队已有开发能力（forge profile）

1.3 决策边界

• 不做储值（砍掉最大合规/资金风险）
• 不做商城（不开线上店）
• 只做：积分兑换优惠券 + 节假日批量发券 + 门店核销
• 同步：欧普消费 → 新系统自动积分（同步方案大头哥自己想办法）

二、方案调研结论

2.1 市面开源方案对比

2.2 核心结论

三、系统架构

四、关键设计决策

4.1 券不进微信卡包，走自己的 H5 页面

• 微信卡包接口（card_id/code/api_ticket）审核严、限制多、需卡券权限
• 用自己的 H5 页面：顾客打开"我的券"→ 每张券一个二维码 → 店员扫
• 简单、可控、零审核

4.2 积分规则在欧普销售同步时自动算

• 每晚 CEW 跑完后触发钩子：当天新增销售单 → 按规则（如 1 元 = 1 分）给会员加分
• 规则配置在系统后台，可随时改
• 积分主数据以新系统为准，欧普只是销售来源

4.3 积分兑换是核心场景

• 顾客在服务号"积分商城"→ 选一张券（如 500 分换 50 元无门槛券）→ 点兑换 → 扣积分、券到手
• 后台防刷：同一会员每日兑换上限、同一券每人每月限兑张数
• 兑换记录可追溯（何时换、何时用、用于哪笔单）

4.4 节日券批量发放

• 后台运营：选模板（春节满500减100）→ 选人群（全部会员 / 按标签 / 按消费层级）→ 一键发
• 发完自动推模板消息："您收到一张春节专属券，点击查收"
• 自主可控、随时发、不限量

4.5 门店核销做到最简单

• 店员手机打开核销页 → 扫顾客券码 → 显示"张三 满200减50券 8月31日到期"→ 点"使用"
• 系统记录核销 + 生成核销码
• 店员在欧普开单时商品改折后价，备注填核销码
• 月底对账：新系统核销记录 vs 欧普销售单备注

五、技术栈

六、数据 Schema（草案）

6.1 核心表（6 张）

-- 会员表
members (
  id, phone UNIQUE, name, birthday,
  openid, unionid,
  created_at, updated_at
)

-- 积分账户
point_accounts (
  member_id PK, balance, total_earned, total_spent,
  updated_at
)

-- 积分流水
point_transactions (
  id, member_id, change_amount, balance_after,
  source_type,  -- 'erp_sale' / 'redeem' / 'manual' / 'expire'
  source_id,    -- 欧普销售单号 / 兑换记录ID
  remark, created_at
)

-- 券模板
coupon_templates (
  id, name, type,  -- 'cash' / 'discount' / 'gift'
  discount_value,  -- 优惠金额或折扣
  min_purchase,    -- 满减门槛
  valid_days,      -- 发放后有效天数
  point_cost,      -- 积分兑换所需分数（0=不可兑换，仅节日发）
  per_member_limit, total_limit,
  created_at
)

-- 券实例
coupons (
  id, template_id, member_id, code UNIQUE,
  status,  -- 'unused' / 'used' / 'expired' / 'cancelled'
  issued_at, valid_from, valid_to,
  used_at, used_store, used_order_no,
  issue_channel  -- 'redeem' / 'campaign' / 'manual'
)

-- 核销记录
redemptions (
  id, coupon_id, member_id, store_code,
  operator,  -- 店员
  discount_amount, order_no,
  created_at
)

七、与欧普 ERP 的对接

7.1 数据流向

7.2 关键约束

• 销售单必须能拿到 会员手机号 + 消费金额 + 门店编码 + 销售时间 四个字段
• 会员主数据以欧普为准，新系统只做 phone ↔ openid 映射
• 新会员在欧普开卡后，T+1 自动出现在新系统

八、服务号配合方案

8.1 菜单结构

是她服务号
├── 我的会员
│   ├── 我的积分（H5 页）
│   ├── 我的券（H5 页）
│   └── 积分商城（H5 页）
├── 门店活动
│   └── 当期优惠券（H5 页）
└── 关于我们
    └── 门店地址/客服

8.2 网页授权

• snsapi_base 静默授权（不弹窗）→ 拿 openid → 查库返回会员数据
• 新会员首次打开 → 提示绑定手机号（输入手机号 + 欧普验证）→ 完成 openid 绑定

8.3 模板消息（需服务号已认证）

• 积分到账通知
• 兑换成功通知
• 券到期前 3 天提醒
• 节日发券到账通知

九、实施排期

总计 4-6 周

十、成本估算

十一、待大头哥确认的问题

• 积分规则：现在客总管怎么算？1 元 = 1 分？按商品类别区分？换券比例多少？
• 节日券量级：一年发几次？每次发多少张？（决定批量发券性能设计）
• 会员分层：有没有 VIP/普通/沉睡？分层规则在哪维护？
• CEW 字段：现有管道能否拿到"会员手机号 + 消费金额 + 门店 + 时间"四个字段？
• 服务号权限：是否已微信认证 + 模板消息权限？
• 客总管数据：券模板和已发放未使用券实例能否导出 Excel？（决定切换策略）

十二、切换风险与对策

十三、不做什么（避免范围蔓延）

• 储值/预付卡（合规风险大）
• 线上商城（不走 CRMEB 那条路）
• 导购业绩归属（保留现有欧普做法）
• 沉睡客自动回访（保留现有飞书机器人）
• 小程序（H5 已够用）
• 微信卡包对接（不必要复杂化）