框架：
1.0用户痛点和需求价值
1.1用户痛点描述
用户下单成功后，有时会遗漏了某件东西，或有朋友想要一起点餐，但又由于联系商家和而再下单的时间成本和金钱成本较高，因而作罢。
1.2用户场景
1）小王是个公务员，最近天气很热，小王一般会选择和同事一起点外卖，方便省时还不需要自己取。今天上午开了个会，出来的时候大家已经点好了外卖，没有带小王的那份，小王只能自己点，自己取了。
2）小明在it行业上班，今天下雨，小明不想顶着雨出门吃饭，于是和朋友几个一起点了外卖，点完外卖后，领导过来问小明中午点什么外卖，加他一个，小明很尴尬，又不好意思拒绝导师，只能单独给领导单独定一份。
3）小李在房地产公司上班，经常要出外勤，今天难得能在中午休息时间回到公司，但是团队中大家没想到他今天会回来，点外卖也没有问他，小李只能自己点外卖吃，小李感觉自己受到了排挤。
4）小张是个大学生，平时喜欢宅在寝室打游戏，一日三餐靠外卖解决。今天中午小张室友问小张有没有一起点外卖，可以省一半配送费，可这时小张已经点完外卖了，小张和室友很遗憾，只能约好下次一起点。
5）小黄是个自由职业者，在家办公，晚上自己点外卖，点了最爱吃的寿司店，可是刚下完单就想起忘记点饮料，此时商家已经接单，取消订单重新下单很麻烦，小黄只好换上外衣去楼下超时买饮料。
6）小罐和小瓶是一对同居情侣，晚上两个人都不想做饭，于是决定点外卖。小罐随便点了一家馄饨，点完后，小瓶发现小罐忘记点他家超好吃的小菜，两人心中都很懊恼，只能约定下次再点。
1.3目前用户的解决方案与问题
目前用户如何解决的？存在何种问题？
1.4需求评级
【结论】：由kano模型，本需求属于期望型需求。
（期望属性：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低）
2.0可行性研究
2.1类似行业做法
电商行业是否有类似功能？可否借鉴？
电商行业加单，用户只需要在线和商家协商，重新下单，商家改运费即可。
电商行业为什么没有将加单流程产品化？
1）加单期限不可控，因商家自行联系快递，导致中间流程具有不确定性，不利于系统自动识别。
2）用户与商家自行协商更方便，用户加单只需要在发货前下单，并告知商家改运费价格即可。
3）商家发货场景复杂不可控，商家服务类别繁杂，有不适合加单的类别如自动分拣机制，系统难以准确区分。
对比电商，外卖行业的困难点是否有相似？
1）用户与商家协商较麻烦，因一些快递为美团骑手派送，商家无法自行修改运费。且外卖商家客服并非标配，可能存在回复不及时或增加人工成本等问题
2）商家发货场景复杂不可控，加单容易造成失误
3）外卖对时间要求更高，加单势必造成送餐时间加长，降低用户体验
对比电商，外卖行业有哪些可行点？
1）加单期限可控，外卖流程较电商更清晰，可设定加单时期为“骑手到店前”或者“骑手出发前”。
2.2需求实现的问题和解决方式
2.2.1商家侧
2.2.1.1商家类型划分及问题
【分类】：商家根据规模、接单量等可划分为大商家和小商家。
在接单、出餐、外卖包裹摆放三个环节中，前两个对于本需求影响较少，因此着重考虑第三点。
【外卖包裹摆放差异】：
大商家：订单较多，外卖包裹较多，容易造成混乱。并且其中一部分商家可能采用自动化分拣装置，将导致无法支持加单。
小商家：订单较少，全程采用人工方式，加单困难情况较少。
【问题】大商家采用自动化分拣设备导致加单困难，是否影响？
首先，大商家占比小，而采用自动化分拣的商家占比更小，因此此问题优先级不高。
其次，大商家可选择是否开通，自行衡量其投入产出比。
所以，无需太过考虑
2.2.1.2接单：自动还是手动？
【结论】：选择自动接单，并通过xxx行为来弥补缺陷。
【手动接单问题】：消耗人力和时间。
1、增加人工成本：加单需要商家花费人手额外判断，而大多商家没有专门客服处理事件。
2、回复时间不可控：商家回复时间较长，不确定性太大。
解决方式：
1、可广播提醒商家“有用户加单了，请及时处理”
2、暂无解决方式，考虑自动接单。
【自动接单问题】：加单商品不合适
1、商品可能耗时长，商家可能太忙没时间做，联系用户取消订单则对双方都造成麻烦。
解决方式：
1、提前设定加单列表与预计时间。加单表上餐品可自动接单，并提前设定好每样商品加单所需时间。同时为商家便利操作，无需每样商品编辑时间，提供直接时间分类，无需每个菜品都编辑时间。（伪需求，商家直接编辑每样商品时间更方便）
2.2.1.3时间计算：串联还是并联？
【结论】：加单时间计算按照串联叠加
【并联问题】：商家太过忙碌，导致订单超时。
【串联问题】：可能会增加加单时长，降低加单率。
两害取其轻，由于加单商品普遍较正常订单少，因此累加时间超长的场景较少且损失较小，所以选择串联计算。
2.2.1.4商家制作：是否插队？
【结论】：商品的加单时间，为商家预留出一定的时间，因此商家可据实际情况自主决定，加单菜品是否插队制作。
2.2.2用户侧
2.2.2.1几点前可以加单？
【结论】：骑手到店前。
【原因】：骑手到店取餐速度快，而其出发后用户再加单，骑手回去换餐时间成本较高，有可能影响其他订单派送。
2.2.2.2加单次数：可以加单几次？
【结论】：每笔订单只有一次加单机会。
【原因】：从需求频率上看，加单一次即能够满足大部分用户需求。从流程影响上看，加单次数越多，对流程各方带来的不确定越多，越难以保证服务质量。
2.2.3骑手侧
2.2.3.1更改通知：到店时间如何更改对其影响最小？
2.2.3.2其他派送：如何影响？能否解决？
【思路】（待完善）
首先，需要考虑多个派送情况占比多少？
其次，可以选择合适的加单时间节点，来减少加单造成的影响。如：在骑手到达餐厅前用户可加单等。
第三，如加单时间过长，骑手可选择放弃订单或者将其他订单转交。
（不过，暂时对骑手流程不太了解，等查清楚了再来填）