本文笔者将【jiāng】通过【guò】分【fèn】析Salesforce的设计逻【luó】辑和思路，从其中总结出CRM系统【tǒng】的设计逻辑，以及【jí】在设计中【zhōng】应该注意的【de】一些问题。

最近由于工作所【suǒ】需，为公【gōng】司的销【xiāo】售团【tuán】队设计【jì】了一【yī】套内部使用的CRM销【xiāo】售管理系统。

为了【le】设计【jì】好该类型【xíng】的产品，特地去研究【jiū】并分【fèn】析了该领域的巨头产品——Salesforce，通过分析该【gāi】产品【pǐn】的设计逻辑和思路，对自【zì】己的【de】产品产生一起启发和【hé】思考，并且【qiě】在实际设计过程中面临的【de】一些问题也同时分【fèn】享出来，以【yǐ】期给大家一些启发。

为什么是Salesforce

对【duì】B端【duān】产品接触较少的【de】人可能对【duì】Salesforce不太了解，但是只要涉及【jí】到B端，一定会提到Salesforce这个B端领【lǐng】域的巨头，特别是国内【nèi】的【de】B端产品或多或【huò】少都收到Salesforce的【de】影响。

根据【jù】互联【lián】网女皇玛丽·米克尔最新发布的2019年互联网趋【qū】势报告【gào】：Salesforce公司以【yǐ】1250亿美元市值牢牢【láo】占据B端领域【yù】市值第一的地位，并且在全球互联网企业市值中排【pái】名第11位【wèi】，力压我们熟知的Uber、Booking、美团、百度等【děng】公司【sī】。

是什么支撑起了Salesforce如此高的市值？

抱着研究和为自【zì】己产品找想法的目的【de】，试用了Salesforce的【de】免费试用【yòng】版，顺便说一句Salesforce提供长达30天的免费试用期【qī】，并且【qiě】开放所有的功【gōng】能，足【zú】以看出Salesforce的自信【xìn】和开放程【chéng】度【dù】。

Salesforce总体的设计逻辑

由【yóu】于Salesforce已经是【shì】一个非【fēi】常完【wán】整的生【shēng】态，涉及到企业的【de】方方面面，因此本【běn】文只【zhī】分析【xī】Salesforce的CRM，及销售管理系【xì】统。Salesforce整【zhěng】个产品的设计是任务和目标【biāo】导向的，从主页的【de】设计就可【kě】以看出，Salesforce在分析公司时，采用如下的公式：

业务流=目标+任务

先制定整【zhěng】体的业绩目标，然后目标通过时间段拆解成每个阶段甚【shèn】至【zhì】每天的任务，任务则可以拆解【jiě】成具体的客户【hù】，而【ér】客【kè】户又来【lái】源于【yú】漏【lòu】斗：潜在【zài】客【kè】户→业务机会→联系人→客户。

如下图所示：

通过这种方【fāng】式，Salesforce将不同公司的销售【shòu】业务都【dōu】抽象出【chū】共通的【de】模型，从而设计更加通用的形式。不得不说，Salesforce对【duì】业【yè】务的拆解【jiě】比国内大多数同类型公【gōng】司更加细致和【hé】用心【xīn】。

从菜单导航看Salesforce对销售进程的理解

首先看菜【cài】单栏，和一般同类【lèi】型的【de】产品相比【bǐ】，采【cǎi】用【yòng】比较少【shǎo】见的横向菜单【dān】布局，从视觉上【shàng】对用户更加友好。

并且，每个【gè】模块下拉菜单【dān】都【dōu】只有新建或者历史记录两栏。对比国内的CRM产品会在下拉菜单中【zhōng】加【jiā】入【rù】很【hěn】多子栏目【mù】，Salesforce设计更加简洁【jié】，尽量把功能都【dōu】放在一个页面里，通过【guò】合理的【de】布局让用【yòng】户减少点击的【de】操作步【bù】骤。并【bìng】且，当【dāng】用户习【xí】惯了该产【chǎn】品之后【hòu】，会发【fā】现想要新增内容会非常方便快捷。因为新【xīn】增对于销售是一个比较高频的需求，不【bú】管是新增客户还是任务等【děng】。

