商旅产品设计思路（1）

写在前面

商旅类产品（ Travel Management Companies,简称TMC）主要定位企业市场，其商业模式主要通过（1）为企业提供差旅票务预订；（2）为企业提供差旅管理流程为企业提供服务。

2019年底，公司组建了商旅团队，我以产品经理的身份进入团队负责产品设计，并在后期开始负责整个业务团队。由于市面上可借鉴的产品（尤其是后端模块）较少，且一些业务流程更偏向B端（像财务对账，组织架构管理），再加上之前的自己主导的大多数是C端产品，因而在产品设计的初级阶段，着实踩了很多坑。写下这篇的主要目的是对自己过往的产品设计功能做一个回顾，同时也希望对入坑的同志们有点帮助。

可能刚入坑（尤其是C端转过来）的产品同事会觉得，商旅产品的重点大概是票务预订的正向逻辑和限制预订的反向逻辑，一开始我在试用竞品和自己考虑的时候也是这么设计的，但是随着对于业务流程的越来越了解，这种想法可能太轻率了，从功能框架上来看，商旅类产品大抵可以分成几个功能模块：

1.权限体系；

2.成员&组织架构；

3.制度&差标&票务预订

4.审批；

5.订单&账单；

6.钱包&账。

我用三到四篇的篇幅逐一讲解下每个功能模块，尽量将每个功能模块的业务含义，设计上该注意的点以及涉及的坑讲清楚，可能大家看着看着觉得自己在看需求文档（哭笑不得.jpg）。那么就开始了：

（一）权限体系

这个功能模块可以说是整个商旅平台的基础。后续的其他功能，其实都是基于权限的基础上进行衍生的。

在商旅产品中，有两大类角色：一类叫企业管理者（我们一般称呼为超级管理员），对应的一般是公司的行政或者财务人员，这类角色主要负责的就是将公司的员工录入到商旅系统中，同时为员工制定差标制度并管理公司的日常账务。超级管理员这个角色的用处简单来说就是制定规则，即谁可以使用商旅产品？可以怎样程度的使用产品。第二类角色就是员工。这个“员工”是一个广义上的概念，对应的可能是一家公司的普通员工，也可能是高级管理者，但是至少在权限这个层面上，二者并无差异，这类角色并不考虑怎样制定差标，怎样核算账单，他们更多考虑的是买票（订车，订酒店）这类实际的业务动作。

这里其实已经把商旅产品的用户群体已经做了较为明确的划分，即企业管理员与普通员工，企业管理员聚焦的是分配权限，制定规则。普通员工聚焦的在管理员制定的权限下使用产品。

根据以上的描述，对应的产品功能分别是：

1.权限管理——一般以后台页面或者功能为最小拆分单位，将整个服务后台进行拆分；

2.角色管理——将上述拆分后页面，按照特定的规则进行组合，一般最基本的三种角色：超级管理员（含有所有权限），行政人员（ 拥有员工、部门、差旅制度和审批流的管理权限），财务（拥有对账，充值的权限）；

3.成员管理——即将公司的部分员工分配到对应的角色中；同时需要注意的是，这里进行成员的增，删，并非真正意义上将员工剔除公司，而仅仅相当于员工不再具备某种标签。

举例：这里拿行业里两家商旅或者叫企业出行服务公司的权限模块进行举例，大抵的设计思路都是：

a.注册第一位注册人员即为企业超级管理员；

b.预设部分角色，并分配对应权限，减少企业客户的操作成本；

c.角色标签可从员工层面移除，但不代表员工从企业中剔除。

（二）员工信息&组织架构

成员和组织架构模块：可以理解为将企业的组织架构平移到商旅平台的具象化，为什么这样做呢？因为大多数企业的差旅标准都是根据部门，岗位，职级来确定的，譬如说一般员工只能坐飞机的经济舱，而CEO们可以坐公务舱。和上面的权限体系不同的是，这里的成员一般指的是实际发生票务预订的员工，而非企业超级管理员。

2.1 员工信息相关

商旅平台本身具备了一定的封闭性，一般有效的用户都是通过企业管理员后台录入或者管理员邀请，因此在C端的注册模块可以暂缓考虑或者前期直接不考虑。企业员工信息一般包含：员工姓名，工号，手机号和企业邮箱，职级，所在组织架构及匹配的差标信息。

一般在做C端的产品的时候，需要考虑用户的唯一性，当前一般的做法时用户注册的信息与现有数据库信息（手机号或者第三方账号）匹配，若无记录则视为新注册用户，且此时生成唯一用户ID。在一家企业中，员工的唯一标识是工号，这个时候能不能直接用这个信息作为用户唯一识别呢？不能！原因有两个：

1.数据格式不统一。各家公司的工号规则不一致，很有可能你用户id信息就乱了。

2.工号其实是用户的一个属性，用户的这个属性是可以更换的，就好像用户的手机号也是个属性可以更换。

所以，其实工号这个信息，除了企业内部管理用以外，对于我们商旅产品设计者而言，用处不大，除非你准备做一些由企业“自定义”的功能可能会运用到，这是另一个庞大的话题，这里就不展开。

员工的信息一般由行政人员批量导入或者批量邀请，这里为了减轻用户的工作量，“批量”功能是必不可少的，而且请谨记：尽量不让用户失败，或者失败了让用户知道是啥原因。不然用户面对海量的数据是会抓狂的，最好为用户准备好模板。

成熟一点的商旅软件由于会对接大型企业（员工数四位数，五位数的那种），这个时候再手动导入员工就有点不靠谱了，这时候需要考虑的就是api接口用于与企业现有的软件进行同步，商旅类产品一般会与企业协同（钉钉，企业微信），OA（致远，泛微），费控（每刻，汇联易），财务（用友，金蝶）等软件发生较强的交互，一般涉及到的主要功能点包含：

1.企业信息的新增&变更；

2.员工信息的增删改；

3.组织架构信息的增删改（下面展示）；

4.审批流程的增删改；

5.差标的增删改

2.2 组织架构

组织架构不难理解，在功能上就是员工的归属关系罢了，毕竟很多公司的差标政策是和部门关联的，比如市场部的同学每月的用车费用上限高于产品和运营的同学。

需要关注的是，部门中必不可少的是“部门负责人”这个概念，在实际场景中，部门的负责人一般会负责部门内所有成员的预订审批，所以我们要在功能上将这个人与其他员工区分开来。如果在功能设计的时候遗漏了“部门负责人”，你在后续设计“审批”的时候，会发现你要来补这个功能点。（这个坑我就踩过）

先小结一下：

1.商旅平台一定记住先设计权限体系，这是后续产品的基石，不要轻视；

2.以新增手机号或者邮箱生成用户id，并以此为唯一识别id，工号只是用户的属性，可以变更；

3.组织架构一般需要考虑到将“负责人”与其他员工区分开来。