框架：
1.0用戶痛點和需求價值
1.1用戶痛點描述
用戶下單成功后，有時會遺漏了某件東西，或有朋友想要一起點餐，但又由于聯(lián)系商家和而再下單的時間成本和金錢成本較高，因而作罷。
1.2用戶場景
1）小王是個公務(wù)員，最近天氣很熱，小王一般會選擇和同事一起點外賣，方便省時還不需要自己取。今天上午開了個會，出來的時候大家已經(jīng)點好了外賣，沒有帶小王的那份，小王只能自己點，自己取了。
2）小明在it行業(yè)上班，今天下雨，小明不想頂著雨出門吃飯，于是和朋友幾個一起點了外賣，點完外賣后，領(lǐng)導(dǎo)過來問小明中午點什么外賣，加他一個，小明很尷尬，又不好意思拒絕導(dǎo)師，只能單獨給領(lǐng)導(dǎo)單獨定一份。
3）小李在房地產(chǎn)公司上班，經(jīng)常要出外勤，今天難得能在中午休息時間回到公司，但是團(tuán)隊中大家沒想到他今天會回來，點外賣也沒有問他，小李只能自己點外賣吃，小李感覺自己受到了排擠。
4）小張是個大學(xué)生，平時喜歡宅在寢室打游戲，一日三餐靠外賣解決。今天中午小張室友問小張有沒有一起點外賣，可以省一半配送費，可這時小張已經(jīng)點完外賣了，小張和室友很遺憾，只能約好下次一起點。
5）小黃是個自由職業(yè)者，在家辦公，晚上自己點外賣，點了最愛吃的壽司店，可是剛下完單就想起忘記點飲料，此時商家已經(jīng)接單，取消訂單重新下單很麻煩，小黃只好換上外衣去樓下超時買飲料。
6）小罐和小瓶是一對同居情侶，晚上兩個人都不想做飯，于是決定點外賣。小罐隨便點了一家餛飩，點完后，小瓶發(fā)現(xiàn)小罐忘記點他家超好吃的小菜，兩人心中都很懊惱，只能約定下次再點。
1.3目前用戶的解決方案與問題
目前用戶如何解決的？存在何種問題？
1.4需求評級
【結(jié)論】：由kano模型，本需求屬于期望型需求。
（期望屬性：當(dāng)提供此需求，用戶滿意度會提升，當(dāng)不提供此需求，用戶滿意度會降低）
2.0可行性研究
2.1類似行業(yè)做法
電商行業(yè)是否有類似功能？可否借鑒？
電商行業(yè)加單，用戶只需要在線和商家協(xié)商，重新下單，商家改運費即可。
電商行業(yè)為什么沒有將加單流程產(chǎn)品化？
1）加單期限不可控，因商家自行聯(lián)系快遞，導(dǎo)致中間流程具有不確定性，不利于系統(tǒng)自動識別。
2）用戶與商家自行協(xié)商更方便，用戶加單只需要在發(fā)貨前下單，并告知商家改運費價格即可。
3）商家發(fā)貨場景復(fù)雜不可控，商家服務(wù)類別繁雜，有不適合加單的類別如自動分揀機制，系統(tǒng)難以準(zhǔn)確區(qū)分。
對比電商，外賣行業(yè)的困難點是否有相似？
1）用戶與商家協(xié)商較麻煩，因一些快遞為美團(tuán)騎手派送，商家無法自行修改運費。且外賣商家客服并非標(biāo)配，可能存在回復(fù)不及時或增加人工成本等問題
2）商家發(fā)貨場景復(fù)雜不可控，加單容易造成失誤
3）外賣對時間要求更高，加單勢必造成送餐時間加長，降低用戶體驗
對比電商，外賣行業(yè)有哪些可行點？
1）加單期限可控，外賣流程較電商更清晰，可設(shè)定加單時期為“騎手到店前”或者“騎手出發(fā)前”。
2.2需求實現(xiàn)的問題和解決方式
2.2.1商家側(cè)
2.2.1.1商家類型劃分及問題
【分類】：商家根據(jù)規(guī)模、接單量等可劃分為大商家和小商家。
在接單、出餐、外賣包裹擺放三個環(huán)節(jié)中，前兩個對于本需求影響較少，因此著重考慮第三點。
【外賣包裹擺放差異】：
大商家：訂單較多，外賣包裹較多，容易造成混亂。并且其中一部分商家可能采用自動化分揀裝置，將導(dǎo)致無法支持加單。
小商家：訂單較少，全程采用人工方式，加單困難情況較少。
【問題】大商家采用自動化分揀設(shè)備導(dǎo)致加單困難，是否影響？
首先，大商家占比小，而采用自動化分揀的商家占比更小，因此此問題優(yōu)先級不高。
其次，大商家可選擇是否開通，自行衡量其投入產(chǎn)出比。
所以，無需太過考慮
2.2.1.2接單：自動還是手動？
【結(jié)論】：選擇自動接單，并通過xxx行為來彌補缺陷。
【手動接單問題】：消耗人力和時間。
1、增加人工成本：加單需要商家花費人手額外判斷，而大多商家沒有專門客服處理事件。
2、回復(fù)時間不可控：商家回復(fù)時間較長，不確定性太大。
解決方式：
1、可廣播提醒商家“有用戶加單了，請及時處理”
2、暫無解決方式，考慮自動接單。
【自動接單問題】：加單商品不合適
1、商品可能耗時長，商家可能太忙沒時間做，聯(lián)系用戶取消訂單則對雙方都造成麻煩。
解決方式：
1、提前設(shè)定加單列表與預(yù)計時間。加單表上餐品可自動接單，并提前設(shè)定好每樣商品加單所需時間。同時為商家便利操作，無需每樣商品編輯時間，提供直接時間分類，無需每個菜品都編輯時間。（偽需求，商家直接編輯每樣商品時間更方便）
2.2.1.3時間計算：串聯(lián)還是并聯(lián)？
【結(jié)論】：加單時間計算按照串聯(lián)疊加
【并聯(lián)問題】：商家太過忙碌，導(dǎo)致訂單超時。
【串聯(lián)問題】：可能會增加加單時長，降低加單率。
兩害取其輕，由于加單商品普遍較正常訂單少，因此累加時間超長的場景較少且損失較小，所以選擇串聯(lián)計算。
2.2.1.4商家制作：是否插隊？
【結(jié)論】：商品的加單時間，為商家預(yù)留出一定的時間，因此商家可據(jù)實際情況自主決定，加單菜品是否插隊制作。
2.2.2用戶側(cè)
2.2.2.1幾點前可以加單？
【結(jié)論】：騎手到店前。
【原因】：騎手到店取餐速度快，而其出發(fā)后用戶再加單，騎手回去換餐時間成本較高，有可能影響其他訂單派送。
2.2.2.2加單次數(shù)：可以加單幾次？
【結(jié)論】：每筆訂單只有一次加單機會。
【原因】：從需求頻率上看，加單一次即能夠滿足大部分用戶需求。從流程影響上看，加單次數(shù)越多，對流程各方帶來的不確定越多，越難以保證服務(wù)質(zhì)量。
2.2.3騎手側(cè)
2.2.3.1更改通知：到店時間如何更改對其影響最??？
2.2.3.2其他派送：如何影響？能否解決？
【思路】（待完善）
首先，需要考慮多個派送情況占比多少？
其次，可以選擇合適的加單時間節(jié)點，來減少加單造成的影響。如：在騎手到達(dá)餐廳前用戶可加單等。
第三，如加單時間過長，騎手可選擇放棄訂單或者將其他訂單轉(zhuǎn)交。
（不過，暫時對騎手流程不太了解，等查清楚了再來填）
2.3流程和頁面設(shè)計
2.3.1流程圖
