B 端 SaaS 产品自动化事件设计 – 规则表达式
温馨提示:这篇文章已超过1014天没有更新,请注意相关的内容是否还可用!
编辑导语:随着B端行业的热度不断上升,相关讨论度也在不断上升,一些产品经理想进入B端行业,但是了解甚少。在B端SaaS产品中,我们经常会遇到一些自动化事件设计模块。本文就B端SaaS产品自动化事件设计进行了分析讲解。推荐对B端SaaS产品自动化感兴趣的用户阅读。
背景:由于疫情或政策原因,目前某预约SaaS平台商家反馈希望能够对用户进行身份识别,以便判断用户是否具备预约资格。
一、需求分析 1. 商家的声音(Voc)
- 商家A :xxx市只允许某某省(某某市除外)的用户进行预约。
- 商家B:xxx市本地市民凭xxxx身份证开头可购买预约特惠票。
- 商家C: xxx市疫情指挥部要求,具备48小时核酸记录才能进行预约。
- 商家D: xxx市提供的老人/小孩用户定向预约。
经过信息收集整理,了解到目前商家提及的需求场景主要有以下3类:
- 商家仅提供本地化服务项目。
- 商家配合疫情防控弹性约束。
- 限定特定年龄段、性别等属性。
- 降本增效:自动化便于商家高效管理预约订单,代替人工完成繁琐重复的工作,降低劳动成本,提升效率。
- 政策法规:自动化配置满足目前疫情大流行背景下,配合地方政府进行风控管理。
- 业务弹性:对于特定约束的服务项目,能够自由组合规则匹配符合的定向用户,自动过滤甄别。
- 可用程度:需求具备丰富预约业务可落地场景,自动化产品能力具备标准化特性,具备高度可复用特性。
- 技术成本:技术实现周期短,属于商家业务关键痛点,付费升级意愿高,已有xx家意向商家。
- 紧急程度:紧急重要程度高,目前已有xx家商家受到地方政府管控影响业务正常运营。
(1)现有业务流程不具备用户身份识别能力,需要构建新的基础能力或在已有能力上改造已满足业务需求。
表单模块与「自动化」的理念高度吻合,而且表单在预约业务流程可以广泛适用于各行各业。
SaaS平台在预约业务流程中,目前已初步具备预约资料表单功能,但在此之前仅用作信息收集用途。
(2)目前平台预约资料表单提供的字段类型有“联系信息字段”和“通用字段”,总结已有字段可以划分为4种类型进行识别,分别是:字符串、数字、日期和多选项。
(3)对于不同的字段类型,经过竞品分析调研,整理出以下常见的字段匹配规则。
以“字符串”类型的信息项为例说明:提供了“是”、“不是”、“包含”、“不包含”、“以…开始”、“以…结束”的规则选项。
对于“字符串”类型题目:你最喜欢的篮球明星是谁?
假设你设定规则为【是“科比”】,那么对于该题目来说,只有用户填写的内容完全匹配【科比】,才算匹配上规则。
如果你设置的是【包含“科比”】,那么用户填写的内容只要有【科比】,即匹配规则,如果不含则不匹配规则。
以此类推,理解其他字段和对应的规则。
2. 迭代业务流
为了能从用户填写的预约资料进行身份识别,需要对于预约资料进行改造,在预约资料表单模块添加“自动化事件”。
大致流程是商家端需要先针对预约资料信息项设定好规则表达式,启动自动化事件。
当用户进行服务项目预约时,会进行3轮的检查。分别是“是否启用自动化事件” → “是否匹配规则”→ “匹配规则是否可以预约”。
商家预设匹配规则「可以预约服务项目」的话,3项检查都通过,用户即可进行服务项目预约。
3. 逻辑规则表达式
(1)在预约资料表单设定规则时,存在多项规则组合设定的情况,比如,只允许A省但不含A1市的市民可以预约特惠项目,用逻辑语言翻译就是:用户身份“是A省”且“不是A1市”。
(2)面对这种情况需要使用到逻辑语言进行匹配规则串联,逻辑语言会有:“且(&)、“或(|)”、“非(!)”3种常见的类型。
目前在产品的现有字段中,只需要用到“且(&)”和“或(|)”2种就能满足需求,未来根据新增字段类型,再决定增加“非(!)”条件。
(3)“且”、“或”用法示例:
A且B =A&B =同时满足A和B规则,即为匹配。
A或B =A|B=只要满足A或B其中一项规则,即为匹配。
另外,在设计过程中,逻辑语言存在一定使用门槛,需要尽可能降低商家在设定时的难度。
三、方案设计 1. 自动化事件
经过讨论,决定基于原有预约资料表单业务增加「自动化事件」。预约资料表单已被大量商家投入业务运营,对于不需管控的商家,默认设定为“不限制”。
商家可以依据运营需要,自行设定自动化事件规则表达式并启用。
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. 规则表达式方案
在经过市面上5款类似产品设计后,提出了 A/B/C 3种设计方案。通过给定设定任务和阅读任务,对 3 位使用者进行易用性测试,大致的结论如下。
方案A:直接条列式设定规则,对于不同的规则可以根据需要选择“且”和“或”组合方式。方案虽然满足可用性,但是并没有解决使用者在使用上设定和阅读的障碍。
方案B:在方案A的基础上,拆分为规则组,把规则拆分成更小的单元来看待。规则组很好解决了设定的问题,但是对于阅读来说,还是存在不小的问题。比如,在第一个规则组后再使用“且”进行组合,那就变成两个组其实是一个组,在阅读上并不直观。
方案C:在前面总结的问题,最后决定采用规则组内只可使用“且”,规则组间只可使用“或”组合。对于专业人士来说,设置复杂的规则表达式会变得重复。但是对于普通人来说,却是更加直观和直觉。
所以,在规则表达式设定上,采用“方案C”。
4. 规则表达式更新机制
预约资料表单在实际使用过程中,会面对业务需要进行表单内容的调整。由于自动化事件是关联在表单之上,会受到表单内容的约束。
当修改预约资料表单的字段影响自动化设定规则时,系统需要进行检查并引导使用者进行操作。针对表单修改影响规则,可以在“?”预览,并可以快速一键排除。如果不确定,可以暂不处理。
又或者点击“马上更新”进入自动化设置页进行调整,对于影响的规则进行突出显示,原则上还是希望能最大程度简化使用者的操作难度,提高操作效率。
四、总结
对于B端产品,特别是对于SaaS产品来说,接收到客户的需求,通常信息是比较片面的。客户只会告诉你需要什么,设计产品的能力不能只站在单个需求上来考虑问题,需要抽离出来看“某一类能力”或“某些业务场景”,结合业务价值一起进行判断。
对于“自动化事件”的能力设计,可以应用的场景非常多。比如,数据变更、顾客下单、取消业务、定时任务等等,只要涉及一个标准的条件(触发项),都可以通过逻辑表达式进行判别。
而后续的行动,当然也不止本文提及的限制顾客进行下单预约。还可以根据实际业务提供行动,比如,发送短信、赠送优惠券、自动打标签等等。
这是一个SaaS产品能力原子化之后的结果,作为SaaS产品经理不只是要增加产品能力,拓展产品解决问题的深度。能力不是越多越好,是有限的能力可以产生更多元的业务组合,这需要思考怎么把产品能力可以抽象成更为基础的能力单元,便于组合能力单元不断发展,深化。
希望对你有所帮助。
作者:龙国富,公众号:龙国富,分享用户研究、客户体验、服务科学等领域资讯,观点和个人见解。
本文由@龙国富 原创发布于人人都是产品经理,未经授权,禁止转载。
题图来Unsplash,基于CC0协议。
九七分享吧所有文章来源于网络收集整理,如有侵权请联系QQ2387153712删除,如果这篇文章对你有帮助或者还不错的请给小编点个小赞(◠‿◠),小编每天整理文章不容易(ಥ_ಥ)!!!
还没有评论,来说两句吧...