saas平台arr计算举例(saas iaas)

saas iaas

由阿里云大型服务器群、高速网络、存储系统等组成IaaS架构提供基础服务；将阿里云提供的RDS、MQ等服务构建在IaaS层上；这些RDS、MQ提供的服务组成PaaS，把视频的应用逻辑（如视频编解码、视频流接入等）部署上来，提供在线的视频点播、直播等服务。

这样一个大型的系统对互联网用户而言，就是一个大规模视频类SaaS应用。

saas arr mrr

销售arr指标是年度经常性收入的指标。是saas或订阅业务使用的关键指标，将定期订阅的合同经常性收入部分规范化为一年期的价值。

ARR/MRR是SaaS企业衡量业务运营情况非常重要的一个指标，也是管理层基于当期SaaS业务进展的财务结果，对未来一段时间进行预测和判断。

saas的arr

年度经常性收入指标。ARR是年度经常性收入指标。ARR指标常常适用于saas或订阅业务,该指标能够反映定期订立的合同经常性收入部分规范化为一年期的价值。

因此,arr指标主要是适用一年期及以上的协议,因为期限越长,价值判断会更加客观清晰。

在中国,GDP指标被看作是衡量一个国家或地区的经济发展状况的指标,反映人们的收入水平状况等。

saas iaas paas

IaaS，基础设施即服务，比如阿里云的ECS云主机。PaaS，平台即服务，比如网易有即时消息服务接口。DaaS，一种说法是桌面即服务，比如亚马逊的桌面服务。SaaS，软件即服务，比如Evernote，Salesforce这些。

saas arr计算公式

SaaS的收入模型至少可以分为以下四种。

1.纯自动化的订阅收入模型

所谓纯自动化的订阅收入模式，即SaaS交付之后的运行不再需要人工介入，而是由软件自动化提供，即“SaaS收入=软件产生的收入”。这是一种理想的收入模式，由于CTS大大降低，所以这种收入模式的盈利能力强，不受服务水平的影响。

如果有可能，SaaS业务设计应尽量支持这种收入模式。订阅模式的优势是有更好的收入可预测性，就是说未来ARR是可预测的。但是这也有一个重要的前提，为了使订阅模式成立，需要保证订阅用户持续付费，也就是尽可能保证客户不流失。

如果SaaS业务依赖纯粹的订阅模式，客户一旦断约，将导致无法预测收入，还会造成续费损失。

2.自动化+人工服务的订阅收入模式

这种收入模式仍然属于订阅模式，只是收入的结构中由两部分组成，即“SaaS收入=软件产生的收入+人工服务产生的收入”。显然，与纯自动化的订阅模式相比，这种模式的一部分收入受到人工服务能力的限制。除了增加CTS外，效率也会受到人工因素的影响。

关键问题是，这种SaaS模式的复制能力较差，这是因为需要合格的人工服务资源，比如一个SaaS数据分析业务，多数情况下需要数据和算法工程师的配合，才能为客户提供数据服务。

如果收入结构中的人工服务收入占比过高，所产生的效率问题会使复制能力受到限制，导致盈利能力的降低。

3.混合收入模式

与完全订阅模式不同，在混合收入模式下：SaaS收入=订阅收入+其他收入。比如电商SaaS除了固定的店铺服务费（订阅）之外，还包括流量费、交易费、交易提成等非订阅收入。

如果订阅收入占比太小，收入的可预测性就会变差。这种混合收入模式在国内很流行，因为订阅收入占比小，所以更抗客户流失，这就可以不受订阅模式回款周期的限制，集中力量把其他收入做大，国内SaaS概念的上市公司大多是这种模式。

但这并不能说明混合收入模式一定是健康的。实际上，这种模式的风险比较大，因为其他收入不可控。特别是当其他收入占比较大时，如果业务模式不能形成稳定的其他收入，整个营收随时可能滑坡，使收益变得不稳定。

4.类SaaS收入模式

所谓类SaaS收入模式，是指除了服务平台架构是SaaS技术模式外，订阅收入的占比为0。也就是说，所有收入都是“其他收入”。类SaaS收入模式的形式很像订阅收入模式，商业模式是通过业务拓展（Bussiness Development，BD）开发客户，之后依靠客户持续复购取得收入。

虽然达不到订阅收入那么准确的预测，但收入曲线与订阅模式相似；虽然没有CTS，但为了维持客户的复购，BD的服务也是有成本的。

saas ai

1，自身培养和运营流量，

2，为各种经营流量的B端或A端提供不同层级的数据科技服务。

3，逐步形成自身对不同类型的流量的保险产品变现能力

以下是围绕这几个方向最近正在做的一些事情

一， 自身培养和运营流量。

1）在京东平台上引入互助的概念， 和相互保险公司合作设计保险元素的互助产品， 形成互助亚文化。目前进展：和众惠合作，已经和监管沟通多次， 完成产品形态的确认， 已经开始准备材料，报监管各部门会签

2）针对政府的医疗健康项目，合作搭建流量平台。 与当地政府合作，就医疗服务、健康服务、保险服务，搭建系统平台，通过各类服务分成获取收入， 重点是通过搭建平台和政府的C端海量人群对接， 形成流量平台。 目前进展：济南、宿迁，以城市计算牵头签署协议，落地中。阜阳洽谈中。山东和浪潮集团正在准备合同签约，随后将进场开发保险产品。

3）针对微信生态，选择合适的合作伙伴，联合特定文化或人群的流量平台，逐步形成公益-保障的京东品牌， 培养京东保险的公信力。

