编辑导语：随着 B 端行业的热度不断上升，相关讨论度也在不断上升，一些产品经理想进入 B 端行业，但是了解甚少。在 B 端 SaaS 产品中，我们经常会遇到一些自动化事件设计模块。本文就 B 端 SaaS 产品自动化事件设计进行了分析讲解。推荐对 B 端 SaaS 产品自动化感兴趣的用户阅读。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　在上半年的时间里，车市虽然依旧深陷疫情和芯片危机的影响，但在国内行之有效的应对之下，中国车市的恢复也是肉眼可见；因此，今天我们就来一起盘点一下，那些在今年上半年上市的重磅新车们。

上一篇：为什么叫它伺服液压机？ 下一篇：合纵科技：公司主业为电力设备制造和锂电材料生产其中电力板块的自动化事业部的产品涉