本文介绍了G端产品的客户特点、G端客户心理需求模型、利益相关方模型等内容，enjoy！

在我们做政府端产品过程中，经常会遇到利益相关方的问题。作为产品团队，我们经常会去做用户调研，然而遇到政府客户，我们就会发现，事情不是想象的那么简单，大多数情况下，政府客户（后面简称G端客户）并不是最终用户。这时，我们需要把客户和用户合并起来考虑，统一叫做利益相关方。

调研中，我们会发现，每个利益相关方需求，关注点都不一样，尤其当利益相关方的需求出现了冲突的时候，我们应该如何抉择；当资源有限的情况下，我们又应该如何分配，才能得到一个各方都满意的结果。

在本文中，我们基于G端客户的特点及心理需求，构建了G端利益地图，更清楚了呈现了利益相关方之间的关系，更有效的解决在做G端产品中我们经常遇到的困难。

首先，让我们来分析一下G端客户具有哪些特点：

一、G端客户特点

1. 用户非客户

这点跟B端产品类似。不一样的是，B端的客户和用户往往属于一个公司，或者一个体系，G端的客户和某类用户可能之间只存在服务与被服务，监管与被监管的关系。

2. 潜在客户难以触达，特别是决策者

因为决策者往往是领导，而除非有特别的关系，或者是客户主动找到我们，领导往往不太容易见到。因此这就更需要我们在关键节点之前，做好充分准备。

3. 竞品难以获取

虽然B端产品也存在这样的问题，但是G端可以说是难上加难。B端往往在竞品网站上能找到一些信息，或者试用版，但是在G端，却很难找到，这跟G端的定制化程度高有比较大的关系，且政府应用的封闭性，增加了获取难度。

4. 客户决策流程较长

政府端通常有一个决策流程，我们能够接触到的，一般是执行者，而执行者往往需要向领导汇报，如果关系到位，可以在关键节点见到决策者，这个时候就需要把握机会，汇报关键内容，争取决策者的信任。预算也是非常关键的因素，弄清楚政府部门在这方面的预算，是至关重要的，预算直接关系着决策的结果。

5. 客户往往是行业专家

客户通常是某个政府行业领域的专家，比如城管局，药监局，交管局等等。这就需要我们去拜访客户之前，对行业有着充分的理解，了解产品需要解决该行业什么痛点，才能够有机会取得客户的信任。

6. 客户的目标不是商业目标

这点跟B端产品不太一样。政府客户往往期望产品能够帮助他们做好监管，规避风险，及时发现问题，如果更好一点，能够树立标杆，体现政绩。而B端往往更关注节省成本，提升效率。

二、G端客户心理需求模型

从以上的分析我们可以产出，G端产品的利益相关方通常比较多，且各自需求不一致。对于乙方公司来讲，决策者的需求当然是最重要的，为了更好的说明决策者的需求，我们总结了以下G端客户心理需求模型，越往上的需求有优先级别越高。

这里要解释一下的是，绝不是说往下的需求就不重要，比如说更好的体验，只是我们认为体验好是最基本的必要条件。这里来简单的阐述一下这个模型：

1. 可靠性

这个对于政府来说是最主要的考虑因素。政府需要项目能够顺利完成，信息数据的安全保密，并且有人长期维护。其中最重要的当属信息安全了。有很多企业目前提供SAAS服务，那么在说服政府的数据上云就需要做好功课及应对方案。

2. 风险控制

很多政府类产品的存在就是为了做风险控制。

比如明厨亮灶，就是为了避免或减少食品中毒案件的发生，或者在发生之后，可以追责溯源。这里面就会有专业的食品安全检测的流程，产品在设计的过程中就要考虑到如何帮助客户实现这个目的。

3. 体现政绩

即使是同一个行业，不同的地方政府对于产品的需求都会有所不同，这也是为什么政府项目容易产生定制化的原因。发达地区追求标杆项目，其他地区追求地方特色。

政府项目还有一大特色就是领导来考察的时候，需要有内容可以给领导展示，因此大屏展示的需求会比较多，大屏要展示什么内容，这个需求往往是定制的，很难做到标准化。

