起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B 端 SaaS 產品自動化事件設計 – 規則表達式
編輯導語：隨著B端行業的熱度不斷上升，相關討論度也在不斷上升，一些產品經理想進入B端行業，但是了解甚少。在B端SaaS產品中，我們經常會遇到一些自動化事件設計模塊。本文就B端SaaS產品自動化事件設計進行了分析講解。推薦對B端SaaS產品自動化感興趣的用戶閱讀。
背景：由于疫情或政策原因，目前某預約SaaS平臺商家反饋希望能夠對用戶進行身份識別，以便判斷用戶是否具備預約資格。
一、需求分析
1. 商家的聲音(Voc)
- 商家A ：xxx市只允許某某?。衬呈谐猓?/strong>的用戶進行預約。
- 商家B：xxx市本地市民憑xxxx身份證開頭可購買預約特惠票。
- 商家C： xxx市疫情指揮部要求，具備48小時核酸記錄才能進行預約。
- 商家D： xxx市提供的老人/小孩用戶定向預約。
2. 場景分類
經過信息收集整理，了解到目前商家提及的需求場景主要有以下3類：
- 商家僅提供本地化服務項目。
- 商家配合疫情防控彈性約束。
- 限定特定年齡段、性別等屬性。
3. 業務價值
- 降本增效：自動化便于商家高效管理預約訂單，代替人工完成繁瑣重復的工作，降低勞動成本，提升效率。
- 政策法規：自動化配置滿足目前疫情大流行背景下，配合地方政府進行風控管理。
- 業務彈性：對于特定約束的服務項目，能夠自由組合規則匹配符合的定向用戶，自動過濾甄別。
- 可用程度：需求具備豐富預約業務可落地場景，自動化產品能力具備標準化特性，具備高度可復用特性。
- 技術成本：技術實現周期短，屬于商家業務關鍵痛點，付費升級意愿高，已有xx家意向商家。
- 緊急程度：?緊急重要程度高，目前已有xx家商家受到地方政府管控影響業務正常運營。
二、產品規劃
1. 現有業務流
（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”?；蛘呱矸葑C是“440100”開始，并且不含“440199”的規則?？梢赃@樣表達：({身份證}[以…開始]{440300})且({身份證}[不含]{440399})或({身份證}[以…開始]{440100})且({身份證}[不含]{440199})。
從上面的講解可以看出，隨著組合規則的增加，設定和閱讀規則變成一件極具難度的事情，對于使用者來說，有很高的學習成本。
經過使用者測試發現，基本超過3項后都在“或”組合規則的時候，會對規則閱讀和理解產生障礙，接下來問題就是考驗實際UI界面展示的時候如何進行交互表達。
3. 規則表達式方案
在經過市面上5款類似產品設計后，提出了 A/B/C 3種設計方案。通過給定設定任務和閱讀任務，對 3 位使用者進行易用性測試，大致的結論如下。
方案A：直接條列式設定規則，對于不同的規則可以根據需要選擇“且”和“或”組合方式。方案雖然滿足可用性，但是并沒有解決使用者在使用上設定和閱讀的障礙。
方案B：在方案A的基礎上，拆分為規則組，把規則拆分成更小的單元來看待。規則組很好解決了設定的問題，但是對于閱讀來說，還是存在不小的問題。比如，在第一個規則組后再使用“且”進行組合，那就變成兩個組其實是一個組，在閱讀上并不直觀。
方案C：在前面總結的問題，最后決定采用規則組內只可使用“且”，規則組間只可使用“或”組合。對于專業人士來說，設置復雜的規則表達式會變得重復。但是對于普通人來說，卻是更加直觀和直覺。
所以，在規則表達式設定上，采用“方案C”。
4. 規則表達式更新機制
預約資料表單在實際使用過程中，會面對業務需要進行表單內容的調整。由于自動化事件是關聯在表單之上，會受到表單內容的約束。
當修改預約資料表單的字段影響自動化設定規則時，系統需要進行檢查并引導使用者進行操作。針對表單修改影響規則，可以在“?”預覽，并可以快速一鍵排除。如果不確定，可以暫不處理。
又或者點擊“馬上更新”進入自動化設置頁進行調整，對于影響的規則進行突出顯示，原則上還是希望能最大程度簡化使用者的操作難度，提高操作效率。
四、總結
對于B端產品，特別是對于SaaS產品來說，接收到客戶的需求，通常信息是比較片面的?？蛻糁粫嬖V你需要什么，設計產品的能力不能只站在單個需求上來考慮問題，需要抽離出來看“某一類能力”或“某些業務場景”，結合業務價值一起進行判斷。
對于“自動化事件”的能力設計，可以應用的場景非常多。比如，數據變更、顧客下單、取消業務、定時任務等等，只要涉及一個標準的條件(觸發項)，都可以通過邏輯表達式進行判別。
而后續的行動，當然也不止本文提及的限制顧客進行下單預約。還可以根據實際業務提供行動，比如，發送短信、贈送優惠券、自動打標簽等等。
這是一個SaaS產品能力原子化之后的結果，作為SaaS產品經理不只是要增加產品能力，拓展產品解決問題的深度。能力不是越多越好，是有限的能力可以產生更多元的業務組合，這需要思考怎么把產品能力可以抽象成更為基礎的能力單元，便于組合能力單元不斷發展，深化。
希望對你有所幫助。
#專欄作家#
龍國富，公眾號：龍國富，人人都是產品經理專欄作家，人因工程碩士。致力于終身學習和自我提升，分享用戶研究、客戶體驗、服務科學等領域資訊，觀點和個人見解。
本文原創發布于人人都是產品經理，未經授權，禁止轉載
題圖來Unsplash，基于CC0協議
專欄作家
龍國富，公眾號：龍國富，人人都是產品經理專欄作家，CxHub主理人。致力于終身學習和自我提升，分享用戶研究、客戶體驗、服務科學等領域資訊，觀點和個人見解。
本文原創發布于人人都是產品經理，未經授權，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
歡迎關注公眾號：龍國富，分享用戶研究、客戶體驗、服務科學等領域資訊，觀點和個人見解。
感謝作者分享！文章干貨滿滿！真的非常有使用價值！
隨著組合規則的增加，設定和閱讀規則變成一件極具難度的事情，對于使用者來說，有很高的學習成本。