业务受理平台不难理解，即将现有业务的线下受理依靠互联网工具迁移到线上来，同时在现有业务的基础上实现互联网+服务最大化。

业务梳理

既然设计的是业务型平台，那就首先要对整体的业务很熟悉，包括业务的内容、范围、输入和输出以及业务流程等。

• 内容：即业务介绍，对于一项业务首先要知道这项业务是关于什么的；
• 范围：即业务受众，哪些人会跟这项业务相关，是针对的个人还是企业；
• 输入：即受理单位需要获取的信息，既然是业务受理则肯定有提交方和反馈方，这里的提交方是输入的源头；
• 输出：即业务结果，该业务受理完成后是以证书的形式还是以其他相关的文件进行反馈；
• 业务流程：即受理流程，业务型平台本身是出于反馈方提高工作效率的目的，因此要把业务完整的受理流程进行梳理，避免造成产品设计过程中逻辑不清晰；

 （右击在新标签页中打开可查看大图）

产品定位

通过对业务知识的获取，我们对我们所需要做的业务平台的核心有个大概的了解，接下来我们就是对其平台这款产品进行定位，毕竟传统业务转型的目的也是希望能在线受理更多用户的申请，因为只有找准了产品定位，才能解决用户线下办理的痛点，才能让这种看似传统业务的工作成功依靠互联网工具进行方向性的改变。针对其考虑我做了如下内容的梳理：

首先是目标用户的梳理，对其目标用户做标签化。

其次是场景思考，思考除线上申请外的其他需求场景，几种场景进行罗列，一是方便对其产品的用户有个更精准的定位，另外一个方便产品后期的规划和宣传；

• 场景一：企业网站或系统买了很多安全设备和安全服务，那安全防护能力达到了一种什么样级别呢？有什么量化的标准呢？
• 场景二：市面上有那么多的安全厂商和安全服务，购买哪些就可以让企业的网站或系统安全呢？
• 场景三：已经购买了网站安全服务，但是安全服务厂商做的怎么样呢？

场景四：用户来访问网站，怎么能让他知道正在访问的网站是安全的呢？

根据我们对用户和场景的分析，我们的平台产品定位是：解决用户异地申请证书及后期安全服务量化的需求；

需求分析

在对其产品的需求分析中，我采用了KANO模型进行分析，目的是对其平台的开发进行阶段性的需求管理；

基本需求：线上提交需求基本信息、申请表信息和申请材料，线上获取证书『这里强调该业务中涉及的证书为电子版』；

期望需求：安全服务可量化，输出量化的报告能定期给老板汇报；

兴奋需求：能通过平台实时查看网站或系统的安全态势；

产品设计

通过对其产品的需求分析，首先考虑实现第一阶段用户的基本需求，即在线提交材料及信息办理获取证书，对其我做了产品框架的整理：

 （右击在新标签页中打开可查看大图）

后期规划

在实现基本需求的基础上，后期的规划主要是对需求池中的需求『如期望需求和兴奋需求』进行整理，同时根据用户的反馈和对用户的调研进行需求分析，把相关需求分析的功能点依据“四象限原则”进行按期设计和开发。产品是个漫长的过程，需要产品经理的精雕细琢，前期的基本需求只能说是我们创造了产品，而真正塑造一款产品需要我们在现有设计的基础上不断增添用户的兴奋性需求，但是最初的方向『即初衷』不能错，因此对于业务型平台的设计一定首先要做的就是懂业务！