网站建设公司关于本文在本栏目上一节“O2O电子社区商务网站平台建设:产品架构解决方案(上）”，与各位分享过部分规划方案，本文继续就未完部分与各位探讨，O2O电商平台购物车在O2O业态下的逻辑相对于电商而言会轻很多。在订单确认环节会根据场景来完成信息的过滤和计算，场景主要包括商家维度和区域维度。这里按照经验给出一个判断的方式，拥有购物车的O2O模式一般需要商家+区域维度进行过滤处理，而没有购物车的则只需要区域维度。过滤的信息包括促销、优惠券等，而部分信息需要根据这两个维度进行计算，比如金额和履约范围等。
O2O大多是短距离承约，因此配送（服务）范围需要根据履约地点进行计算，超出的需要告知用户，履约地点默认定位为用户当前地址，也可以由用户自行填写。金额的计算也需要通过判断区域维度来完成，比如商品类配送需要考虑运费的变化以及预计送达时间的调整，而服务类配送则要调整订单预估金额和计算预计履约时间。最后说一下会员的前端处理。一般来说，如果存在商家店铺的概念，对于会员来说，则包括平台会员和商家会员两个概念，但商家会员往往会以CRM的标签方式来处理，而不会特别标注在前端的App中。会员的概念多数指平台的会员服务体系。O2O的运营主要是平台模式，与电商的商家平台在功能结构上是一样的，同样会分为平台整体调控运营的功能和商家店铺内的运营功能。而服务类的O2O没有店铺和商品的概念，个体替代了店铺和商品。功能上主要包括个人信息及资产的管理、订单的处理两个大的模块。个人信息主要是资质认证和一些平台沟通的功能，订单主要是进行查看、接单、履约及结算等。拥有不同资质的个人可以承接不同类型的订单，比如房产租赁类的保洁、维修服务对应的个体就是保洁人员和维修人员，他们可以根据各自的类型承接相应的订单并进行履约。说到履约，它也是O2O和电商具有最大区别的地方。
O2O的履约分单和路线指定对于服务质量的影响远大于电商，虽然现在也有部分平台支持次日达，但电商的配送时效一般在3天左右，而O2O往往是以小时为计时单位的，因此O2O的配送也可以称为即时配送。由于时效的要求，我们需要快速处理响应变化的情况和订单的调度，这就要求分单的逻辑要特别考虑时效性的问题。与此同时，根据O2O的不同类型，我们将履约类型分为商品履约类型和服务履约类型，前面运营环节提到，服务履约不需要店铺和商品，个人即店铺，服务即商品，因此订单属于后付费类型，而商品类的多数为预付费类型。这样就造成两种类型的订单在不同环节的差异，商品履约在用户确认信息后就生成订单，这个流程和电商比较相似，而服务履约需要核实用户的订单诉求，等待分配。接下来就会进入分单流程，电商系统对订单的拆解和合并往往是基于仓库和发货地址的，其目的是提高仓内分拣效率，同时也尽可能优化配送时效。但对于O2O来说时效是最重要的指标，因此处理订单会优先考量时效性，其次是服务质量以及运力调配，在分单过程中，本着快速响应的需要，平台会优先允许抢单。抢单指所有服务人员可以根据自身情况进行接单，所有的用户订单诉求会流入抢单池，未被接的订单可以被相关人员抢单并提供服务。
O2O社区电商平台建设系统的分单逻辑是根据一些因子进行派单，比如当打车类应用短时间内无人接单时，系统会根据服务人员的所在区域匹配度、服务质量和车辆类型等因素进行派单，确保订单不会出现无人响应的情况。我们认为抢单和派单已成为商品类型订单的唯一固定规则，即按照商家归属和可接单状态进行派单。分单的因子包括服务区域、配送人员距离远近、服务质量、天气、服务内容、预计履约时间和运力能力等，由于篇幅原因，这里不对分单的细节逻辑进行详述，网上也有很多类似的算法和逻辑，大家可以自行了解一下。还有一种情况是O2O的订单需要进行人工调度，由于对时效的高要求，在履约过程中因为不可抗力（比如天气、事故等）的干扰，需要快速完成订单的履约调度，人工运营有权对订单进行二次分配，从而确保订单在发生履约意外的时候可以尽快通过其他途径完成履约。后续的流程和电商的流程基本相同，这里就不做详解了，大家可以参考电商的流程来设计规划。好了，
网站建设公司本文关于“O2O电子社区商务网站平台建设:产品架构解决方案(下）”至此就分享完毕，谢谢您的关注，希望能给您的项目规划工作有所帮助。
