后台|后台设计漫谈——电销系统设计思路注册资本|集成电路|贾朝晖|联

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

文章插图
在我十年的产品生涯里面，其实是更擅长做后台系统的。这当然和个人的职业经验有关系，我长期做互金业务，重头都在后台系统上，前端其实东西很少。
因为年后大概率需要从0到1设计一个电销系统，不经想起几年前做电销系统的事情，所以正好讲一讲以前做电销系统的一些小事，没有那么严肃和系统，但也还是有些东西的。
一、选择设计路线我在上一家公司从0开始做过一次电销系统，当时正值公司业务规模放大，需要组建电销部门。
但是我没有这方面的经验，电销系统从来没做过。见都没见过，当时内心慌得一批。
当时我想了想，有三个选择：

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

第一条路呢属于偷懒的办法，用已经成熟的系统，好处是功能肯定齐全，坏处是未必那么贴合电销部门的需要。
第二条路属于取巧的办法，电销部门会依据他们的经验给你提供很多有用的信息，因为他们脑子里是有框架的，我要做的是把他们问出来而已，好处是需求最终肯定没问题，坏处是细节需要反复确认，因为他们在表述的时候未必完整和清晰。
第三条路就是笨办法，妥帖是妥帖，但是也很花时间，而且未必做好之后未必会觉得好用。
我个人的建议是能不用第一条就不要用第一条，既然都是自己开发了，就不要搞一个不好用的系统，虽然是内部用户，但是系统架构合理、流程符合业务实际且好用仍然是一个产品经理的基本追求。参考成熟的系统，大概率就是不那么贴合实际需要的，因为那个系统就不是根据你们公司的情况设计的，每家公司的流程和业务情况其实都不一样的。
题外话，这就是功能复杂的saas系统会存在深度定制的问题，SaaS系统要么就做的基础、通用性强，要么就深度定制、功能足够强大。想要通过做通用性的设计来符合大部分公司的需求是不现实的。也不要两头不靠，深不深、浅不浅的，用户付费意愿会很弱。
第3条就是真·笨功夫，沟通的过程会很长，非常耗时。而且你需要实际观察他们的工作流程，因为很多细节是需要在日常工作中体现的。设计的系统肯定能用，但是好用不好用的就得看产品经理的功力了。
又一个题外话，后台系统是按照你的理解和习惯设计的，但是使用的是其他人，所以实际使用感觉上是会有差异的。产品经理的很多习惯和理念都会融合到设计里面，但是这些设计是你觉得好的，别人是怎么感知的不一定。人都是对自己熟悉的事物会天然的觉得亲切和好用，这就是在设计原则上要求不要违背主流习惯的原因。
第2条就是个取巧的办法。电销部门的同事通常会使用过一个或者多个电销系统，所以在他们的脑子实际上是有影子的，你可以让他们把每个功能都复述出来，一边画草图一边沟通，相对高效一些。
把他们觉得好的地方保留，不好用的提修改意见，没有用的就可以去掉。注意，即便是这样也不是一次沟通就可以解决的，但比第3条路还是要快很多。
最最最重要的是，由于这是他们结合自己的经验提出来的，所以符合他们的认知和习惯，好评度相对高一些。
记住，能巧不能笨，能笨不能懒，懒对于一个产品经理来说绝对不是一个好习惯。
我当时用了第2个办法，因为有条件。
二、梳理流程和设计初稿然后我就在电销同事表述的基础上梳理了一下流程和功能框架。业务流程肯定是优先于功能框架的，流程都走不通设计框架是没有用的。
流程的设计其实就考虑注意使用人员的需要就行，虽然使用后台的包含电销员和管理人员，但是管理人员本身并不参与日常工作，所以不需要考虑他们的流程。
电销系统的流程倒是不复杂的：
首先要考虑的就是被电销的用户有哪些，这个的话就需要业务部门确定下来。
其次就考虑这些用户怎么派单给电销员，派单逻辑是怎么样的，是每天派一次，还是电销员请求一次派一次，不同的派单逻辑效果是不一样的。