背景：由于疫情或政策原因，目前某预约 SaaS 平台商家反馈希望能够对用户进行身份识别，以便判断用户是否具备预约资格。

1. 需求分析

1.1 商家的声音(Voc)

1）商家 A 👉🏻 xxx 市只允许某某省（某某市除外）的用户进行预约。

2）商家 B 👉🏻 xxx 市本地市民凭 xxxx 身份证开头可购买预约特惠票。

3）商家 C 👉🏻 xxx 市疫情指挥部要求，具备 48 小时核酸记录才能进行预约。

4）商家 D 👉🏻 xxx 市提供的老人/小孩用户定向预约。

1.2 场景分类

经过信息收集整理，了解到目前商家提及的需求场景主要有以下 3 类：

1）商家仅提供本地化服务项目。

2）商家配合疫情防控弹性约束。

3）限定特定年龄段、性别等属性。

1.3 业务价值

1）降本增效 👉🏻 自动化便于商家高效管理预约订单，代替人工完成繁琐重复的工作，降低劳动成本，提升效率。

2）政策法规 👉🏻 自动化配置满足目前疫情大流行背景下，配合地方政府进行风控管理。

3）业务弹性 👉🏻 对于特定约束的服务项目，能够自由组合规则匹配符合的定向用户，自动过滤甄别。

4）可用程度 👉🏻 需求具备丰富预约业务可落地场景，自动化产品能力具备标准化特性，具备高度可复用特性。

5）技术成本 👉🏻 技术实现周期短，属于商家业务关键痛点，付费升级意愿高，已有 xx 家意向商家。

6）紧急程度 👉🏻 紧急重要程度高，目前已有 xx 家商家受到地方政府管控影响业务正常运营。

2. 产品规划

2.1 现有业务流

1）现有业务流程不具备用户身份识别能力，需要构建新的基础能力或在已有能力上改造已满足业务需求。

表单模块与「自动化」的理念高度吻合，而且表单在预约业务流程可以广泛适用于各行各业。

SaaS 平台在预约业务流程中，目前已初步具备预约资料表单功能，但在此之前仅用作信息收集用途。

2）目前平台预约资料表单提供的字段类型有“联系信息字段”和“通用字段”，总结已有字段可以划分为 4 种类型进行识别，分别是：字符串、数字、日期和多选项。

3）对于不同的字段类型，经过竞品分析调研，整理出以下常见的字段匹配规则。

以“字符串”类型的信息项为例说明：提供了“是”、“不是”、“包含”、“不包含”、“以...开始”、“以...结束”的规则选项。

对于“字符串”类型题目：你最喜欢的篮球明星是谁？

假设你设定规则为【是“科比”】，那么对于该题目来说，只有用户填写的内容完全匹配【科比】，才算匹配上规则。

如果你设置的是【包含“科比”】，那么用户填写的内容只要有【科比】，即匹配规则，如果不含则不匹配规则。

以此类推，理解其他字段和对应的规则。

2.2 迭代业务流

为了能从用户填写的预约资料进行身份识别，需要对于预约资料进行改造，在预约资料表单模块添加“自动化事件”。

大致流程是商家端需要先针对预约资料信息项设定好规则表达式，启动自动化事件。

当用户进行服务项目预约时，会进行 3 轮的检查。分别是“是否启用自动化事件” → “是否匹配规则” → “匹配规则是否可以预约”。

商家预设匹配规则「可以预约服务项目」的话，3 项检查都通过，用户即可进行服务项目预约。

2.3 逻辑规则表达式

1）在预约资料表单设定规则时，存在多项规则组合设定的情况，比如，只允许 A 省但不含 A1 市的市民可以预约特惠项目，用逻辑语言翻译就是：用户身份“是 A 省”且“不是 A1 市”。

2）面对这种情况需要使用到逻辑语言进行匹配规则串联，逻辑语言会有：“且(&)、“或(|)”、“非(!)”3 种常见的类型。

目前在产品的现有字段中，只需要用到“且(&)”和“或(|)”2 种就能满足需求，未来根据新增字段类型，再决定增加“非(!)”条件。

3）“且”、“或”用法示例：

A 且 B = A&B = 同时满足 A 和 B 规则，即为匹配。

A 或 B = A|B = 只要满足 A 或 B 其中一项规则，即为匹配。

另外，在设计过程中，逻辑语言存在一定使用门槛，需要尽可能降低商家在设定时的难度。

