后台|后台设计漫谈——电销系统设计思路( 二 )


譬如每天派一次那就能确保当天的任务都被分配掉,用户池不会积压;而电销员请求一次派一次则能确保电销员的任务不会有积压,具体怎么选择就看业务需要了。
然后是考虑电销员日常会用到哪些功能,譬如拨打电话、添加备注信息、挂起、选择完成状态等等;这里面比较重要的是需要关注电销员需要看到哪些用户信息,敏感信息一定要脱敏。
然后是数据呈现的问题,电销员是需要看效果数据的,因为他们是拿提成的,所以他们会需要看到自己拨打之后的实际转化效果,要展示明细数据,方便他们自己计算能拿多少钱。这一点非常重要!这一点非常重要!这一点非常重要!
至于怎么才算他们的业绩可以根据电销部门的规则要求进行标记。
在这个流程的基础上开始设计和组合功能,电销员的就不细讲了,其实从流程也能看得出来,就三个页面就行,一个是待拨打页面、一个已拨打页面、一个是转化数据页面。页面上的具体和数据就结合业务实际处理。
但是这里面还有一个角色就是前面提到的管理人员的角色,管理人员不参与日常工作,需要单独设计一些管理类的功能给到对方:

  1. 对电销员的一些日常数据的观察,譬如每天的单量大概是多少,不同的电销员每天拨打的电话数量、转化数据,方便管理人员去看哪些电销员是干的好的,哪些是干得不好的;
  2. 需要做一些分支设计,譬如电销员请假、离职、调岗等情况下,挂在他名下的拨打任务的二次处理,允许转分配;当然这里面可能也需要设计电销员的状态,确保新的任务不再派单给暂时不在岗的电销员,确保任务不会积压;
  3. 需要设计权限功能,这个的话就很常规了,一般管理员权限就给到电销部门负责人。
有的后台系统大家是平权的,层级上都是一样的,只是通过权限来区分看到的页面和功能;有的后台系统大家是分层级的,页面可能是同一个,但是功能上有差异,这就要根据实际来处理了。
三、对稿和修改这一步也是必须的,虽然在大体上肯定是没有问题了,但是重要的是细节,一个后台或者功能好不好用,其实最主要还是在细节上。大家经常聊用户体验,其实也就是在细节上更符合用户的预期和习惯、甚至超过用户预期。
当然我其实很少提超过用户预期这一点,因为要做到超预期是很花功夫的,但又很难量化成业绩,想要在流量型的公司得到支持是非常困难的。
对稿这一步就是把你的理解具象出来,然后看一下和电销员的理解是不是一样,就是一个把大家的想象尽可能重合起来的一个过程。
对稿之后就是把修改的点列出来,然后逐一修改。
这一步其实不复杂,重点是沟通得细一点。
以我的经验来说,对稿的时候可能会需要做比较多的修改:一是因为大家的理解未必一样;二是因为电销员的想法会发生改变,所以会需要根据他们的想法做调整;三是有可能在第一次沟通的时候有些东西没有讲出来,所以需要做二次补充。
以上几种情况都是有可能的,而且可能是同时会遇到。
四、开发与验收后台系统其实一般来说不如前端受重视,这是常态。对于很多小公司来说后台系统甚至是敷衍的。
所以在测试环节一定要让电销部门也同时介入验收,一个是能促使技术部门尽可能地按照你的方案进行实现,二是能合理管控电销员的预期。
我遇到过很多次,后台长得还不如我的原型稿好看,这你上哪里说理去。这个时候就需要管理预期了,让电销部门提前介入就是管理预期的一种方式。
技术的同事经验越少的对于后台的易用性通常重视程度越不足,同时很多公司都是业务驱动的,一味强调快,自然而然就放松了标准,这样一来对于实现程度来说也有非常大的影响。
所以一定要注意管理预期,不要因为你无法干预的因素而影响对你工作的评价。
我知道有些朋友甚至领导是反对让业务部门直接介入研发环节的。
一部分是出于岗位认知的原因,认为这个事情就应该产品和业务对接好,技术部门就不能和业务部门进行对接。
后台|后台设计漫谈——电销系统设计思路】我个人的见解是这个认知大错特错,对于一个业务线来说,业务、产品和技术应该尽可能融合,技术接触业务就能更好的理解业务需求,这样就在实现的时候会更好。
一部分是出于部门认知的原因,认为业务部门和研发部门是两个不同的部门,产品经理应该站在研发部门的角度而不是业务部门的角度,这种情况通常是在大公司待久了,产品又放在研发中心下面,所以研发的负责人就会这么来判断。