Membership refactor

概览

CRM 的核心是acquisition 与retention。Membership 是retention 里最终要的功能，但也是一直以来最薄弱的，很多商家实际运营membership 时的use case 都无法做到job to be done，使用率也非常低，几乎没有商家使用。

而2025 年 7 月时，我们正在争取的 T1 大客户 Central Bark，恰恰是一家非常重视会员运营的的连锁品牌，也有丰富的use case，可以说是membership 使用的标杆用户。因此我们把membership 推翻重做，让central bark 可以顺利的使用membership，进而促成了与moego 的合作。

一个大客户的合作意向，让我们重新审视我们的membership功能

契机

事情的开始，是销售侧传来的一个消息：我们一直在争取的 T1 连锁客户 Central Bark 被说动了，愿意给 MoeGo 一个机会——前提是，Membership 能做好。

Central Bark 的商业模式几乎完全建立在会员制之上，他们的顾客基本上都是 member。对他们来说，Membership 不是锦上添花的附加功能，而是每天高频运转的经营核心。因此我们需要能够覆盖他们的use case，保证使用我们的membership 是流畅的，不会造成资损的。

如何才能做好membership？还原真实的会员运营场景

挖掘用户最真实的会员运营场景

在我接手 CRM 之前，团队已经做过一版 Membership，但问题很多，处于"不太可用"的状态。所以我做的第一件事，是自己在线上把全流程走查了一遍。第一遍走下来，我发现真正的问题是：旧系统缺的不是顺手的界面，而是对整个会员运营场景的理解缺失。

而团队里之前并没有沉淀会员运营场景的use case，而centrial bark 只会在我们有updates 时才愿意和我们沟通的客户，需要看到方案以后，才能有一个锚点来引导他们说出他们的使用场景。

所以我把场景验证的过程变成一个，我尝试画出demo和用户直接验证的循环：带着 wireframe 和结构化的选项去做 demo，再把反馈带回来迭代。除了标杆客户 Central Bark，我还找了另一家大客户 Red Dog 交叉验证，确认这些诉求不是单一客户的特例。最终确认了如下场景：

场景一：Setup

创建一个 membership plan，商家需要按自己的经营方式配置规则。除了常规的membership 名称，包含的权益，还有两处灵活度是刚需：

• 扣款日：每家商家的财务进账节奏不同——有的固定每月 1 号，有的每周一——顾客被扣款、商家才进账，所以扣款日必须能设。
• perks 有效期与计费周期解绑：weekly membership 的权益，不一定非得一周内用完；商家可能希望"这周买的 perks，一个月内用完都行"。有效期应该独立配置，而不是硬跟着 billing 周期走。

而旧方案里，扣款日无法设置，perks 有效期也被自动绑死在 plan 的周期长度上。

场景二 ：Ops

日常经营中，pet parent 会因为各种原因需要变更会籍，可能只是想暂停会籍，然后再继续。但我们目前只能立刻取消，非常不利于商家维护长期老客户。

除此以外，会员制生意靠长期关系维系，商家和顾客之间有很强的线下 bonding，例外处理是常事：

• 延长 perks 有效期：顾客家里有急事、没来得及用，商家愿意通融给个宽限。
• transfer to store credit：把没用完的 perks 直接兑现成店内余额去消费。

而我们的系统里，这类灵活处理系统层面完全缺失，商家只能在系统外私下记账。

场景三 ：Inquiry

"If someone calls me and asks how many credits I have, how would I answer that?"

"How do I know when a perk I purchased was redeemed, and what services/invoice they were redeemed on?"

前台每天最高频的工作场景就是处理来自顾客的问询：

