Introduction

本文着眼于设计映射到产品架构的软件定价策略, and, of course, 市场机遇. 在不同的公司中，定价责任的归属可能差别很大. 在某些情况下，销售、交易部门或营销部门可能拥有定价权，在其他情况下， product management may own it. 不管核心责任在哪里, 产品必须能够提供, 跟踪和报告在定价结构中考虑的销售计量.

Designing an 有效的定价策略 商业模式是进入市场计划中最重要的工作之一. 这不是一门精确的科学, 而是一个不断协商的过程, market validation, operational validation, 行业竞争力, and customer acceptance.

第1部分:探索软件定价模型

任何定价模式的目标都是在最小争议的情况下吸引顾客购买. 明确与测量使用相关的物流，以便有一个可行和可持续的模型.

Licensed Software

软件授权意味着允许某人使用你的软件——无论是作为个人还是作为一个应用程序，它将被绑定到安装它的设备上. 产品经理定义使用术语. 法律团队将帮助定义与合同相关的法律权利 最终用户许可协议 (EULA)和任何渠道/合作伙伴协议. In this model, 定价通常伴随着设置或安装(或供应)费用和维护费.

软件授权定价模式的好处是，收益是预先获得的——这是对底线的一次性提振. 缺点是与客户没有牢固关系的风险. 从同一客户那里获得新的收入往往需要更长的销售周期. For the client, 通常授权软件的成本很高, 他们的偏好可能是按月付款，或者能够更有效地管理他们的现金流.

Subscription Software

软件即服务(Saas) 或者云模型意味着订阅者将“租用”服务——因此EULA将被最终用户服务协议(或类似术语)取代，该协议定义了与使用服务相关的访问权限和使用条款. 定义系统对服务进行计数和收费的方法非常重要.

订阅服务应该随着时间的推移作为使用计量的价值来衡量. 服务协议可采用多种模式，包括:

• Freemium: 通常用作“赔本招财” freemium 模型意味着所接受的服务是免费的. 在设计免费模式时, 期望它是一个非常简单的版本，供应商希望大多数用户能够升级到付费版本. 限制通常基于使用量. For example, 免费增值包可能只允许客户拥有3个活跃的发票账户, 可能不包括工资处理, etc. 但只要支付“名义月费”，用户就可以“开启”附加功能.
• Usage fees: 通常是SaaS模型中提供的服务的经常性费用. 计算使用率可能需要不同的仪表. 仔细考虑这些, 速率越复杂, 客户估计自己的消费(出于预算目的)就越困难，合同谈判就越复杂. Keep it simple. 需要考虑的一些仪表:
  • 每秒事务数(TPS)-每秒并发事务的简单计数，作为一段时间内的平均值. 这种仪表常用于电信业务(如.e. SMS messages). 有些系统每5分钟测量一次，然后除以300作为计算方法. Then, 从计费的角度来看, TPS的最高数字(峰值TPS)是计算任何版税或费用的标准. 如果定价是根据使用断点对批量折扣计算的, 传统的用法将四舍五入到最接近高峰TPS的类别
  • Number of transactions (i.e. API调用)，或者作为一个块，当用完时，必须更新
  • Megabit per second (Mbits/s, Mbps不要与Mbits/sec混淆，后者是毫秒/秒)-或者 Gigabit per second (gbit /s, Gb/s或Gbps) -也用于数据传输测量，通常在高速网络中
  • Storage meters-用于每个时间段使用的存储量的静态计数
  • Number of subscribers–measuring unique identities that are allowed access to the service; simple count
  • 并发用户数–measuring the maximum number of concurrent subscribers–think of this as a pool of licenses that can be shared; this meter is not used often in SaaS/cloud services anymore, 因为它可能导致复杂的审计
  • Minutes or seconds–used often with telecom applications; a count of time on which to meter charging
• Revenue Management: 确定对业务有意义的期限. What is the term? 这是一份为期3年的合同吗.e. Salesforce model)? 是预付一年的牌照吗? 是按月后付费吗? 系统将如何处理真实情况? 在此过程中如何处理针对契约的升级或迁移呢? 取消呢?? 奖励计划或回扣呢?

