工作中会遇到各种各样的阻力和限制，可能是个别需求方对设计这一环重视程度低，也有可能是老板压根不关心你负责的部分工作，从项目维度上获得知识并成长通常是藉由跨部门沟通，体验驱动的实验设计可以借助一些老板视线之外的保障项目，以免被各方面掣肘，这也正是其有利有弊的地方。
供应商端的订单管理页面结构上看起来非常复杂，我们区分了“待处理”“已确认”和“已取消”三大类订单类型，其下的子类型和可筛选条件涵盖来看显得很复杂，所以想去做一个重设计。
客人下单后无论支付未支付都会在供应商端生成一笔待处理订单，由于“待处理”同样可针对那些退款待处理/取消待处理的订单，因此我们把新生成的这些未经客人再次染指的订单统称为“新订单”；供应商可在未支付订单24小时之内对客人引导支付，超过24小时订单自动转化为已取消订单；对于已支付的订单，供应商可确认或拒绝资源（订单），同样是超过24小时未确认自动归为已取消订单并向客人全额退款；
客人自行在供应商确认资源之前之后取消订单也有差异，之前的订单即便取消了我们也无需刻意知晓，但已经确认的订单都可能已被派遣了相关的资源，虽然通过线上派遣资源的订单都会在被取消后自动释放资源，但也存在少部分的供应商依然通过线下方式联系派遣，如果不告知必然会引起纷争，所幸随着我们特意在流程上强化，这部分比例正在急剧缩减中。资源派遣在滴滴事件之后做了时间上的限制，如果限制时间之内没有实行派遣则会记为缺陷。
还有一种特殊情况是第三方资源代订，这类退订规则独立，可能与供应商所设的规则有冲突，这就需要客人和供应商自行联系，平台唯一能便利于供应商的就是提供订单备注的功能。当然这是很极端的情况之一。
客人和供应商都可以取消订单，且都可以手动或通过时限被动触发取消行为，而供应商取消订单的行为会计入拒单数，影响预订端显示排名。提到取消自然要谈到退订，这边有“退订”和“退款”两种概念，退订是指取消已支付或未支付的订单，退款则只针对有余额的订单且可设定退款金额，一个场景是客人支付后与供应商商议获得一些优惠，即可发起部分退款的要求，供应商可以针对退款行为批允或拒绝。若批准退款金额达到订单金额，则这张订单记为被客人全部退订。
供应商可以自行设定宽松或严格的退订规则，即客人x日内退订返还y%金额。还有一个坑是针对那些“可订今日”的订单，情况会变得有些复杂。通常而言，客人在下单和支付之前都会与供应商先行联系确认，供应商也会在客人下单之后与之联系，但如若真的有客人直接下单并支付了，产生的退订后果也需要供应商和客人自行沟通处理，除非供应商有设置极为宽松的退订规则。
