今天就聊一聊如何通过产品市场去提升多产品售卖情况

随着ToB市场不断发展，融资、市场竞争逐渐加剧，ToB企业为了新融资故事、新营收增长点，都会选择从单一产品逐渐发展成为多元产品矩阵，覆盖更多业务场景。

但在实际多产品销售过程中，我们时常会遇到有限营销资源难以合理分配，BD销售与市场团队存在售卖分歧，不同产品商业贡献差距巨大，产品运营相对独立，高关联度产品难以把握最佳售卖时机，低关联度产品难以进行交叉售卖等诸多现实问题。

那么，今天就聊一聊如何通过产品市场去提升多产品售卖情况；在实际销售过程，「提升多产品售卖情况」这一命题会涉及到多个环节以及对应关键角色：

• 多产品架构的设计：产品经理
• 多产品组合解决方案的设计：售前解决方案经理
• 销售提成、销售考核策略的制定：商机运营经理
• 市场营销（产品运营）：产品市场、产品运营、数据分析师

作为一个产品市场，我们非常希望不同产品能够更好进行组合售卖。一方面，多产品的售卖能够为业务贡献更多营收，不管是带来更多的资源消耗还是附加服务消费；另一方面，多产品的售卖能够有效提高厂商的不可替代性，增加客户粘性，降低流失风险。最后，通过不同产品的组合，也能进一步提高服务质量，降低售后服务成本。

虽然我们可以通过站内相互引流、不同售卖优惠活动、产品组合解决方案、最佳实践的产品组合推广，甚至销售BD的产品搭配考核等不同方式，来拉动多产品组合售卖；但作为一个数据驱动的产品市场（伪），我们今天就来换个视角去思考这个问题。

具体的看「提升多产品售卖情况」这一问题，我们可以会细化成好几个问题：用户在购买什么产品后，在使用产品到什么程度，就会还需要购买什么关联产品，怎么说服他们购买关联产品；这就需要找到不同产品之间的关联性之后，当用户身处在不同生命周期阶段时，我们对用户进行关联产品的价值传递。

那么，具体动作可以拆解为：判定核心产品—解析产品关联度—判断目标受众分群&最佳营销时机—输出产品价值&自动化营销—数据反馈迭代。

一、判定核心产品

想要实现有效的组合售卖，目前很多厂商会选择一拖多的形式进行；因此，判定核心产品尤为重要。

在判定核心产品的过程中，初创企业以及成熟企业有着些许不同。

对于初创企业而言，一方面，很多初创企业在企业早期都是通过单一产品进行PMF，在占据一定市场份额后，逐步展开产品矩阵。另一方面，这个早期单一产品可能是后续其他产品的技术底座或者数据底座；对于这样的企业而言，将主力产品作为整个多产品组合的核心产品似乎成了唯一的选择。

对于成熟公司而言，在占领某个新市场时，可能是多个产品同时面世发布。这时我们可以从两个维度选择核心产品：

• 产品品牌及产品价值维度：目前客户价值最高、口碑最好的主力产品；
• 产品商业贡献维度：AURP值或用户数量高的高流水产品。

在这里，可能会疑惑我们为什么不选择粘性产品、高利润产品？相较于主力产品，粘性产品对于客户的价值可能是在于主力产品解决核心业务问题后的再优化，而非解决业务核心问题；比如在企业上云这个大业务场景下，云服务器资源是采购的核心产品，容器相关产品是提升云服务器资源的使用效率，而非购买的核心产品。

在广告监测场景下，反作弊、渠道分析、转化分析是采购的核心功能，而后续的留存分析等分析模型是后续的精细化功能。

高利润产品同样如此，商业贡献是相对于厂商自身而言的，这对客户而言价值有限；因为高利润产品并不一定代表购买这些产品的企业就一定具有更深的钱包深度以及购买意愿。很多时候，高利润产品是主力产品的附加品，用以贡献利润，平衡收支。

二、解析产品关联度

在判定核心产品后，我们就要开始解析核心产品与其他产品之间的关联度。联系是普遍存在的，关联的存在是具有价值的。在进行解析产品关联度时，可以从产品/解决方案设计维度和运营分析维度进行展开。

一方面，我们通过多个不同功能的产品来组成垂直或者横向的完整业务场景解决方案或者行业解决方案，进行产品的售卖；比如说企业数字化营销路径，一般会从用户行为分析开始，然后自动化营销、个性化推荐、个性化预测这样子的线性演进流程；或者企业上云路径，一般从云服务器开始，然后在研发运维场景围绕容器或者中间件的相关产品进行横向展开。

那么，想要使得产品符合客户的业务发展路径，就需要产品经理、解决方案架构师针对特定行业或者业务场景，将行业理解体现在产品规划上，并将之设置成产品Roadmap，从而进行逐一地实现；或者以解决方案形式将横向或者存在递进关系的产品进行组合，加强产品关联度，并通过各种市场行为进行营销。

另一方面，虽然我们可以通过产品规划以及设计解决方案加强产品关联度，但由于实际使用者或者企业所处阶段、使用情况、业务视角不同，用户在实际使用过程中可能使用的产品与我们所预估的产品组合不尽相同。

以数据分析产品举例，当客户创建超过一定数量的用户分群后，他对于分群运营的需求逐渐提升，那么我们可能认为为客户推荐相关个性化自动营销产品可能是一个非常好的时机；或者，当客户建立了多个单独的事件分析图表，那么推荐相关漏斗分析模型或者留存分析模型，也许是他正在计划的下一步。但也有可能，客户的需求就是到此为止，不会有更深的业务需求。

虽然凭借行业经验，我们可以推测出客户进行交叉组合购买的部分可能，但实际上客户需要的并不止这些，抑或我们在进行主观推断过程中存在偏差。

那么，为了更有效的进行验证，这就需要进行数据挖掘。这里我们可以借鉴关联推荐的相关规则，简单讲解一下关联推荐，关联推荐具有三个核心数据：支持度，置信度，提升度。

• 支持度：衡量某一关联的应用场景的多少（换成人话：关联组合出现的频次）；
• 置信度：衡量某一关联在应用场景的占比（换成人话：关联组合的条件概率）；
• 提升度：衡量某一关联推荐的应用的好坏（换成人话：组合推荐购买某产品概率 / 直接购买某产品的概率）。