后台设计漫谈——电销系统设计思路

3 评论 5125 浏览 3 收藏 14 分钟

编辑导语:电销系统设计是后台设计中常见模式之一,本文作者基于自身实际经验,与大家浅析电销系统的设计思路。从设计路线的三种选择出发,制定流程及设计初稿等步骤,作者列举可能性方案及其相关结果,详实地说明了后台设计中的关键点。推荐相关行业从业者阅读学习~

在我十年的产品生涯里面,其实是更擅长做后台系统的。这当然和个人的职业经验有关系,我长期做互金业务,重头都在后台系统上,前端其实东西很少。

因为年后大概率需要从0到1设计一个电销系统,不经想起几年前做电销系统的事情,所以正好讲一讲以前做电销系统的一些小事,没有那么严肃和系统,但也还是有些东西的。

一、选择设计路线

我在上一家公司从0开始做过一次电销系统,当时正值公司业务规模放大,需要组建电销部门。

但是我没有这方面的经验,电销系统从来没做过。见都没见过,当时内心慌得一批。

当时我想了想,有三个选择:

  1. 去看下同业的系统,参考一下;
  2. 问一下电销部门他们之前有没有使用过电销系统,都有哪些功能;
  3. 问一下电销部门,日常他们的工作流程是怎么样的,梳理流程然后设计后台。

第一条路呢属于偷懒的办法,用已经成熟的系统,好处是功能肯定齐全,坏处是未必那么贴合电销部门的需要。

第二条路属于取巧的办法,电销部门会依据他们的经验给你提供很多有用的信息,因为他们脑子里是有框架的,我要做的是把他们问出来而已,好处是需求最终肯定没问题,坏处是细节需要反复确认,因为他们在表述的时候未必完整和清晰。

第三条路就是笨办法,妥帖是妥帖,但是也很花时间,而且未必做好之后未必会觉得好用。

我个人的建议是能不用第一条就不要用第一条,既然都是自己开发了,就不要搞一个不好用的系统,虽然是内部用户,但是系统架构合理、流程符合业务实际且好用仍然是一个产品经理的基本追求。参考成熟的系统,大概率就是不那么贴合实际需要的,因为那个系统就不是根据你们公司的情况设计的,每家公司的流程和业务情况其实都不一样的。

题外话,这就是功能复杂的saas系统会存在深度定制的问题,SaaS系统要么就做的基础、通用性强,要么就深度定制、功能足够强大。想要通过做通用性的设计来符合大部分公司的需求是不现实的。也不要两头不靠,深不深、浅不浅的,用户付费意愿会很弱。

第3条就是真·笨功夫,沟通的过程会很长,非常耗时。而且你需要实际观察他们的工作流程,因为很多细节是需要在日常工作中体现的。设计的系统肯定能用,但是好用不好用的就得看产品经理的功力了。

又一个题外话,后台系统是按照你的理解和习惯设计的,但是使用的是其他人,所以实际使用感觉上是会有差异的。产品经理的很多习惯和理念都会融合到设计里面,但是这些设计是你觉得好的,别人是怎么感知的不一定。人都是对自己熟悉的事物会天然的觉得亲切和好用,这就是在设计原则上要求不要违背主流习惯的原因。

第2条就是个取巧的办法。电销部门的同事通常会使用过一个或者多个电销系统,所以在他们的脑子实际上是有影子的,你可以让他们把每个功能都复述出来,一边画草图一边沟通,相对高效一些。

把他们觉得好的地方保留,不好用的提修改意见,没有用的就可以去掉。注意,即便是这样也不是一次沟通就可以解决的,但比第3条路还是要快很多。

最最最重要的是,由于这是他们结合自己的经验提出来的,所以符合他们的认知和习惯,好评度相对高一些。

记住,能巧不能笨,能笨不能懒,懒对于一个产品经理来说绝对不是一个好习惯。

我当时用了第2个办法,因为有条件。

二、梳理流程和设计初稿

然后我就在电销同事表述的基础上梳理了一下流程和功能框架。业务流程肯定是优先于功能框架的,流程都走不通设计框架是没有用的。

流程的设计其实就考虑注意使用人员的需要就行,虽然使用后台的包含电销员和管理人员,但是管理人员本身并不参与日常工作,所以不需要考虑他们的流程。

电销系统的流程倒是不复杂的:

首先要考虑的就是被电销的用户有哪些,这个的话就需要业务部门确定下来。

其次就考虑这些用户怎么派单给电销员,派单逻辑是怎么样的,是每天派一次,还是电销员请求一次派一次,不同的派单逻辑效果是不一样的。

譬如每天派一次那就能确保当天的任务都被分配掉,用户池不会积压;而电销员请求一次派一次则能确保电销员的任务不会有积压,具体怎么选择就看业务需要了。

然后是考虑电销员日常会用到哪些功能,譬如拨打电话、添加备注信息、挂起、选择完成状态等等;这里面比较重要的是需要关注电销员需要看到哪些用户信息,敏感信息一定要脱敏。