从菜单导航【háng】设置【zhì】来看，Salesforce对整个销售的各个进程考虑【lǜ】的非【fēi】常全【quán】面【miàn】。

从【cóng】客户设【shè】置【zhì】就可以【yǐ】看【kàn】出，Salesforce将客户分成【chéng】客户、联系人、潜在客户。

从功能设计可以看出，三【sān】者的区别是：客户是已经确定有交易关系的【de】主体，而【ér】一个客户会对【duì】应多个联系人——即【jí】一家【jiā】公司【sī】会派出多个员工和其他【tā】公司接触。比如会从一般的业务人员到部门领导甚至到公司高管，Salesforce充【chōng】分考虑【lǜ】到【dào】现实商业接触中多【duō】层【céng】级【jí】的接触模式【shì】，因此这方【fāng】面考虑的【de】还【hái】是【shì】非常【cháng】细【xì】致的【de】。

如下图所示：

潜【qián】在客【kè】户则【zé】是和公司没有确【què】定正式的【de】合作关系，但【dàn】是已经有初步接触有【yǒu】发展成客户前景的其他公司。

由于公司刚【gāng】接触的时候【hòu】往往只【zhī】会派一个人进行初步接【jiē】触，所以这里没有设计多个联系人情【qíng】况。当和【hé】潜在用户【hù】接触【chù】时，Salesforce对该类型事【shì】件主要抽【chōu】象成两【liǎng】个模块：进程状【zhuàng】态和任务事【shì】件，这也符合绝大多数公【gōng】司做【zuò】市场时候的需求。

Salesforce提供仪表板【bǎn】的功能来【lái】监控业务【wù】指标【biāo】和分析销售进程，这也是国【guó】内CRM产品比较【jiào】少使用的【de】形式。

在仪表板【bǎn】中，Salesforce关注的【de】数据指标【biāo】主要包括【kuò】：每个阶【jiē】段的销【xiāo】售额；salesforce定【dìng】义的【de】销售阶段包【bāo】括：qualification（可【kě】以理解成接触【chù】阶段）、need analysis（评估阶段）、negotiation（协议阶段）、closed won和closed fail（交易成功【gōng】和交易失败），以及【jí】交易【yì】成功和【hé】交易失【shī】败的客户来源和具【jù】体客户。可以【yǐ】看【kàn】到【dào】，也【yě】是以完成业绩【jì】目标为导向，来分析完成和失败的原因。

总结

总【zǒng】结【jié】一下：Salesforce在【zài】设计CRM产【chǎn】品时【shí】，首先从大的维度定【dìng】义产品要实【shí】现的目的，在这里【lǐ】就【jiù】是完成业绩目标，然后通过将目【mù】标拆成每阶段的任务【wù】——就【jiù】是获得足够多的客户数量。

而客户则来源【yuán】于【yú】层层的转【zhuǎn】化，通过这【zhè】种【zhǒng】方式，产品的逻辑和架构【gòu】逐渐【jiàn】清晰，也为接下【xià】来设【shè】计自己的产【chǎn】品提供了思路。

设计自己的CRM产品1. 如何分析并找到核心需求？

既然分析完了Salesforce产品，为什么要先分析需求？

首先，上【shàng】述【shù】的【de】Salesforce产品，是分【fèn】析了大量公司【sī】真实【shí】的业务需求，包括其他产品【pǐn】的思【sī】路，从而提【tí】炼出最核心【xīn】的需求设计成这种形【xíng】式【shì】。因此，设计【jì】产品的核心还是要从需求出发【fā】，分析并找到核心【xīn】的需求，才能找到真正的高效的业【yè】务【wù】流【liú】转方式。

B端产品需【xū】要和大量的一线业务【wù】人【rén】员沟通【tōng】需求，确【què】定他们的痛【tòng】点和难点，而由于这些业【yè】务人员【yuán】大多是从自己的视【shì】角出发【fā】，一【yī】碰到问题【tí】就容易产生新【xīn】的想法【fǎ】，因此【cǐ】这种需求往往是“拍脑袋的”。

