分析：滴滴司乘意見徵求會所提的建議
知“錯”能改，善莫大焉。最近滴滴的一系列整改舉動，似乎很有誠意。文章就滴滴司乘意見徵求會所提的建議來分析一下，一起來看看~
滴滴做整改、整治，提供更安全便捷服務的這件事，將導致更多人信任依賴它，有了更多人的支援，滴滴也必將持續改善服務。{做事件X，導致Y，Y促進X，不斷良性迴圈。}
這樣的表現，恰好符合 “複利效應” ，而只要把握住複利效應的利率（提供更安全便捷服務），便可形成差異化服務。 但，只有加強差異化重複發生的可能性，才能處於複利模型加速成長階段。
10月6日，滴滴召開司乘意見徵求會，主要關於產品功能及規則的反饋建議。其中，有以下3點建議，我比較感興趣。
對此就做了分析及思考：
- 一鍵報警不醒目，容易被誤碰
- 司機端的防疲勞駕駛規則僵化，有時與接單獎勵規則產生衝突
- 醉酒乘客處理規則
一、一鍵報警
“一鍵報警”起到震懾作用，不涉及風險是對安全最有保障的設計。
在還沒設計“一鍵報警”這個功能前期，如若對乘客進行不恰當的行為最多是遭受乘客的差評，投訴。沒有更有力的制裁制度，導致一小部分司機很容易沒有敬畏感。但在如今複雜司乘的關係形勢下，增設“一鍵報警”功能，即一旦進行報警，司機就有可能要揹負違紀的行為，受法律制裁。
從滴滴徵求司機意見中的“一鍵報警容易誤碰”可以看出，很多司機對此功能有敬畏，但更多的是感到恐懼。因為絕大部分的滴滴司機都在為生活所奔波，司機擔心碰到奇葩的乘客，故意觸碰報警。給司機造成時間以致其他方面的損失。
所以在設計該功能需要考慮的不僅要給乘客提供最便捷的安全保障途徑，也要考慮到司機接單途中的順利，保障司機切身的利益。（誤碰設計的必要性）
醒目設計需要考慮：
- 如果是在車內進行行凶的話，很可能就一瞬間的事情。（在慌張的情況下根本來不及觸發）
- 如若，依前兩次的作案方式，作案人員將其車開出人群之外，此時的 路線已經偏離正常的規劃，送達預估時間也已經異常 。
- 如果是採用系統對訂單的異常做出判斷，可能風險會降低。（自動觸發機制）
- 再者，如果每位乘客每一趟行程都要做提防，一直關注司機行為與APP介面的“一鍵報警”，那這樣的出行根本是不爽的。
綜上，“一鍵報警”可以設定成浮窗，以長按的形式做誤觸防護。
具體實現是：“一鍵報警”介面按正常方式開啟，介面有浮窗可選項，設定浮窗開啟，退出滴滴出行app時，可以懸浮。點選浮窗，浮窗提示“長按報警”。
二、獎勵金
司機提出的這一條“司機端的防疲勞駕駛規則僵化，有時與接單獎勵規則產生衝突”想必司機已經明白，這是滴滴的運營策（Tao）略（Lu）。
滴滴專車獎勵制度（每天完成訂單數）：
- 18單及以上，獎勵金88
- 28單及以上，獎勵金188
- 38單及以上，獎勵金288
防疲勞規則：連續服務3小時，處於收車模式20分鐘，計費時長累計完成10小時，處於收車模式至時長清零。
獎勵呈階梯式上升，初期很多司機也都是卯足勁想賺一大筆，畢竟獎勵金對司機很有誘導力。但滴滴以保護司乘“安全”為由，用防疲勞規則來成功的保住獎勵金。
怎樣保住？
我們來看一項分析：
以一單平均25分鐘計，一單25￥計，達到18單需要7.5小時，滴滴抽取的佣金90￥（每單20%計）。然而獎勵金是88￥，滴滴最後獲利2￥？
顯然Average 25分鐘是不成立的。
實際接單中，是不可能沒接到長途訂單的，試想只要從中指派幾個中長途的訂單，控制一單平均36分鐘（17單需10.2小時），就可以成功啟動防疲勞規則，讓你處於收車模式。完成不了獎勵金規定的訂單數指標。
顯然，系統可以事先把絕不大部分的賬號做標籤，控制其訂單數在17單內。想要完成獎勵規定的訂單數很曲折啊。
既然該條建議被委婉的呈現出來，說明一點， 滴滴也認為該運營機制可能不是最佳的， 需要制定更利好的規則。（像收取佣金過高，是否考慮調整。這種不利好的說法就不該被指出）
如果是如下的規則，滴滴能接受嗎？
每天計費時長累計7小時後，後續計費時長期間訂單數達到8單，獎勵金28￥，且累計時長清零。
如果滴滴後臺的資料呈現出“計費時長累計比較短，平均少於5小時（不積極）”，的情況，則這樣可以促進司機積極性的規則，也許是更好的機制。（比起拿不到的獎勵金，好拿的28￥更受青睞）
三、醉酒乘客
限制醉酒乘客單獨乘車、增加醉酒標籤和特殊報備、設定醉酒保護金、只允許有攝像功能的車輛接醉酒乘客等。
關於保障醉酒場景下出行安全的方案，可謂是漏洞百出呀。
平臺能識別出哪個訂單是醉酒乘客？
不能吧（檢測酒精含量需要專用的測試儀，一個APP有何能耐）。
既然，演算法做不到識別出哪位乘客是醉酒的，那如何做限制？
等司機發現乘客是醉酒，取消其訂單。這樣的做法，不妥之處有兩點：
- 其一：因為醉酒乘客本身就處於迷糊，不理智狀態，過激的做法會直接引起衝突，造成更惡劣的影響。
- 其二：司機可以隨意取消訂單，轉私下交易。
系統無法預先判斷出醉酒乘客，系統同樣也無法精準的把醉酒乘客的訂單指派給有攝像功能的車輛。所以“只允許有攝像功能的車輛接醉酒乘客”的考慮同樣是沒有基於特定場景。
增加醉酒標籤，倒是一個可行的方案。但，系統同樣無法通過演算法實現篩選——標記。
歸咎，系統是無法識別乘客是否處於醉酒狀態。那處理醉酒乘客的問題，應該聚焦於司乘“條約”。
條款說明中，應該寫入該條司乘條約：醉酒乘客在下單時，需主動選中“醉酒標籤”，醉酒標籤的訂單在服務時，給司機帶來損失，平臺視情況與乘客分擔負責。如若未選中“醉酒標籤”，在服務時，給司機帶來損失，乘客負全責。
最後的這條建議，似乎看起不像是司機所提出來的建議，更像是 滴滴的戰略。
建議為司機提供更加豐富和便利的一站式服務，解決車輛保養、加油以及日常用餐等後顧之憂
但願滴滴對得起，“滴滴一下，美好出行”的初衷。
本文由 @不一樣先生 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自網路