花时间与财务团队就适当的收入确认要素进行沟通. 请记住，在考虑收入时，也要考虑销售补偿模型. 在任何销售环境中，成功都意味着销售团队必须得到充分和适当的补偿，以保持他们的销售.

Services

Often, 当我们想到服务时, 我们考虑的是支持服务——但是还有很多服务可以成为产品提供的一部分.

• 新员工培训/集成服务: Usually for B2B types of services, 入职也可以被描述为设置, installation, 或者配置费用—通常是一次性的“使其工作”费用，用于需要专有系统集成时. 集成可能包括被称为的元素 操作支持系统(OSS) and 业务支持系统(BSS):
  • 与计费系统连接，实现流量收入管理
  • Connecting with a CRM for subscription management; sharing of customer data
  • 连接到身份验证过程(OATH, Radius, Diameter, Active Directory, SAML, etc.)，以确保只有获授权的用户才能使用系统，并追踪使用情况
  • 应用程序连接器(i).e. 连接到网络服务，a POS 服务、内部数据库、电子商务引擎、目录等.)
• Maintenance Services: 通常与授权软件绑定, 维护费用不是支持服务, 但仅仅是与获得新版本的权利相关的费用, upgrades, bug fixes. 维护服务通常不包括新的特性功能，除非在业务关系中特别包含(法律合同). In a SaaS model, 维护费被认为是订阅费用的一部分(并且应该在您的收入分类中考虑)。.
• Support Services: 通常与访问知识库的能力或与某人获得帮助有关. 支持服务也可能与 服务水平协议(SLA) 哪些条款定义了提供支持的条款, 以及补救措施(升级), 履行责任. In a SaaS model, maintenance fees are considered part of the fees (and should be accounted for in the revenue breakdowns; as those departments will want to share the overall revenues).
• Customer Success: 面向云服务提供商的新兴专业服务, 利用付费的客户成功服务可以扩展 客户终身价值(CLV); provide the analysis to continue to demonstrate value, 并通过展示公司正在履行销售承诺来展示公司的诚信.e. ROI analysis).
• Professional Services: 通常是一组开发人员，他们将一次性获得报酬，以执行某些特定的服务. 这些可能包括针对该客户的特性增强, branding, product customization, etc.

第2节:如何为软件产品定价

获得合适的价格是产品经理面临的最大挑战之一. 我们将研究必须考虑的各种因素, 为了得到一个可行的价格为您的业务.

有两种基本的初始方法可以做出正确的决定. 基于成本的定价可以作为基准来验证您可以考虑的最低价格. 基于价值的定价可以为产品投资带来最佳回报.

Cost-based Pricing

Every company measures gross margins -交付产品/服务的成本. 定价必须达到或超过毛利率目标, 基于商业计划和预期收入. 理想情况下，这不应该成为决定市场定价的方法.

Value-based Pricing

花时间确定基于价值的定价，特别是在SaaS机会中. 在基于价值的定价模型中, 针对当前客户情况，对产品的可微分价值进行定量估计. Does it save them money? Does it make them money? 它能降低风险或责任吗? Does it provide value? 多少钱在什么时期?

有多种方法可以得出一个数字，但作为一个起点——做市场调查. 找出其他人正在使用的数字. 确定他们是否有折扣，如果有，折扣的基础是什么? 确保了解哪些相关服务是收费的，费率是多少. 把家庭作业作为一种有价值的工具来培养捍卫定价建议的信心.

从你的市场调查中发现的价格将是你创造可行性的数字 ROI models. 这不是价目表上的价格.

对市场愿意支付的价格有一定的了解, 向前一步，通过业务需求来提出 制造商标准零售价 (MSRP). 建议零售价是任何商业价目表上的价格.

评估潜在的市场路线

虽然公司现在可能有一个直接面向客户的定价模式，但一定要考虑到在任何时候都可能改变商业模式的“假设”. 长期设计.