而【ér】作为产品经理，需要根据业务人员所【suǒ】说的需求抽丝剥茧，找到需求的共同点，从而【ér】提炼出核心【xīn】需求【qiú】。B端产品面临的难点往往是定制化和通用【yòng】性的【de】取【qǔ】舍，一方面是要【yào】根据业务人员的实际【jì】需求设计产【chǎn】品，另一方【fāng】面则需【xū】要【yào】抽【chōu】象【xiàng】出通用和共同的东【dōng】西，形成【chéng】一定的通用性【xìng】组件，从【cóng】而【ér】实现产品的良好的可拓展【zhǎn】性【xìng】。

这里【lǐ】推荐需求分析【xī】的PSP方法：即【jí】P（Person，角色）、S（Scenes，场【chǎng】景）、P（Paths，路径），下面通过一条具【jù】体的需求来说【shuō】明如何进行分析【xī】。

首先，这【zhè】条需求非常不明确【què】，主要体【tǐ】现在没有说明如何录入和查看【kàn】哪些信【xìn】息，这时候就需要和一线业务【wù】人【rén】员进一步明确，查看的是【shì】哪些【xiē】客【kè】户【hù】信息。

当明确完之后，需要【yào】确定录【lù】入的【de】方式是【shì】通过手【shǒu】动录入【rù】，还是其他接口来【lái】自己导入【rù】，后续和小李沟【gōu】通细化发现是通过上一步【bù】筛选出来的用户。因此，可以通过【guò】对接上一步【bù】产【chǎn】品的数【shù】据库，来实现数据的自动导入，并且增加手【shǒu】动录入和修改的功能，防【fáng】止【zhǐ】数据有错误。

因此，该需求的核心点是：快速确【què】定客【kè】户【hù】信息【xī】，因【yīn】此通过【guò】自动导入比手工录入和批【pī】量【liàng】录【lù】入都更能解决问题。

同时，通过PSP方法，需要明确不同【tóng】角色【sè】的使用【yòng】场景和路径。在该需求中【zhōng】，主要涉及到【dào】管理员、销售两【liǎng】种角色，录入功能【néng】应该只针对【duì】销售，因为他【tā】们是距离客户【hù】最近的人员，第一时间会了【le】解到客【kè】户【hù】的【de】新的信息。而修改功能应该只针对【duì】管理员【yuán】，因为他们负责管【guǎn】理销【xiāo】售，因此他们有权【quán】修改【gǎi】客户【hù】的【de】进程等相关信【xìn】息【xī】。

2. 设计产品的过程中需要注意的三个问题

在确【què】定完核心需求【qiú】并【bìng】确定了产【chǎn】品的【de】基本架构和框架之后，接下来再具体设【shè】计过程【chéng】中还需要时【shí】刻注意以【yǐ】下几个问题，从而设计【jì】的【de】产品有更大的合理【lǐ】性和可拓展性。

1）数据从哪里来，到哪里去？

乍一看很像哲学家苏【sū】格拉底所说的“从哪里【lǐ】来，到哪里去”的【de】哲学问题，但是【shì】这其实【shí】也是设计该类型产品的一个底层逻【luó】辑【jí】。

C端的【de】产【chǎn】品【pǐn】数据是明确的【de】来自用【yòng】户，而B端产品的数【shù】据往往来源于其他【tā】和系统【tǒng】和【hé】产品的传输，因此明确清楚系统的数【shù】据从【cóng】哪里来，以及如何流转是【shì】设计该产品【pǐn】的【de】第一【yī】步也是最基础的一步。

拿自己设计的系统为例：由于本系统【tǒng】是【shì】针对客户设计的【de】销售管【guǎn】理【lǐ】系统，因此最重要的客户数据来自于H5和【hé】小程序收集的客户信息【xī】，包括客【kè】户【hù】自己【jǐ】填写的手【shǒu】机号和其【qí】他基本【běn】资料【liào】。

因【yīn】此，首先【xiān】要和技术确定开【kāi】发相【xiàng】关的接口去接收【shōu】和传递数据到【dào】系统中【zhōng】。当数据进【jìn】入【rù】到系统【tǒng】中后，要确定数据的流【liú】转规则，也【yě】就是先后顺序和【hé】对应关系，本系统采用的是三级分配的原【yuán】则，也就是数据到最终的销【xiāo】售和经过三层的【de】分配，如【rú】下【xià】所示：