然后是数据呈现的问题,电销员是需要看效果数据的,因为他们是拿提成的,所以他们会需要看到自己拨打之后的实际转化效果,要展示明细数据,方便他们自己计算能拿多少钱。这一点非常重要!这一点非常重要!这一点非常重要!

至于怎么才算他们的业绩可以根据电销部门的规则要求进行标记。

在这个流程的基础上开始设计和组合功能,电销员的就不细讲了,其实从流程也能看得出来,就三个页面就行,一个是待拨打页面、一个已拨打页面、一个是转化数据页面。页面上的具体和数据就结合业务实际处理。

但是这里面还有一个角色就是前面提到的管理人员的角色,管理人员不参与日常工作,需要单独设计一些管理类的功能给到对方:

  1. 对电销员的一些日常数据的观察,譬如每天的单量大概是多少,不同的电销员每天拨打的电话数量、转化数据,方便管理人员去看哪些电销员是干的好的,哪些是干得不好的;
  2. 需要做一些分支设计,譬如电销员请假、离职、调岗等情况下,挂在他名下的拨打任务的二次处理,允许转分配;当然这里面可能也需要设计电销员的状态,确保新的任务不再派单给暂时不在岗的电销员,确保任务不会积压;
  3. 需要设计权限功能,这个的话就很常规了,一般管理员权限就给到电销部门负责人。

有的后台系统大家是平权的,层级上都是一样的,只是通过权限来区分看到的页面和功能;有的后台系统大家是分层级的,页面可能是同一个,但是功能上有差异,这就要根据实际来处理了。

三、对稿和修改

这一步也是必须的,虽然在大体上肯定是没有问题了,但是重要的是细节,一个后台或者功能好不好用,其实最主要还是在细节上。大家经常聊用户体验,其实也就是在细节上更符合用户的预期和习惯、甚至超过用户预期。

当然我其实很少提超过用户预期这一点,因为要做到超预期是很花功夫的,但又很难量化成业绩,想要在流量型的公司得到支持是非常困难的。

对稿这一步就是把你的理解具象出来,然后看一下和电销员的理解是不是一样,就是一个把大家的想象尽可能重合起来的一个过程。

对稿之后就是把修改的点列出来,然后逐一修改。

这一步其实不复杂,重点是沟通得细一点。

以我的经验来说,对稿的时候可能会需要做比较多的修改:一是因为大家的理解未必一样;二是因为电销员的想法会发生改变,所以会需要根据他们的想法做调整;三是有可能在第一次沟通的时候有些东西没有讲出来,所以需要做二次补充。

以上几种情况都是有可能的,而且可能是同时会遇到。

四、开发与验收

后台系统其实一般来说不如前端受重视,这是常态。对于很多小公司来说后台系统甚至是敷衍的。

所以在测试环节一定要让电销部门也同时介入验收,一个是能促使技术部门尽可能地按照你的方案进行实现,二是能合理管控电销员的预期。

我遇到过很多次,后台长得还不如我的原型稿好看,这你上哪里说理去。这个时候就需要管理预期了,让电销部门提前介入就是管理预期的一种方式。

技术的同事经验越少的对于后台的易用性通常重视程度越不足,同时很多公司都是业务驱动的,一味强调快,自然而然就放松了标准,这样一来对于实现程度来说也有非常大的影响。

所以一定要注意管理预期,不要因为你无法干预的因素而影响对你工作的评价。

我知道有些朋友甚至领导是反对让业务部门直接介入研发环节的。

一部分是出于岗位认知的原因,认为这个事情就应该产品和业务对接好,技术部门就不能和业务部门进行对接。

我个人的见解是这个认知大错特错,对于一个业务线来说,业务、产品和技术应该尽可能融合,技术接触业务就能更好的理解业务需求,这样就在实现的时候会更好。

一部分是出于部门认知的原因,认为业务部门和研发部门是两个不同的部门,产品经理应该站在研发部门的角度而不是业务部门的角度,这种情况通常是在大公司待久了,产品又放在研发中心下面,所以研发的负责人就会这么来判断。

这种情况当然不是全部,但是我遇到过,研发中心的负责人CTO直接就当面指责我不应该把业务拉进来,导致技术和业务部门有摩擦。我当时没说啥,但是很快就找了新工作。一个公司的高层,居然主动搞部门墙,格局就不是很高了,不值得跟随。

五、最后

今天说的东西其实并不具体,都是个人的心得和体会,但也还是有点东西的,希望对大家有个启发。

 

本文由 @产品人玄青 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 刚好做过一个类似的系统,派单—拨打电话—状态记录—流转至微信—信息记录和业绩分配

    来自广东 回复
    1. 可以沟通一下吗

      来自河南 回复
  2. 能巧不能笨,能笨不能懒。讲的很精髓。

    来自广西 回复