• “如果我的大客户想把这个转卖给他们的客户怎么办?”
• “如果我想把它放到市场上?”
• “如果我不得不放弃巨大的折扣来达成交易怎么办??”

Consider the models of:

• “卖给”——某人将其用于自己的消费(只有他们的员工可以使用)
• “与客户一起销售”——与可能想要获得推荐费/中间人费补偿的合作伙伴合作
• “通过销售”——雇佣一个间接销售团队, 或者通过市场销售, 以佣金的形式支付给合伙人的费用在哪里, 收入分成或其其他形式

了解渠道和合作伙伴的标准补偿模式. 预先将这些因素纳入定价中, 这样，当他们出现时，公司就不会发现自己处于毛利率争夺战的底部.

考虑你的折扣等级

请放心，该型号将需要批量折扣. 找出最大的潜在客户, 然后计算出与它们的体积相关的米加上50%. 这是一开始的最大折扣水平. For simplicity (and SKU 管理)，将折扣级别限制在5或6个级别.

Look at the market. 如果仪表与使用量相关，则确定客户在量刻度上的位置. For example, in selling to a telecommunications service provider in a specific geography–and the largest service provider had 50M subscribers; (with subscriber-based price) calculate the largest discount level for 75M (50 x 1.5 = 75M). 如果超过25%的市场同样大，折扣表可能是这样的:

这取决于对目标市场的评估. 如果这个客户是一个异常，那么查看整个客户群并确定大多数客户适合的位置. 针对小客户的客户群, 面对更大的客户仍然很重要, 但考虑到对折扣的需求将来自较小的客户.

设计一个规模，以满足特定市场的要求. 这将需要与定期与这些客户打交道的销售团队进行大量讨论. 尽量让关卡保持简单. 预计将面临压力的挑战，为每个最小的客户提供较低的费率. 找到最佳点(销售团队应该关注的客户规模)，并确定适合该细分市场的折扣.

第3部分:设计有效的定价架构

在将数字放入价格计划之前，请考虑软件架构. 对于SaaS服务，请考虑下面的模型. 它代表了一种以数据为核心的结构——这可能是该公司没有推销的一件事. 应用程序代表了正在销售的实际SaaS服务——但也有潜在的平台访问(api)。, 微服务或数据馈送成为额外的收入来源.

Price accordingly. 如果希望利用核心数据和微服务来创建越来越多的服务, 然后将大部分收益分配给平台.

不要忽视整体的解决方案架构. 作为B2B场景中的SaaS提供商，请考虑定价结构中的输入和输出.

For example, 用于定价分析的定价细分可能会将收益加载到平台和数据馈送中, 只剩下20%的收益来自ui——应用程序;

有组织的定价模式, 新增的云服务(SaaS应用)可以与其他SaaS服务定价一致. Likewise, 通过准备好故障, 在api和应用程序方面，更容易考虑更具创造性的定价 microservices. 该模型支持可能来自客户的需求，即“只要给我数据，我就会将其合并到我自己的UI中。.”

请放心，随着产品系列的增长, sales, 解决方案工程师和客户都希望将新服务的定价与旧服务进行比较. 有一个定价结构将简化头寸和建议.

在你确定价格之前，回头看看你们的毛利率. Predict what the impact of growth 将增加您的运营成本(特别是对于SaaS模型), 并确保你在公司的财务目标之内.

第4部分:定价模式的灵活性

以一种创造逻辑的专业精神来对待定价策略, 经得起时间考验的可重复使用定价. 准备好采用新的定价方法，新的定价方法. 快速调整价格的能力将使该公司相对于竞争对手具有战略优势.

相应地设计软件，以捕获和报告适合当前和潜在服务产品的逻辑仪表.

Conclusion

在为软件产品定价时，构建一个易于解释的方法. 确定可以测量和审计的定价策略的逻辑度量. 为报告和审计设计平台，并期望定价表发生变化. 如果做对了，交易台就可以处理大多数销售机会，而不必回来为每个例外情况协商价格.