在零售与 SaaS 产品的设计中，命名不仅是标签，更是认知与体验的入口。本文从“门店”这一基础概念出发，探讨产品设计中如何避免过度个性化需求，回归清晰、统一的表达逻辑。

在很多的书籍或者方法论中，认为SaaS产品应该实现标准的需求，当遇到个性化需求的时候，要把它抽象化，抽象成很多企业可以共用的样子。

开始的时候我信了，数十次碰壁之后我发现，这可能也是中国没有一个可以走向世界的SaaS产品的原因原因之一。

01

我们做To B的SaaS服务，有一天，一个客户跟我说，我要看我们公司不同门店的数据，你帮我处理下吧。

那时候使用系统的基本都是餐饮类企业，调研了多家企业又分析了竞品，发现这是个标准需求呀，我们挺高兴，在系统里增加了一个“门店”的标签。

好多用户反馈，你们这个功能好呀，我都能按门店查询啦，再也不用导出来一点点对账啦……

02

随着业务发展，慢慢接入了好多房地产行业的用户，客户说，我得按小区统计数据，你们支持吗？

我们一看，这跟门店不是一个意思嘛，问人家门店行不行，客户说：我是小区，不是门店。

我们想，书上说了，要抽象，专门开了10次会议讨论，终于确定了一个词“业务类型”。

那时候觉得自己特牛，终于可以支持多个行业场景啦。什么餐饮门店、物业小区、建筑项目、不同业务线，都往上靠吧！

然后，业务又发展了，有了更多的合作伙伴，更多的行业使用这个产品。

于是，每天每天，电话、微信群、面对面会议，总有人问“业务类型”是什么呀？怎么用呀？

在同一个人第80次问我的时候，我哭了。边挠桌子边问：“姐，我如果让它叫门店你能理解吗？”

东北小姐姐扯着嗓门说：“那有啥不理解的呀，你早这么叫我都不问你。”

除了跪下，我还能怎么办……

03

这时候我不得不想，抽象，是不是错了。

如果同一个概念，门店就叫门店，小区就叫小区。

在客户使用系统前，选择下行业，系统根据行业区分后显示对应名词，是不是这个沟通和学习成本就没这么高了？

或者，还有哪些更好的方式，能既使用客户常用的名词，系统又能兼顾不同情况呢？

SaaS化，到底是把客户的需求抽象后实现，还是直接实现客户的需求，系统通过灵活的配置兼容多场景，低学习成本推广呢？

我倾向于后者。

04

这篇文章从写完到发布，经历了大约一个月左右的时间。

我在网络言论方面，是个胆子有点小的人，对于这种理论与实践冲突比较大的情况，总想多方位的求证，在不同的场景和行业里得到证实之后，才敢胡说八道。

在求证过程中，我发现有太多太多名词无法理解，因为用词不一致导致大量无效沟通甚至产品推进难度大的情况。

究其原因，是大家在常识方面不一致。

不同地区、行业、职业、教育背景、原生家庭甚至不同性别的人，都各自有自己的常识。这些在C端产品中备受重视的客户细分，到了B端，因为业务的复杂性，有时候会被无意识的忽略。

尊重对方的习惯的时候，同样获得尊重。不论是人还是产品。

而抽象，属于一种融合，是进行了深入理解甚至逻辑处理后的结果。首先挑战人的习惯，其次挑战人的惰性，再次考验人的记忆力和理解力。

遇到类似问题时，多想几套方案，不局限于抽象，不拘泥于常识，也许会遇见更多的惊喜。