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

电话营销系统哪家好用（电话营销系统哪家好些）

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

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

一、选择设计路线

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

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

当时我想了想，有三个选择：

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

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

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

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

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

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

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

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

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

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

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

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

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

二、梳理流程和设计初稿

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

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

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

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

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

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

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

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

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

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

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

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

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

三、对稿和修改

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

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

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

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

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

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

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

四、开发与验收

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

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

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

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

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

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

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

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

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

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

五、最后

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

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

题图来自 Unsplash，基于 CC0 协议

本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请发送邮件至 sumchina520@foxmail.com 举报，一经查实，本站将立刻删除。
如若转载，请注明出处：https://www.yiheng8.com/129430.html