2. 場景分類

經(jīng)過信息收集整理，了解到目前商家提及的需求場景主要有以下3類：

1. 商家僅提供本地化服務項目。
2. 商家配合疫情防控彈性約束。
3. 限定特定年齡段、性別等屬性。

3. 業(yè)務價值

• 降本增效：自動化便于商家高效管理預約訂單，代替人工完成繁瑣重復的工作，降低勞動成本，提升效率。
• 政策法規(guī)：自動化配置滿足目前疫情大流行背景下，配合地方政府進行風控管理。
• 業(yè)務彈性：對于特定約束的服務項目，能夠自由組合規(guī)則匹配符合的定向用戶，自動過濾甄別。
• 可用程度：需求具備豐富預約業(yè)務可落地場景，自動化產(chǎn)品能力具備標準化特性，具備高度可復用特性。
• 技術成本：技術實現(xiàn)周期短，屬于商家業(yè)務關鍵痛點，付費升級意愿高，已有xx家意向商家。
• 緊急程度：?緊急重要程度高，目前已有xx家商家受到地方政府管控影響業(yè)務正常運營。

二、產(chǎn)品規(guī)劃

1. 現(xiàn)有業(yè)務流

（1）現(xiàn)有業(yè)務流程不具備用戶身份識別能力，需要構建新的基礎能力或在已有能力上改造已滿足業(yè)務需求。

表單模塊與「自動化」的理念高度吻合，而且表單在預約業(yè)務流程可以廣泛適用于各行各業(yè)。

SaaS平臺在預約業(yè)務流程中，目前已初步具備預約資料表單功能，但在此之前僅用作信息收集用途。

（2）目前平臺預約資料表單提供的字段類型有“聯(lián)系信息字段”和“通用字段”，總結已有字段可以劃分為4種類型進行識別，分別是：字符串、數(shù)字、日期和多選項。

（3）對于不同的字段類型，經(jīng)過競品分析調(diào)研，整理出以下常見的字段匹配規(guī)則。

以“字符串”類型的信息項為例說明：提供了“是”、“不是”、“包含”、“不包含”、“以…開始”、“以…結束”的規(guī)則選項。

對于“字符串”類型題目：你最喜歡的籃球明星是誰？

假設你設定規(guī)則為【是“科比”】，那么對于該題目來說，只有用戶填寫的內(nèi)容完全匹配【科比】，才算匹配上規(guī)則。

如果你設置的是【包含“科比”】，那么用戶填寫的內(nèi)容只要有【科比】，即匹配規(guī)則，如果不含則不匹配規(guī)則。

以此類推，理解其他字段和對應的規(guī)則。

2. 迭代業(yè)務流

為了能從用戶填寫的預約資料進行身份識別，需要對于預約資料進行改造，在預約資料表單模塊添加“自動化事件”。

大致流程是商家端需要先針對預約資料信息項設定好規(guī)則表達式，啟動自動化事件。

當用戶進行服務項目預約時，會進行3輪的檢查。分別是“是否啟用自動化事件” → “是否匹配規(guī)則”→ “匹配規(guī)則是否可以預約”。

商家預設匹配規(guī)則「可以預約服務項目」的話，3項檢查都通過，用戶即可進行服務項目預約。

3. 邏輯規(guī)則表達式

（1）在預約資料表單設定規(guī)則時，存在多項規(guī)則組合設定的情況，比如，只允許A省但不含A1市的市民可以預約特惠項目，用邏輯語言翻譯就是：用戶身份“是A省”且“不是A1市”。

（2）面對這種情況需要使用到邏輯語言進行匹配規(guī)則串聯(lián)，邏輯語言會有：“且(&)、“或(|)”、“非(!)”3種常見的類型。

目前在產(chǎn)品的現(xiàn)有字段中，只需要用到“且(&)”和“或(|)”2種就能滿足需求，未來根據(jù)新增字段類型，再決定增加“非(!)”條件。

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

A且B =A&B =同時滿足A和B規(guī)則，即為匹配。

A或B =A|B=只要滿足A或B其中一項規(guī)則，即為匹配。

另外，在設計過程中，邏輯語言存在一定使用門檻，需要盡可能降低商家在設定時的難度。

三、方案設計

1. 自動化事件

經(jīng)過討論，決定基于原有預約資料表單業(yè)務增加「自動化事件」。預約資料表單已被大量商家投入業(yè)務運營，對于不需管控的商家，默認設定為“不限制”。

商家可以依據(jù)運營需要，自行設定自動化事件規(guī)則表達式并啟用。

2. 復合規(guī)則表達式

（1）單項規(guī)則

單項規(guī)則時，比如限制身份證是“440300”開始的規(guī)則，可以這樣表達：({身份證}[以…開始]{440300})。

（2）“且”組合規(guī)則

