今年有幸参与了某度假屋项目从0到1的设计过程，展示给用户的是精致的APP，然而APP背后却是逻辑比较复杂的后台系统。APP的使用体验，很大程度上是由后台系统决定的，后台系统逻辑的合理性决定了APP的核心流程。
业务介绍
简要介绍一下此项目的业务流程如图1所示：
业主购买度假屋并由物业管理公司托管，业主购买度假屋有三种类型：全套、分权、分时，全套即业主购买整套度假屋，分权即业主购买度假屋部分产权，分时即业主购买某季的居住权。
业主每年可以获得一定数量的居住券，分权、分时业主每年获得28张居住券，全套业主每年获得365张优惠券。业主可以选择自住、换住、出租，其中换住是在平台进行，业主将一部分居住券储存在平台，平台返还用户一定数量的换游币，用户可以使用换游币在APP预定其他地区的度假屋并前往居住。所以，此平台是一种度假权益交换的共享度假平台。
图1
后台系统设计
了解业务以后，我们详细介绍后台系统的设计思路，后台的主要系统构成以及流程如图2所示：
图2
销控管理系统主要对度假屋的销售情况进行管理，以及线上的销售合同管理；物业管理系统对度假屋托管情况进行管理，以及线上的物业托管合同管理。
业主托管并签订合同后，业主信息将传递给会员中心和空间管理系统，空间系统根据淡旺平季以及度假屋类型，分发给业主相应的居住券。
业主可以用居住券在APP储存，储存成功后获得平台的换游币。居住券的储存，换游币的换算等动作都是通过super后台系统，同时，super系统还要对空间管理系统的房屋进行包装，最终在APP展示相应的房源。
super系统是APP的核心后台系统，分为运营、客服、超级管理员三种角色，运营主要对系统中的房源信息进行编辑；客服查看订单和会员相关信息，同时可以帮助业主储存居住券。
用户在APP下单后，订单中心生成入住订单，物业方在PMS系统确认订单，PMS系统主要是物业方进行排房、订单管理、房态房量管理、房价管理等操作。
有的物业方没有PMS系统，平台提供了PMS供物业方使用，如果物业方原来就有PMS，则平台提供E-Booking系统供物业方与平台对接，E-Booking系统是平台与物业方确认房源、房屋底价录入、房态房型管理、结算等操作的对接系统。
总结
作为项目的产品经理，首先需要对业务非常熟悉，要做到懂系统人群里最懂业务的，懂业务人群里最懂系统的，这样才能将业务逻辑很好的融合进系统，转换成系统流程。后台产品经理与前台产品经理，前者需要深刻理解业务，将现有的业务流程落实到系统，支撑前台的功能流程；而后者更需要对用户行为进行深入挖掘，对交互和体验有一种死磕精神。
本文只是粗略的说明了此项目后台的系统功能及流程，具体的每个系统还有比较复杂的内部功能逻辑，后续文章会做详细的说明，敬请期待~
