於是，今天便有外賣配送平台宣佈將在訂餐系統終端推出一個新功能：在結算付款項上增加一個“我願意多等5分鐘/10分鐘”的小按鈕。據説，訂餐用户只要點了這個按鈕，平台計時系統就會因此增加相應的配送時間，從而讓騎手減輕限時的壓力。所以，這個小按鈕的設計，是不是還頗有點人性化了？
又於是，以後訂餐用户在這個平台訂餐結算付款時，是不是都要點一下“我願意多等5分鐘/10分鐘”的小按鈕呢？如果點了這個按鈕，那麼，毫無疑問，訂餐用户對騎手的關愛之情會溢滿屏幕。但是，問題恰恰在於如果不點這個按鈕，那麼，這樣的訂餐用户是不是就愛心全無，不管送餐騎手的死活了呢？如此這般，以後訂餐用户在訂餐時，每一次都不啻要經受訂餐平台給出的道德拷問：點擊不點擊“我願意多等5分鐘/10分鐘”的小按鈕？
昨天那篇引發公眾關注的文章的題目是《外賣騎手，困在系統裏》。這個標題，把這篇文章的內容概括得清清楚楚，那就是外賣騎手是為訂餐平台的系統所困，而非困在訂餐用户結算付款選項的小按鈕上。實際上，解決騎手所困的方法一點也不難：訂餐平台在系統裏為騎手多寬限些時間，不就解決問題了嗎？當然，這個“一點”也不難，不能讓消費者“一點”，然後騎手就不難了，訂餐平台就由此解脱了。説到底，消費者在訂餐平台消費，只是滿足日常的口腹之慾而已，並不是到訂餐平台來答題的。
在大數據技術驅動下搭建的算法平台，使得外賣行業（不止餐飲外賣）形成了一個新業態。數據也好，算法也罷，從某種角度而言，實際上都是如何管理騎手的問題。解決騎手困在系統裏的問題，最終主要還是要靠系統來解決。在此，無論如何也不能把問題甩給消費者，讓消費者來解決。就説餐飲外賣，騎手的時限並不是消費者設定的，少5分鐘還是多10分鐘，實際上是平台算法根據店鋪出餐時長、路途遠近、交通線路以及車輛速度等因素整合而定。
因此，既然算法還不足以將影響送餐時長的各種實時情況納入系統，並因此而調整送餐時間，那麼，平台原本就應該根據日常經驗數據，如中午晚間用餐高峯的不同時段、雨雪天氣的交通狀況等，在原有限定時長基礎上，分別增加騎手送餐時長。