网络营销微信餐饮配送建设方案.docx
《网络营销微信餐饮配送建设方案.docx》由会员分享，可在线阅读，更多相关《网络营销微信餐饮配送建设方案.docx（22页珍藏版）》请在冰点文库上搜索。
网络营销微信餐饮配送建设方案
{网络营销}微信餐饮配送建设方案
1.前言6
1.1.概述6
1.2.建设目标6
2.总体规划与设计7
2.1.建设原则7
2.2.开发平台及工具8
2.3.技术选型9
2.3.1.采用基于SOA的组件化开发框架，实现组件柔性集成9
2.3.2.基于J2EE的技术应用平台9
2.3.3.三层B/S设计模式10
2.3.4.组件化、面向对象的开发模式11
2.3.5.基于XML的数据支持13
2.3.6.基于WebService接口支持13
2.3.7.基于XX地图GIS平台13
2.3.8.技术架构特点14
3.系统技术方案15
3.1.系统总流程15
3.2.系统组成16
3.3.系统架构17
3.4.运维中心子系统18
3.4.1.菜品维护19
3.4.2.店铺管理21
3.4.3.促销推广23
3.4.4.会员管理24
3.4.5.退款管理25
3.4.6.投诉管理26
3.4.7.日志管理26
3.4.8.员工管理27
3.4.9.评价管理28
3.5.门店子系统28
3.5.1.配送管理29
3.5.2.退款处理30
3.5.3.菜品沽清31
3.5.4.订单管理31
3.5.5.店铺管理33
3.6.微信订餐服务33
3.6.1.店铺选择34
3.6.2.菜品展示35
3.6.3.支付35
3.6.4.菜品推荐37
3.6.5.订单管理38
3.6.6.历史订单38
3.6.7.个人信息38
3.6.8.大客户预约通道39
3.6.9.建议与投诉39
3.7.送餐子系统40
3.7.1.开始配送41
3.7.2.订单送达41
3.7.3.配送记录查询42
4.系统安全设计42
4.1.安全性要求42
4.2.安全方案43
4.2.1.授权管理43
5.附件46
5.1.原型界面（供参考）46
5.1.1.主界面46
5.1.2.点餐界面47
5.1.3.菜品信息界面48
5.1.4.订单界面49
5.1.5.个人信息界面50
5.2.系统报价51
1.前言
1.1.概述
由于企业的数量众多，企业员工对于外卖订餐的需求很大，而其附加值也在不断地提高，本平台就主要针对各个企业员工的工作餐，为员工的订餐提供一个订餐和外卖的平台，为客户提供让其满意的服务。
从消费类型上细分，消费者可分为这样几种类型
（1）个人，这种消费者能够长期订餐。
并且占的比重较大。
个人从消费取向上一般多注重便宜、实惠、好吃。
（2）中小公司员工，这属于白领阶层的一个需要，由于工作忙碌或者其他原因，选择网络叫餐，他们的消费取向一般是方便、实惠，口味独特。
（3）家庭，生活节奏的加快，总会让家庭选择更快的就餐方式，特别是家里来客人，唯一的选择就是足不出户，选择网络叫餐。
这种消费者的消费取向一般是大量、不同采品，不计较消费额，只追求满意。
（4）中高档消费者，这种消费者的消费取向一般都比较挑剔，不在乎价格，追求异众口味。
1.2.建设目标
1、管理自己的客户。
不把自己的客户交给美团、XX来经营。
2、节省人工成本。
客户在微信平台上自助下单，小票打印机自动出票。
外送员撕下小票，直接按小票送餐，高峰期省下人工成本。
而且不会因为电话占线而错失订单。
3、促进常客的消费频次。
经常在吃饭时间前2个小时推送一下促销信息，在客户还没想好今天要吃什么的时候就推送，促进消费频次。
4、线上线下互动。
可以在餐具和餐台上印上二维码，把线下客户引流到线上点餐。
也可以通过推送店铺活动，将线上客户引流到门店里消费。
2.总体规划与设计
2.1.建设原则
系统集成方案将遵循以下几个原则：
1．经济性
经济性主要体现在硬件设备的处理能力指标在满足需求的前提下不会超出太多。
2．扩展性
由于需求及业务的可发展性，系统在投入运行之后很可能会有需求上的变化，通常情况下会在信息处理能力、交换能力等方面对系统提出更高的要求。
实施方案必须考虑这种可能性，便于系统扩展和升级。
3．易于管理
随着数据节点设备的增加，维护人员对设备的管理难度也会相应增加。
方案应尽量降低管理复杂性和管理成本。
从另一个角度来讲，一个易于管理的系统，其可靠性通常也比较高。
4．稳定性
整体系统确保稳定、高效、连续地运营，能够支持全天24小时的连续运行需求。
5．开放性
采用开放标准，开放结构，开放系统组件和开放用户接口。
充分满足用户投资保护和业务扩展、系统维护等方面的需求。
此外，在系统设计还考虑到安全性、保密性、可视处理等需求，力求提供一个完整实用的建设方案。
2.2.开发平台及工具
✓开发语言：
JAVA
✓数据库：
Mysql；
✓微信公众平台；
✓送餐子系统：
安卓APP
✓数据交换：
REST、WEBSERVICE、XML
2.3.技术选型
2.3.1.采用基于SOA的组件化开发框架，实现组件柔性集成
面向服务技术架构SOA（Service-OrientedArchitecture）是一种面向企业级服务的系统架构，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。
SOA使用户可以构建、部署和整合这些服务，且无需依赖应用程序及其运行计算平台，从而提高业务流程的灵活性。
采用SOA架构有利于项目的建设，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
2.3.2.基于J2EE的技术应用平台
J2EE是主流的技术体系，J2EE已成为一个工业标准，围绕着J2EE有众多的厂家和产品，其中不乏优秀的软件产品，合理集成以J2EE为标准的软件产品构建本软件平台系统，可以得到较好的稳定性、高可靠性和扩展性。
J2EE技术的基础是JAVA语言，JAVA语言的与平台无关性，保证了基于J2EE平台开发的应用系统和支撑环境可以跨平台运行。
J2EE平台包含有一整套的服务、应用编程接口（API）和协议，可用于开发基于Web的分布式应用。
它定义了一套标准化、模块化的组件规范；并为这些组件提供了一整套完整的服务、以及自动处理应用行为的许多细节---例如安全和多线程。
由于J2EE构建在Java2平台标准版本上（J2SE），因此，它继承了Java的所有优点――面向对象、跨平台等。
随着越来越多的第三方对Java2平台企业版（J2EE）提供支持，Java已经被广泛用来开发企业级应用。
基于J2EE技术的应用服务器（ApplicationServer）主要是用来支持开发基于Web的三层体系结构应用的支撑平台。
在这种结构中，应用程序不能直接调用后台的数据库存取数据，而要通过中间件产品来进行对数据库的调用。
J2EE应用服务器作为前台应用程序和后台数据库中间的代理，帮助进行应用和数据库之间的交互。
这样，应用程序无法直接对数据库进行操作，增加了系统的安全性；再加上中间件与前端应用和后端平台的独立性，应用程序的开发更加的灵活，不需要考虑对后台的调用，而且中间件性能的进一步开发会带来系统整体性能的提升。
2.3.3.三层B/S设计模式
随着软件系统的规模和复杂性的增加，软件体系结构的选择成为比数据结构和算法的选择更为重要的因素，三层客户/服务器体系结构为企业资源规划的整合提供了良好的框架，是建立企业级管理信息系统的最佳选择。
三层B/S模式（以下简称三层模式）在两层模式的基础上，增加了新的一级。
这种模式在逻辑上将应用功能分为三层：
客户显示层、业务逻辑层、数据层。
客户显示层是为客户提供应用服务的图形界面，有助于用户理解和高效的定位应用服务。
业务逻辑层位于显示层和数据层之间，专门为实现企业的业务逻辑提供了一个明确的层次，在这个层次封装了与系统关联的应用模型，并把用户表示层和数据库代码分开。
这个层次提供客户应用程序和数据服务之间的联系，主要功能是执行应用策略和封装应用模式，并将封装的模式呈现给客户应用程序。
数据层是三层模式中最底层，用来定义、维护、访问和更新数据并管理和满足应用服务对数据的请求。
三层模式的主要优点为：
1.良好的灵活性和可扩展性。
对于环境和应用条件经常变动的情况，只要对应用层实施相应的改变，就能够达到目的。
可共享性。
单个应用服务器可以为处于不同平台的客户应用程序提供服务，在很大程度上节省了开发时间和资金投入；
2.较好的安全性。
在这种结构中，客户应用程序不能直接访问数据，应用服务器不仅可控制哪些数据被改变和被访问，而且还可控制数据的改变和访问方式。
增强了企业对象的重复可用性。
“企业对象”是指封装了企业逻辑程序代码，能够执行特定功能的对象。
随着组件技术的发展，这种可重用的组件模式越来越为软件开发所接受。
三层模式成为真正意义上的“瘦客户端”，从而具备了很高的稳定性、延展性和执行校率。
三层模式可以将服务集中在一起管理，统一服务于客户端，从而具备了良好的容错能力和负载平衡能力。
2.3.4.组件化、面向对象的开发模式
1.组件化设计
“软件组件化”是一种理想的软件开发理念，它主张软件产品的开发应当像制造工业产品那样，首先通过专业化分工生产出不同功能的“零部件”，然后再将这些“零部件”合理地组装起来，形成所需的产品。
“软件组件化”，真正实现了软件复用和组件化生产，极大节约软件产品的开发时间和开发成本。
2.面向对象
面向对象是一种自下而上的程序设计方法。
不像过程式设计那样一开始就要用main概括出整个程序，面向对象设计往往从问题的一部分着手，一点一点地构建出整个程序。
面向对象设计以数据为中心，类作为表现数据的工具，是划分程序的基本单位。
而函数在面向对象设计中成为了类的接口。
面向对象设计自下而上的特性，允许开发者从问题的局部开始，在开发过程中逐步加深对系统的理解。
这些新的理解以及开发中遇到的需求变化，都会再作用到系统开发本身，形成一种螺旋式的开发方式。
（在这种开发方式中，对于已有的代码，常需要运用Refactoring技术来做代码重构以体现系统的变化。
3.采用基于构件的柔性集成的系统架构
基于企业服务总线实现应用系统之间服务交互，即按照制定的总体应用集成规范，指导业务系统开发商按SOA服务构件方式改造（或新开发）应用系统之间的接口，并统一进行服务注册管理和调用，使企业服务总线成为企业标准的、通用的、可管理的应用系统之间的信息桥梁，使现有的应用系统之间点对点的接口程序转变为独立、统一注册、便于管理的服务构件。
2.3.5.基于XML的数据支持
系统内部数据交换全部采用XML标准。
系统平台全面遵循XML标准。
XML数据标准的推出，增强了系统之间、应用系统之间的数据交换功能，也大大增强了系统之间的集成度。
以XML标准描述数据格式，能促进多种数据格式支持、内容共享、内容的再利用以及增强客户对服务的满意度。
使用XML作为数据交换的格式。
由于采用XML技术，使得本系统的内容描述的标准化，实现跨平台、跨应用系统的信息交换更加流畅和便捷。
2.3.6.基于WebService接口支持
系统平台的接口系统除了提供一般的接口以外还提供WebService的接口。
WebService就是在Internet上提供的基于标准XML消息系统的服务，它具有与操作系统和编程语言无关的特性。
2.3.7.基于XX地图GIS平台
XX地图已经与微信、微博一道成为广大用户基于移动互联网的生活习惯，深刻的影响和改变了无数人的生活方式。
XX地图与其他GIS平台比较具有如下优势：
1.“周边”资源丰富
2.产品迭代速度较快
3.开发者体系相对健全
4.品牌优势
5.免费
2.3.8.技术架构特点
技术架构具有前瞻性、开放性、实用性、可扩展性、可维护性。
为满足目前这种跨部门的复杂业务系统需求，技术架构设计方面充分考虑了前瞻性、开放性，针对未来可能情况预留了设计空间，满足易于扩展的需求，使之能适应行业的变化。
同时系统还考虑了实用性、可维护性，保证架构的成熟和系统安全稳定可靠，适应集团级大规模管理应用的复杂性和全面性的需求。
2.3.8.1.对未来应用建设提供开放式标准
现有的各个系统采用不同的技术平台、不同的开发手段、不同的接口标准和不同的部署方式，后期的日常维护和统一管理、后期信息化的优化提升、系统间的信息集成和用户的使用都带来了很大的成本。
本次平台的建设在整体上搭建统一的应用集成平台，并制定应用系统开发建设的标准规范，为后续系统的开发提供了一套开放式的标准，极大地降低了企业的运维成本和系统改造成本。
3.系统技术方案
3.1.系统总流程
1、会员注册
2、订餐
3、生产
4、配送
3.2.系统组成
系统提供四套子系统，分别为不同实体对象服务，包括运维中心子系统、门店子系统、微信订餐服务和送餐子系统。
其中运维中心子系统可设置在总店或者单独成实体。
运维中心管理店铺、会员、菜品和运营需要的各种服务。
总店/分店管理自己日常送餐服务。
订餐客户通过微信公众平台获取系统提供的订餐与配送服务。
送餐员通过二维码扫描和GPS定位等技术手段，为订餐用户提供快捷和直观化的送餐服务。
图1系统组成
3.3.系统架构
图2系统架构
当前，顺口溜连锁店存在着系统卡顿的问题，初步定为数据库服务能力不足，为了解决当前的困境，下面给出了数据库服务器和WEB服务器负载均衡设计方案。
图3服务器负载均衡
3.4.运维中心子系统
图4运维中心子系统功能组成
3.4.1.菜品维护
3.4.1.1.菜品分类
菜品分类定义：
例如爽口小菜、美味小炒、美食爽翻天等等分类，提供对分类的增删改功能，分类为了用户操作方便和现实简介，建议只用一层树目录。
对菜品分类的操作将记入系统日志。
分类包括的功能有：
✓菜品分类维护
✓将菜品添加到菜品分类
✓将菜品从菜品分类移除
3.4.1.2.每日菜品
以星期为单位，可设置每日早、中、晚三餐的提供的菜品，设定好的菜单按照每周循环在用户的微信界面上显示当日的菜单（各个门店相同），各门店可按照自己的实际情况，沽清某个菜品，当进入该门店时候，界面不显示该菜品或者显示该菜品已经售完。
包括的功能有：
✓按星期一到星期日定制菜品
✓菜品下架
3.4.1.3.菜品信息
设置菜品的详细信息，包括浏览图（大小各一张，分别适应手机屏幕和pad屏幕）、详细介绍大图（若干张，用户可手指滑动查看图片介绍）、菜品的名称、月销售单数、评价、菜品详细描述、菜品的价格（基准价）、菜品的限定时间段（有的菜品只能在某个时间段提供）。
包括的功能有：
✓菜品信息维护
3.4.1.4.菜品上下架
为了操作的简便，一些不应季的菜品或者不需要的菜品可以对其进行下架处理，下架的菜品将不再出现在后台每日菜品可挑选的列表之中（相当于回收站）。
当到了菜品对应的季节时，可对下架的菜品进行上架操作（重回可挑选的菜品列表）。
包括的功能有：
✓菜品下架
✓菜品上架
✓下架菜品列表
3.4.1.5.折扣管理
菜品的折扣（按照基准价，线上支付价和VIP价格）在此统一设置，线上支付价按照90%，VIP价格按照85%的默认折扣执行，管理员可调整这些折扣的比例。
此外，大客户折扣也在此设置。
包括功能有：
✓线上支付价折扣调整
✓VIP支付价折扣调整
✓大客户支付价折扣调整
3.4.2.店铺管理
3.4.2.1.店铺信息
分店的创建和修改都在此体现，创建门户的时候，首先可输入门店的大致地址，系统会按照地址弹出下拉框，下拉框中按照地址匹配出现对应的地址列表，管理员选择正确的地址，系统在地图上标注该门店的坐标（或者手工标注），该坐标为配送范围提供基准起始点。
门店的信息包括名称、描述和门店图片等信息，这些将在订餐时候作为门店列表选择项显示。
功能包括：
✓门店信息维护
✓门店坐标确定
3.4.2.2.配送范围
管理员可设定每个门店的最大配送范围，以门店坐标为基点，设定最大配送公里范围，例如5公里，因为各个城区跨度太大，不建议按照行政区进行配送范围设置。
当用户配送地址超出该范围时，系统会提示并拒绝进行支付。
用户订餐时也会按照最大配送范围覆盖情况显示其附近的门店。
包括功能有：
✓门店配送范围调整
3.4.2.3.营业时间
为每个门店设置早中晚的营业时间，用户订餐提交订单的时候会让其选择某个营业时间段进行菜品的生产和配送。
营业时间以星期为单位，循环执行。
包括功能有：
✓门店营业时间设置
3.4.3.促销推广
3.4.3.1.新品推广
管理员可挑出几个菜品进行推广，和热销推广不同的是热销推广是销售数比较大的菜品，新品推广可挑选任意菜品进行推广，功能包括：
✓新增菜品推广
✓设置推广时间
✓菜品推广下架
3.4.3.2.热销推广
热销推广首先列出菜品销售的前几名，由管理员挑选几个作为推广项目，和新品推广类似，功能包括：
✓新增菜品推广
✓设置推广时间
✓菜品推广下架
3.4.3.3.促销信息推送
管理员可对微信用户发送新的促销信息或者其他公告，基于微信一个月只能发送4次公告，所以该功能需谨慎使用。
包括功能有：
✓促销信息编辑
✓促销信息发布
3.4.3.4.菜品促销
类似打折促销，可临时设置一个折扣价，菜品按照这个折扣价进行促销，在用户微信端菜品列表上方醒目显示，功能包括：
✓新增促销菜品
✓促销菜品下架
✓设置折扣
3.4.4.会员管理
3.4.4.1.会员浏览
显示会员列表，可对会员进行查询、排序等操作。
包括功能有;
✓会员查询排序
✓会员详细信息查看
3.4.4.2.信息导出
将会员信息以Excel或者xml格式导出到文件，方便备份和作为他用。
包括功能有：
✓会员信息导出
✓会员信息导入
3.4.4.3.黑名单
管理员可将会员加入到黑名单，黑名单会员将不能提交订单。
功能包括：
✓新增黑名单
✓将会员从黑名单移除
✓显示黑名单列表
3.4.5.退款管理
3.4.5.1.退款处理审核
订餐用户由于各种原因发起退款申请时，首先申请到退款的门店进行处理，处理的结果分为接受退款和拒绝退款，如果接受退款，门店注备退款说明，该申请被移交到运维中心进行审核（会计等），订餐用户的界面查看退款进度时，会有退款处理中、退款已审核和已完成退款几个状态。
退款失败的状态包括：
退款驳回、退款审核驳回几个状态。
包括功能有：
✓每日退款列表
✓退款处理审核
3.4.5.2.退款记录
显示退款历史纪录，包括用户信息、退款的订单、时间、处理状态和审核状态等等。
包括功能有：
✓退款信息查询
✓退款信息分类（审核通过、驳回）显示
3.4.6.投诉管理
3.4.6.1.投诉回复
对用户的投诉与建议，相关人员可在此回复用户，说明改正情况。
包括功能有：
✓编辑回馈信息
✓回馈信息发布
3.4.7.日志管理
后台每一步关键的操作，如删除菜品、下架、更改营业时间等等，都会记录操作人和时间以及相关的信息，备留待查，日志处于安全考虑，不可删除。
功能包括：
✓日志浏览
✓日志查询
✓日志导出
3.4.8.员工管理
3.4.8.1.角色管理
系统角色包括：
财务、店面、客服和管理员，权限分配给角色而不直接分配给员工，员工具备其角色所拥有的权限。
功能包括：
✓角色维护
3.4.8.2.权限分配
权限按照模块划分，如退款管理权限、会员管理权限等，不具备该权限的人员无法进入该模块。
权限分配给角色，再将角色赋予员工。
其具体操作方式是：
选择一个角色，显示所有权限列表，管理员勾选该角色可具备的权限。
3.4.8.3.员工信息
员工信息包括姓名、联系方式、岗位等，其功能包括员工信息的修改和为员工分配多个角色，其具体功能包括：
✓员工信息维护
✓屏蔽员工（该员工不能登入系统）
3.4.8.4.店铺分配
为员工指定所属的门店，只有加入到该门店的员工才能登录所对应的门店子系统。
包括功能有：
✓员工门店归类
3.4.8.5.角色分配
为员工赋予角色，单一员工可拥有多个角色。
包括功能有：
✓员工角色维护
3.4.9.评价管理
3.4.9.1.评价审核
订餐用户在微信发表的评价只能通过管理员审核后其他用户才能看到，功能包括：
✓审核发布
✓审核屏蔽
3.5.门店子系统
图5门店子系统功能组成
3.5.1.配送管理
3.5.1.1.送餐员管理
各个门店管理自己的送餐员（探讨），只有在门店注册的送餐员方可登录该门店的送餐子系统（手机app）。
送餐员信息包括姓名、联系方式等。
功能包括：
✓送餐员信息维护
✓屏蔽送餐员
✓送餐记录列表（按送餐员）
✓送餐统计
3.5.1.2.运费制定
各门店可根据自己的实际情况设置按里程收取不同的运费，微信客户端可依据门店与配送地址确定运费。
包括功能有：
✓按门店里程设置运费
3.5.1.3.起送金额
各门店可根据自己的实际情况设置起送总金额，低于起送金额的订单不能提交和付款。
包括功能有：
✓设置起送金额
3.5.2.退款处理
3.5.2.1.发起退款流程
订餐用户发起退款申请后，门店依据实际情况，为退款备注退款情况，并流转到运维中心进行审核（流程是否符合实际情况待商讨），或者直接拒绝退款申请并给出用户理由。
包括功能有：
✓驳回退款申请
✓退款申请处理通过（待审核）
3.5.2.2.退款进度查询
门店可查询退款的审核情况（参考退款处理审核）。
包括功能有：
✓退款进度查询
3.5.3.菜品沽清
各门店可根据自己的实际情况沽清当日的某些菜品，这些菜品将不会在改门店当日的微信列表中出现（或者显示已卖完）。
包括功能有：
✓沽清菜品
3.5.4.订单管理
3.5.4.1.订单查询
门店可按照日期、用户等条件查询订单并显示订单详细情况。
包括功能有：
✓订单查询
3.5.4.2.厨房打印
该功能需要部署应用程序，监视系统订单，对已经支付的订单进行分项打印，便于厨师依单下菜。
包括功能有：
✓分项菜品打印监控
✓分项菜品打印
3.5.4.3.配送打印
该功能需要部署应用程序，打印整个订单，订单上付上生成的条形码或者二维码，便于送餐员扫描送餐。
由于打印机等异常情况，也可由门店手动通过查询订单进行打印。
（打印的格式、份数商讨）包括功能有：
✓已支付订单监控
✓订单打印
3.5.4.4.二维码生成
系统为每个订单生成条形码或者二维码（选一种），二维码记录订单的单号，送餐员扫描这个二维码可从系统读取订单的详细情况，二维码用来减轻送餐员的输入强度，加快送餐的效率。
包括功能有：
✓订单二维码生成
3.5.4.5.配送地图查询
门店可点击订单，显示当前订单送餐员的位置情况，方便了解送餐进度。
如图：
图6配送地图查询
3.5.5.店铺管理
3.5.5.1.配送范围调整
门店可根据自己的实际情况调整配送范围（参考配送范围）。
3.6.微信订餐服务
图7微信订单服务功能组成
3.6.1.店铺选择
用户点餐的时候首先根据用户所在位置显示附近的门店，用户也可根据当前城市显示所有的门店列表进行订餐（送到门店附近的地址）。
包括功能有：
✓附近的门店
✓门店查询
3.6.2.菜品展示
3.6.2.1.分类展示
用户进入门店后，显示菜品分类列表，界面上方显示促销和推广的菜品。
包括功能有：
✓菜品分类树
✓菜品列表
✓促销和推广菜品广告
3.6.2.2.加入购物车
用户点击加入购物车，将菜品加入到购物车，也可修改菜品的数量。
包括功能：
✓加入购物车
✓修改购物车条目数量
3.6.3.支付
支付流程：
1.选择配送地址
2.选择送餐时间（可选）
3.选择付款方式（微信支付、支付宝、会员卡）
4.提交订单
5.支付
6.微信信息提
升级会员 