这种分配方式确实不够快速简洁，但是好处有一下两点：

方便组【zǔ】织管【guǎn】理以及职【zhí】级分工，每个角色都【dōu】有【yǒu】自己明确的数据边界和范围。方便【biàn】客户【hù】数【shù】据和【hé】销售【shòu】的1对【duì】多匹配。不同公司对客户的【de】跟进【jìn】有不同【tóng】的规则【zé】，比如有些公司规定是【shì】1个客【kè】户对应1个【gè】固定销售，单【dān】独负责整个流程【chéng】的转化，而【ér】很多公司往往是1个客户对应多个销售，也就是当1个销售转化不顺时往往会换一个销售跟进，因【yīn】此，这样【yàng】设【shè】计【jì】有【yǒu】利于客户对应销售的【de】快速调整。

2）权限角色问题

权限与【yǔ】角色往往是该类【lèi】型产品的一个【gè】重点，不过在【zài】设计权限角【jiǎo】色之【zhī】前，首先需要确【què】定：权限角色实现的目标是什么？

本【běn】质上来说，设计权限角【jiǎo】色【sè】是为【wéi】了让不【bú】同的角色有不同的功能【néng】权限和数据权限，而两【liǎng】者的区别【bié】如下所示：

因【yīn】此，确定好不同角色【sè】对应的功能权限和数据【jù】权限后，会【huì】对【duì】不【bú】同角色的菜单设计和页面设【shè】计产生【shēng】影响。

举【jǔ】例来说【shuō】，上图中的角色1是偏管理员的角色，因此展示【shì】给他【tā】的菜单栏包括了人员配置的功能，而其【qí】他角【jiǎo】色就不应该展示【shì】该【gāi】功能【néng】，如下图【tú】所【suǒ】示：

（角色1）

（其他角色）

3）哪些部分应该模块化？

最后【hòu】，在具体设计功能时，需【xū】要考虑如何把关联性较强的功能或【huò】需【xū】求放在一起，从【cóng】而实现系统的模块化，达到【dào】“松散耦合”：各模块内部【bù】的功能紧【jǐn】密【mì】联系，同时各【gè】模块【kuài】直接【jiē】既有一定【dìng】的关联又保证一【yī】定【dìng】的独立性【xìng】，从而有利于未来系统【tǒng】的扩展。

拿自己做的系统举例：

在做【zuò】的过程中碰到【dào】的【de】一个问题是：数据【jù】统计功能应该【gāi】放到各个【gè】模块中，还【hái】是单独用一个模块整体展示？

因为很多模块【kuài】都有数据统计【jì】的需求【qiú】，并且统【tǒng】计的【de】时间维【wéi】度和字段【duàn】都【dōu】有不同，因此比较纠结到底采【cǎi】用什么形【xíng】式。最后，还是从系统【tǒng】可拓展性的角度，把数【shù】据统计【jì】单独做成一个模块【kuài】，方便未来在模块展示【shì】更多的【de】数据分析相关【guān】功能。而对于不同【tóng】模块的数据统计【jì】如何统【tǒng】一？

这需【xū】要对整个【gè】业务抽象出更【gèng】底层的信息【xī】，找到最关注【zhù】的几【jǐ】个数【shù】据指标，最后进行整合，整合前如【rú】下图【tú】所示，数据指标较多并且比较零散。

整合之后，把总体数据和【hé】时【shí】间【jiān】维度的数据【jù】通过【guò】一个时间筛选器进行筛选【xuǎn】，使得数据的灵活性大【dà】大【dà】增【zēng】加，更加聚焦于【yú】核心指【zhǐ】标，如下图所示：

最后，整个系统的模块大致是如下形式，便于后期更加灵活的拓展。

本文【wén】由 @woer 原创发【fā】布于人人都是产品经【jīng】理【lǐ】。未经许可【kě】，禁止转载

题图来自Unsplash，基于CC0协议

标签： #psp边境之门什么时候能汉化