a、与工银安盛、防癌慈善机构合作用户教育微信传播产品，通过线上线下合作，推广健康防癌等健康理念，逐步形成防癌早查的公益品牌。

b、针对残障儿童群体，与中信保诚合作，设计父母身故后的生存保障产品，通过线下渠道配合微信传播产品， 打造京东公益的品牌。

4）针对京东生态设计京东商城相关保险

a、创新产品挖掘：生理年龄保险，趣减龄，Remark带动的合作，同时撬动光大银行信用卡用户

b、深度商城类目需求挖掘：在商城类目类开发类似隐形眼镜退货险之类的产品，抓住客户痛点，逐步对之前运费退货无法覆盖的三类医疗产品目录进行深度切入。

c、社交属性产品设计：以少儿年金为底层的少存钱罐产品。

二， 面对流量去中心化的趋势， 通过自身对不同类型的流量的保险产品变现能力，为各种经营流量的B端或A端提供不同层级的数据科技服务。

1）面向保险行业的流量合作 ，针对保险公司的自身痛点， 设计相应的产品和业务模式， 服务保险公司的业务价值链条中的需求。

a、车险流失客户赢回， 与中华联等财险公司合作，对方提供车险流失客户，我们撞库得出客户信息，返回给合作财险呼叫成交。目前进展：已经形成商业模式，并过公司内部合规风控， 开始准备协议签署阶段。

b、团体货车车险分期项目，实质是保险公司的流量在汽车金融领域的再变现。 与人保、太保、平安落地签约中，试单与流程优化中

c、寿险公司 数据电销：针对京东客户，与大都会、华夏等寿险公司联合，设计不同特征数据标签，通过电销营销寿险产品。目前进展：模式已完成合规、法务审核，正在制定话术、挑选产品、协议签署中。

d、为鼎鼎保代和天津津投设计相关产品， 提供相应出单平台。

2）面向三方平台的合作， 从与保险相关的互助类的大流量平台开始，设计专属险种。 逐步推广到其他第三方流量平台， 提供产品的开发设计、数据建模、风控、服务等方面的合作。

a、针对水滴3000万会员，根据其平台用户特征，对客户进行分层标签，相应设计重疾保险，初步设计一款分级核保分级赔付产品，亚太财险承接。目前进展：已完成初步撞库和协议签署，进入数据建模阶段

b、针对必互个人会员提供续费优化智能呼叫服务， 针对必互20万代理人设计智能保顾服务。 目前进展：服务设计与协议中。

C、对特定人群的流量平台，开始逐步赋能产品出单能力，并针对性的进行相应产品的设计。如伊宿租房，目前进展：已经上线小京保SAAS平台，完成产品设计，正在研发对接。

三， 打造全价值链条的保险赋能服务，价值链体系包括流量平台出单能力、产品设计，大数据挖掘，建模、风控、产品定价和设计、反欺诈、平台和客户运营等方面的服务。

1）保险分销SAAS平台：针对有线下销售队伍、线上流量的平台的分销平台建立

目前进展：小京保预计8月3日完成监管报备，目前已上线车险、全球医疗、健康险三款，入驻1000余人，开始试单跑流程。

2）底层服务能力建设：针对有人身险销售场景的各类B端平台，做人身险的人工智能知识库

目前进展：针对定期寿已推出第一版试用，接下来在重疾险、终身寿等复杂产品开始解构语义。

3）直接和再保险公司合作， 在创新产品和特定客群类产品进行定制化开发。

和中再设计包括糖尿病产品之类的健康险产品， 和美国再设计持续小额提额的健康险产品，等等， 目前进展：这些产品已经在设计、有的在直保公司落地、产品报备阶段。

4)延保产品设计 商城车后设计配件延保，机油、电瓶、轮胎延保产品设计，车后以集采方式成交；延保公司汽车的核心部件延保产品设计

saas aas

PaaS (Platform as a Service) 与 SaaS (Software as a Service) 是云计算中两种不同的服务模型，具有以下区别：1. 目标用户不同：PaaS主要面向开发人员，提供开发平台和工具，使得开发者可以快速构建和部署应用；SaaS则面向终端用户，直接提供软件应用程序和服务。2. 管理责任不同：PaaS服务提供商通常负责维护软件平台的基础设施和比较安全性，而开发人员应负责应用的开发、测试和部署；SaaS服务提供商则提供完整的软件解决方案，包括维护、升级、备份和比较安全性。3. 可定制性不同：PaaS用户可以在开发平台上自行部署和配置应用程序，可获得更高的自由度和可定制性；而SaaS服务通常由供应商统一配置和管理，用户只能在所提供的范围内使用。4. 部署方式不同：PaaS主要通过云服务的方式，提供开发、测试、部署和托管等服务；SaaS则更多地使用基于浏览器的网络方式提供应用程序和服务。总的来说，PaaS更侧重于提供一个编写、测试和部署应用程序的平台，SaaS更侧重于提供一个已构建好的应用程序和服务。

saas api

pass层

Pass 层细分为三层，基础服务层，主要负责数据存储处理；事务框架层，主要负责微服务的注册·调度管理、分布式事务处理；应用服务层、主要实现各个微服务的 API，供其它微服务直接调用以及 Saas 层的服务调用。Saas 服务就是公开对外提供的业务服务。

saas层

PaaS层：可以理解为平台层，通俗意义上的后台，或者是阿里提的中台，就在这里。

SaaS层：可以理解为用户层。用户看到的和使用的东西，web网页、APP、报表等。