4. 效率提升

这个跟ToB 的需求就类似了。就拿我司产品12345政务服务热线来说，整个产品涉及到监督部门，客服人员，委办单位等5类角色，一个工单需要在这5类角色之间流转，并且需要对人员每月进行工作量统计，绩效考核，这个时候如何提升效率就显得尤为重要。

5. 更好的体验

其实所有的角色都需要更好的体验，但是有一类人群，我们可能需要特别关注，这个我们一会儿在利益地图里会讲到。

三、利益相关方模型

这里我们抽象出了一个利益地图模型，按照利益和权力划分为两个维度，通常我们的利益相关方可以按照利益和权力的不同程度对应进入四个象限里。

第一象限，驱动决策者来做某个项目，一定是有相关的政策或者考评要求，因此我们设定他们为利益最高的人，相应的，他们的权力也是最高的（这里主要是指对项目的决策权）。

我们对这类角色，需要做的就是满足他们的目标，这里的目标对应着心理模型里面的可靠性，风险控制以及体现政绩。

第二象限通常是管理者或者执行者，他们也是有一定的权力，但是他们更多的是要去使用系统去做具体的管理和执行，对于他们来说，最关注的是效率。

如果决策者和管理者之间的需求出现了冲突，一定要及时提出，由于我们和管理者对话较为容易，可以请管理者跟决策者确认一下需求，以达到统一。

第三象限通常是被监管者或者是最基层用户，他们一般都是被考评对象，使用系统的时间通常较长，在业务流程上，他们并不是制定者，因此没有很大的发言权，但是我们也不能因此对他们忽视。我们可以尽可能为他们优化体验，让他们在长时间使用系统的过程中，能相对轻松。

第四象限通常是政府的服务对象，也就是公众。他们对第一象限有着一定的舆论监督作用，有时候也会跟第三象限建立起服务与被服务的关系。他们并不被强制使用产品，如果能够满足他们一些核心需求，可能才会使用。

下面我们以我司产品12345政务服务热线来举例说明，怎么应用这个模型。

如下图所示，我们很清晰的能够看到每个利益相关方的关注点，以及他们之间的关系。

1. 产品的总体目标

我们应该从决策者，也就是政府信息化部门领导那里获取项目的总体目标，这里往往包含了一些定制化的需求，比如大屏展示哪些内容，页面风格的定制等等。但是作为产品团队，我们需要融合产品团队自身的目标。

2. 业务需求获取

我们通常从第二象限的用户来获取主要的业务流程，以及他们需要达到的管理目标。对于此例中的督办岗来说，他们需要对工单数据进行统计分析，并且能够对工单进行跟踪督办。另外，我们也可以使用服务设计蓝图，来画出不同用户之间的业务流程交互。

3. 对体验的要求

第三象限有两类用户，其中使用时间最长的就是话务员，对于话务员来说，他们是被管控的员工，同时，使用系统时间最长，因此我们需要优化他们的体验，比如设计“刁难用户转移”功能，“夜间工作模式”。

4. 提取核心利益点

对于公众来说，使用12345政务热线产品客户端，一般来说有以下两种情况：

1. 热线电话打不进去
2. 想要快捷查询工单进展

第一种需求也是话务中心希望的，这样能够给话务中心分流。因此方便快捷的提交意见单，以及方便快捷查询工单进展是公众的核心需求。并且由于客户端模式太重，我们通常建议客户采用公众号的形式来提供服务。

从以上案例中我们可以看出，利益地图可以让我们快速理清各方诉求，合理的分配设计资源，设计出利益相关方都认可的G端产品。

下面让我们最后做一个总结：

1. 产品的总体目标需要从第一象限决策者处获取，但要与产品团队自身目标做融合。
2. 具体业务需求通常从第二象限管理者/执行者处获取。如果决策者和管理者之间的需求出现了冲突，请管理者跟决策者确认一下需求，以达到统一。
3. 第三象限的用户我们通常要给予体验上的关注。
4. 第四象限通常是公众端，关注核心利益点的顺畅实现即可。

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

题图来自Unsplash，基于CC0协议