3. 方案设计

3.1 自动化事件

经过讨论，决定基于原有预约资料表单业务增加「自动化事件」。预约资料表单已被大量商家投入业务运营，对于不需管控的商家，默认设定为“不限制”。

商家可以依据运营需要，自行设定自动化事件规则表达式并启用。

3.2 复合规则表达式

1）单项规则

单项规则时，比如限制身份证是“440300”开始的规则，可以这样表达：({身份证}[以...开始]{440300})。

2）“且”组合规则

多项“且”规则时，比如限制身份证是“440300”开始，并且不含“440399

”的规则。可以这样表达：({身份证}[以...开始]{440300})且({身份证}[不含]{440399})...。

3）“或”组合规则

多项“或”规则时，比如限制身份证以“440300”开始，或者以“440399”开始的规则。可以这样表达：({身份证}[以...开始]{440300})或({身份证}[以...开始]{440399})...。

4）混合组合规则

多项“且”和“或”规则时，比如限制身份证是“440300”开始，并且不含“440399”。或者身份证是“440100”开始，并且不含“440199”的规则。可以这样表达：({身份证}[以...开始]{440300})且({身份证}[不含]{440399})或({身份证}[以...开始]{440100})且({身份证}[不含]{440199})。

从上面的讲解可以看出，随着组合规则的增加，设定和阅读规则变成一件极具难度的事情，对于使用者来说，有很高的学习成本。

经过使用者测试发现，基本超过 3 项后都在“或”组合规则的时候，会对规则阅读和理解产生障碍，接下来问题就是考验实际 UI 界面展示的时候如何进行交互表达。

3.3 规则表达式方案

在经过市面上 5 款类似产品设计后，提出了 A/B/C 3 种设计方案。通过给定设定任务和阅读任务，对 3 位使用者进行易用性测试，大致的结论如下。

方案 A：直接条列式设定规则，对于不同的规则可以根据需要选择“且”和“或”组合方式。方案虽然满足可用性，但是并没有解决使用者在使用上设定和阅读的障碍。

方案 B：在方案 A 的基础上，拆分为规则组，把规则拆分成更小的单元来看待。规则组很好解决了设定的问题，但是对于阅读来说，还是存在不小的问题。比如，在第一个规则组后再使用“且”进行组合，那就变成两个组其实是一个组，在阅读上并不直观。

方案 C：在前面总结的问题，最后决定采用规则组内只可使用“且”，规则组间只可使用“或”组合。对于专业人士来说，设置复杂的规则表达式会变得重复。但是对于普通人来说，却是更加直观和直觉。

所以，在规则表达式设定上，采用“方案 C”。

3.4 规则表达式更新机制

预约资料表单在实际使用过程中，会面对业务需要进行表单内容的调整。由于自动化事件是关联在表单之上，会受到表单内容的约束。

当修改预约资料表单的字段影响自动化设定规则时，系统需要进行检查并引导使用者进行操作。针对表单修改影响规则，可以在“?”预览，并可以快速一键排除。如果不确定，可以暂不处理。

又或者点击“马上更新”进入自动化设置页进行调整，对于影响的规则进行突出显示，原则上还是希望能最大程度简化使用者的操作难度，提高操作效率。

4. 总结

对于 B 端产品，特别是对于 SaaS 产品来说，接收到客户的需求，通常信息是比较片面的。客户只会告诉你需要什么，设计产品的能力不能只站在单个需求上来考虑问题，需要抽离出来看“某一类能力”或“某些业务场景”，结合业务价值一起进行判断。

对于“自动化事件”的能力设计，可以应用的场景非常多。比如，数据变更、顾客下单、取消业务、定时任务等等，只要涉及一个标准的条件(触发项)，都可以通过逻辑表达式进行判别。

而后续的行动，当然也不止本文提及的限制顾客进行下单预约。还可以根据实际业务提供行动，比如，发送短信、赠送优惠券、自动打标签等等。

这是一个 SaaS 产品能力原子化之后的结果，作为 SaaS 产品经理不只是要增加产品能力，拓展产品解决问题的深度。能力不是越多越好，是有限的能力可以产生更多元的业务组合，这需要思考怎么把产品能力可以抽象成更为基础的能力单元，便于组合能力单元不断发展，深化。

希望对你有所帮助。

公众号：龙国富，人因工程硕士。致力于终身学习和自我提升，分享用户研究、客户体验、服务科学等领域资讯，观点和个人见解。