多項“且”規(guī)則時，比如限制身份證是“440300”開始，并且不含“440399”的規(guī)則。可以這樣表達：({身份證}[以…開始]{440300})且({身份證}[不含]{440399})…。

（3）“或”組合規(guī)則

多項“或”規(guī)則時，比如限制身份證以“440300”開始，或者以“440399”開始的規(guī)則?？梢赃@樣表達：({身份證}[以…開始]{440300})或({身份證}[以…開始]{440399})…。

（4）混合組合規(guī)則

多項“且”和“或”規(guī)則時，比如限制身份證是“440300”開始，并且不含“440399”?；蛘呱矸葑C是“440100”開始，并且不含“440199”的規(guī)則。可以這樣表達：({身份證}[以…開始]{440300})且({身份證}[不含]{440399})或({身份證}[以…開始]{440100})且({身份證}[不含]{440199})。

從上面的講解可以看出，隨著組合規(guī)則的增加，設定和閱讀規(guī)則變成一件極具難度的事情，對于使用者來說，有很高的學習成本。

經(jīng)過使用者測試發(fā)現(xiàn)，基本超過3項后都在“或”組合規(guī)則的時候，會對規(guī)則閱讀和理解產(chǎn)生障礙，接下來問題就是考驗實際UI界面展示的時候如何進行交互表達。

3. 規(guī)則表達式方案

在經(jīng)過市面上5款類似產(chǎn)品設計后，提出了 A/B/C 3種設計方案。通過給定設定任務和閱讀任務，對 3 位使用者進行易用性測試，大致的結論如下。

方案A：直接條列式設定規(guī)則，對于不同的規(guī)則可以根據(jù)需要選擇“且”和“或”組合方式。方案雖然滿足可用性，但是并沒有解決使用者在使用上設定和閱讀的障礙。

方案B：在方案A的基礎上，拆分為規(guī)則組，把規(guī)則拆分成更小的單元來看待。規(guī)則組很好解決了設定的問題，但是對于閱讀來說，還是存在不小的問題。比如，在第一個規(guī)則組后再使用“且”進行組合，那就變成兩個組其實是一個組，在閱讀上并不直觀。

方案C：在前面總結的問題，最后決定采用規(guī)則組內(nèi)只可使用“且”，規(guī)則組間只可使用“或”組合。對于專業(yè)人士來說，設置復雜的規(guī)則表達式會變得重復。但是對于普通人來說，卻是更加直觀和直覺。

所以，在規(guī)則表達式設定上，采用“方案C”。

4. 規(guī)則表達式更新機制

預約資料表單在實際使用過程中，會面對業(yè)務需要進行表單內(nèi)容的調(diào)整。由于自動化事件是關聯(lián)在表單之上，會受到表單內(nèi)容的約束。

當修改預約資料表單的字段影響自動化設定規(guī)則時，系統(tǒng)需要進行檢查并引導使用者進行操作。針對表單修改影響規(guī)則，可以在“?”預覽，并可以快速一鍵排除。如果不確定，可以暫不處理。

又或者點擊“馬上更新”進入自動化設置頁進行調(diào)整，對于影響的規(guī)則進行突出顯示，原則上還是希望能最大程度簡化使用者的操作難度，提高操作效率。

四、總結

對于B端產(chǎn)品，特別是對于SaaS產(chǎn)品來說，接收到客戶的需求，通常信息是比較片面的。客戶只會告訴你需要什么，設計產(chǎn)品的能力不能只站在單個需求上來考慮問題，需要抽離出來看“某一類能力”或“某些業(yè)務場景”，結合業(yè)務價值一起進行判斷。

對于“自動化事件”的能力設計，可以應用的場景非常多。比如，數(shù)據(jù)變更、顧客下單、取消業(yè)務、定時任務等等，只要涉及一個標準的條件(觸發(fā)項)，都可以通過邏輯表達式進行判別。

而后續(xù)的行動，當然也不止本文提及的限制顧客進行下單預約。還可以根據(jù)實際業(yè)務提供行動，比如，發(fā)送短信、贈送優(yōu)惠券、自動打標簽等等。

這是一個SaaS產(chǎn)品能力原子化之后的結果，作為SaaS產(chǎn)品經(jīng)理不只是要增加產(chǎn)品能力，拓展產(chǎn)品解決問題的深度。能力不是越多越好，是有限的能力可以產(chǎn)生更多元的業(yè)務組合，這需要思考怎么把產(chǎn)品能力可以抽象成更為基礎的能力單元，便于組合能力單元不斷發(fā)展，深化。

希望對你有所幫助。

#專欄作家#

龍國富，公眾號：龍國富，人人都是產(chǎn)品經(jīng)理專欄作家，人因工程碩士。致力于終身學習和自我提升，分享用戶研究、客戶體驗、服務科學等領域資訊，觀點和個人見解。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)授權，禁止轉載

題圖來Unsplash，基于CC0協(xié)議