换主体之后，会员权益的账由谁认

换主体、换服务商时，技术团队最常被问的是“数据能迁吗”。但会员真正关心的是另一句话：“我原来的积分、余额和等级还算数吗？”前一个是导入问题，后一个是责任问题。数据可以跟着 CSV 过去，责任不会。

所以在讨论字段和接口之前，先把三件事写下来：旧账谁认、新账谁接、差额谁补。

一、三张表，先把责任划清

第一张表列旧主体已经承诺、但还没兑付的权益：积分、储值、优惠券，以及等级带来的折扣和服务。第二张表列新主体愿意承接的部分和承接条件。第三张表列不承接的部分怎么处理：退款、补偿、限期使用，还是明确失效。

三张表的金额要能对上。对不上，就是缺口；缺口不会因为“上线后再说”而消失。把缺口写在纸上，比埋在导入脚本里安全。

二、积分：营销工具，也是待兑付的承诺

积分通常不是法定货币，但对会员来说，它是已经获得的利益。迁移时可以等值迁移、按比例折算、限期兑换，或者清零并给出补偿。四种都可以讨论，唯独不能不告知。

还要区分积分类型：促销赠送和消费获得是否同权，过期规则是否延续，退款产生的负积分怎么处理。如果旧系统只有总额，就把“无法区分类型”写进已知限制，并准备人工处理争议。

把积分悄悄清零，是最容易引发集中投诉的做法；折算比例不透明，效果也差不多。

三、储值：预收款，先过财务和法务

储值余额是客户已经付过的钱。在很多司法辖区，它被视为预收款或预付负债，涉及退款、发票、税务和资金归属。谁承接、怎么开票、能不能退款，这些不是技术团队能单独决定的事。

如果新主体不承接，旧主体仍然要负责退款或继续履约。发一纸迁移公告，并不能把责任转走。赠送金额、折扣充值、过期条款都会影响实际负债，核算时不能只看账户余额。

“技术上能导入”不等于“法律上能承接”。储值方案应该先有财务和法务的书面意见，再有接口设计。

四、等级和优惠券：承诺型权益，按条件处理

等级对应的是折扣、服务或优先权，是一种持续承诺。迁移时要么承认历史消费并重新计算，要么设一个过渡期，让老会员按原等级使用一段时间。两种做法都要写清周期、门槛和截止日期。

优惠券通常有有效期、适用范围和叠加规则，跨系统往往无法原样迁移，只能在新系统重发等价券。哪些重发、哪些到期不补、哪些改成其他补偿，要提前定好并对外说明。

五、告知和申诉，是方案的一部分

会员需要在什么时候、通过什么渠道、知道哪些变化？哪些权益保留，哪些折算，哪些到期？如果不同意，去哪里申诉，多久有回复？

这些问题不解决，客服会在上线当天替整个项目解释。提前准备告知文案、常见问题、申诉入口和处理时限，比事后道歉便宜得多。具体的告知义务以适用法律和法务意见为准。

六、对账和兜底：把差额留在纸面上

迁移前统计各资产总额，并按状态拆分；迁移后再算一遍，记录差额、原因和处理人。差额可以存在，但必须被解释。

设一个观察期，比如三十天或六十天，约定这段时间内的争议处理时限和责任人。旧系统在观察期内保持只读，保留回滚或补偿的可能。超过观察期的差额怎么处理，也要提前写下来。

七、协议里建议写清的几件事

1. 承接范围：哪些资产、从哪个时间点、附带什么条件。
2. 数据责任：准确性、保留期限、删除方式、访问权限。
3. 对外告知与申诉：由谁告知、由谁接待、多久响应。
4. 差额处理：谁核对、谁签字、缺口由谁承担。
5. 退出安排：观察期、回滚窗口和旧系统停用时间。

具体条款以法务意见为准。技术方案的价值，是在责任清楚之后，把承诺准确地实现出来。

会员不会读迁移方案，他们只会打开自己的账户，看积分、余额和等级还在不在。先把数据交接和身份匹配做好，再谈责任落地，顺序就不会乱。