• 查余额：顾客打电话问"我还剩多少次？"，前台需要在电话不挂断的几秒内答出 remaining perks，最好能一次看到跨周期（cross multiple time periods）的情况。
• 对核销：如果两边结论对不上——顾客说还有、系统说没有——就得追溯"这些 perks 到底核销在了哪笔订单上"，拿记录说话。
• 对操作：如果争议升级到"上次是 XX 员工给我操作的"，还得能追溯到历史上是哪位 staff、什么时候做了什么操作。
  而旧方案里，会员信息藏在独立页面，要进详情、再在下拉框里逐周期点开——一通电话根本走不完；每个周期只有一个孤零零的 remaining 数字，核销去向查不到；员工操作更是没有任何 log。所以客户的原话是：

但我们系统里这些都看不到，导致用户在接受问询时，无言以对。

我们的问题到底是什么？哪里做的不好？

• Lack of Visibility：Inquiry 里查不到余额、看不了跨周期。

• Lack of Traceability：Inquiry 里追不到核销去向、查不到员工操作。

• Lack of Flexibility：Setup 的扣款日与有效期、Ops 操作的灵活度太低

Solution 就是逐一优化 Visibility, Flexibility, Tranceability

Visibility

会员信息直接整合进 client 档案：卡片式平铺展示每个 membership 及其状态（98% 的客户只有 1-2 个 subscription，不需要做成列表）；每个购买周期都有独立的 Benefits overview，逐项展示数量、剩余、有效期和权益状态，并支持 All history / Remaining perks 的快速筛选——前台接起电话，当页就能回答"还剩多少"。

不仅可以看到每个周期内的剩余量，还可以看整个plan的剩余总量（之前周期会有没来得及用的权益，只要没用过，都包含在内）

Flexibility

Setup 支持自定义扣款日、并让权益有效期与计费周期解绑独立配置.

Ops 场景支持灵活切换会员会籍，可以Pause / Restart / Cancel。Restart 支持按日期自动恢复或手动恢复，cancel 区分 end of period / 未来第 N 期 / 立即取消，立即取消时支持 manager 手动输入协商后的退款金额；

Ops 场景支持权益的手动延期与 transfer to store credit，让顾客与商家的协商都有操作空间。

Traceability

Activities log把暂停、恢复、取消、续费、延期等所有操作连同操作人和时间记录下来。

最终，客户亮起绿灯

方案的方向得意验证，于是逐步落地

以上方案也是与客户来回沟通后，终于让客户满意的方案。这个验证的过程里，不仅是界面的设计方案，包括功能设计（比如membership 应该有几种操作和状态，每个状态下权益能否使用，能否延期或transfer等等）都通过设计来推动验证。这个过程有多次的会议，多次的邮件往来，一一记录了这个有意义的过程。

这些验证之所以重要，是因为与客户的利益息息相关，稍有不当就容易让商家被薅羊毛（比如pause后membership的renewal date会无限延长，如果还能继续使用权益，那么就相当于是无限期的使用权益，永不过期）。但当每个细节都考虑到后，作为设计师的价值感也油然而生。

Impact

重构后的 Membership最终对合作亮起了绿灯。Membership 从大客户谈判桌上的短板，变成了可以拿出来讲的能力。

目前我们也开白了将近 600 个商家，已经在逐步稳定的面向全部用户开放使用。

思考

回头看，这个项目最大的收获在于：设计师如何把需求挖出来？我最初以为面对的是一个 usability 问题，但其实面对的是还原日常运营里最真实的操作场景和商家的心思 - 系统不是所有事都要死板的按规定走，我们的系统设计给真实的人，我们的用户也面对真实的人，这个系统要在规矩之外，满足人与人在线下的strong bonding下的通融。

它还让我对"灵活性"有了更具体的理解：Flexibility 不是把所有东西都做成可配置项，而是先弄清楚线下真实发生了哪些"例外"，再决定系统要为哪些例外留出操作空间。

同时，Central Bark作为会员运营的标杆用户，他的case可以cover基本所有商家的运营场景。这也让我学会了，如果要做好一个功能，就去找到使用这个功能的标杆，把标杆研究透，这个功能也就做透了。