很多小程序开发公司都可以开发支付宝小程序；
对于商家来说，小程序开发的成本是重要的考量标准，毕竟之所以外包，除了技术限制外，节约研发成本也是初衷之一。当然价格也不是越低越好，所有的开发公司都需要承担相应的运营和开发成本，如果对方报价比同行要低很多，则势必开发公司会从其他方面缩减成本，如果因此影响小程序的开发进度或功能效果，那就得不偿失了。
所以，在选择开发外包公司时，尽量选择几家不同档次，不同价位的开发公司进行对比，结合小程序开发的功能、页面和价格等因素综合考虑，选择出性价比较高的一家。
移动营销服务中心开发的支付宝小程序已经上线了，可以找他们
本回答由提问者推荐
目前数动力是国内少数实现视频、音频、分销和会员、拼团秒杀功能的小程序开发商！ ...
现在互联网产品应该不区分区域的，全国的互联网公司应该都会卖这个小程序的！
微商城定制开发的工期一般要看你的APP开发复杂程度和开发公司有多少技术员在开发，像互联在线一个拥有300人的研发团队来说，开发一个APP大概是两周左右，其实要说哪家好的话，需要注重三点。1、这家微商城开发公司的技术团队，投入人多的进去开发的话当然快了，不过对于公司来说人工成本就高了。
2、微商城的质量，质量又包括微商城的设计水平，市场上普遍的微商城开发公司都是用一个模板套上去，然后修改下数据就可以用了，缺乏创新。还有就是微商城的性能是否稳定，有没有BUG。
3、微商城的售后，售后这个要非常重视的，这家微商城开发公司是否对你的微商城定期进行例行维护，升级，以保证你的微商城优秀的用户体验等。
我们公司制作的APP是一个叫【中圈信息科技】的公司做得，跟别的公司做得不一样，很有特色，服务也很好，他们好像是一个集团，不像有些小工作室，大公司也比较值得信赖
作者 | 蔡芳芳
采访嘉宾 | OpenSumi 项目组
经过近三年的研发和内部应用场景打磨，由阿里集团和蚂蚁集团共同打造的 IDE 研发框架 OpenSumi 于近日正式对外开源，采用目前使用较广泛的 MIT 宽松许可协议。
项⽬地址：
官⽹地址：
OpenSumi 是一款面向垂直领域，低门槛、高性能、高定制性的双端（Web 及 Electron）IDE 研发框架，基于 TypeScript+React 进行编码，实现了包含资源管理器、编辑器、调试、Git ⾯板、搜索⾯板等核⼼功能模块。开发者只要基于起步项⽬进⾏简单配置，就可以快速搭建属于⾃⼰的本地或云端 IDE 产品。
框架⾃身兼容 VS Code 插件⽣态，主流 VS Code 插件均可⽆缝在基于 OpenSumi 研发的产品中运⾏。同时，OpenSumi 为开发者提供了多种低成本、⾼定制的视图定制能⼒，能满⾜ IDE 场景下绝⼤多数视图定制场景。
IDE 产品的研发一直以来都是一件门槛高、费时费力的事情，OpenSumi 项目组希望通过开源 OpenSumi 帮助对 IDE 有兴趣的开发者更好地了解并掌握 IDE 研发这项技术，让更多的开发者可以以一种低门槛的方式去研发自己的 IDE 产品。同时，通过社区中开发者的使用，也可以帮助 OpenSumi 更好地改进，获得更多的需求场景输入，同时通过社区影响力让框架获得更加长远的发展。
由于各种原因，开发者群体中不乏质疑阿里、蚂蚁开源是 KPI 项目的声音，一些项目开源出来后可能很快就消亡了，如何保证 OpenSumi 不会走上同样的道路呢？
对此 OpenSumi 项目组回应表示，开源项目能持续下去最重要的是保证项目的价值，这才是持续吸引开发者来共建和使用的核心原因；其次是开放治理 Open Governance，让外部贡献者也能在公开透明的治理结构里参与项目的关键决策，让 OpenSumi 成为不是阿里、蚂蚁两家公司在做的开源项目。
“开源初期我们便把所有核心代码一次性开放到了开源仓库中。得益于 OpenSumi 极强的拓展性，我们内外部的许多核心产品在今年 1 月份已经完成了从内部依赖切换到开源依赖的工作，不再区分内部版本和外部版本。我们希望通过这种方式，一定程度上帮助 OpenSumi 在开源社区中持续发展下去，慢慢从内部的一个开源框架发展成为开源社区中能让大家广泛接受的 IDE 研发框架。”
OpenSumi 的架构及特性整体架构为了保证框架可以同时在 Web 和 Electron 环境下运行，OpenSumi 采用了一套前后端分离、通过抽象的通信层进行相互调用的项目结构。
在 Web 上使用 WebSocket 作为通信的实现，在 Electron 上则是 IPC 通信。每一个通信的连接对应前后端一个独立的 DI (Dependence Inject) 容器，所以 OpenSumi 的后端实现是无状态的，不同连接之间严格隔离。
OpenSumi 内主要有三个核心进程：插件进程 （Extension Process）、后端进程 （Node Process）和前端进程 （Browser Process）。
为了保证插件的问题不会影响 IDE 的性能表现，插件能力上 OpenSumi 采用了跟 VS Code 类似的方案，通过独立的插件进程去启动插件，插件进程再通过后端进程与前端进程通信。
OpenSumi 的不同能力实现被拆分到了不同的模块内，这些模块通过 贡献点机制 (Contribution Point)、DI 机制 (Dependence Inject) 互相之间有较弱的依赖关系，对于一些比较核心的基础模块，如主题服务、布局服务等，也会被其他模块直接依赖。因此，在集成开发过程中需要保证一些模块的引入顺序。
整体启动的生命周期如下图所示：
关于 OpenSumi 模块和插件的更多介绍，详见：
主要特性和应用情况目前研发 IDE 的主流框架包括 code-server 和 Theia，在性能和编码体验上 OpenSumi 与主流框架相近，OpenSumi 相较于主流框架的优势主要在于两点，即更强的视图可定制能力、更友好的集成手段和丰富的场景案例。
基于 OpenSumi 的基础框架，开发者可以自由地通过模块或插件定制自己的 IDE 产品，实现真正意义上的“全视图定制”能力。
在许多内部产品实现阶段，会通过模块实现基础能力以得到更好的可维护性，而通过插件实现业务上的视图或能力定制，则可以实现更好的定制性。以阿里内部的部分研发场景为例，结构分层如下：
另外，OpenSumi 在设计之初就确定要兼容 VS Code 插件生态，因此对框架会有持续性的要求，开源后团队计划每三个月完成⼀次 VS Code 插件 API 的适配⼯作，适配计划的制定将会由相应的版本管理⼈员组织在讨论区进⾏，当前已适配⾄ VS Code v1.60.0 版本标准 API， 进度可⻅适配计划。 相比之下，Theia 框架虽然兼容了一部分 VS Code 插件能力，但对于后续 VS Code API 的兼容已经越来越少，基本依赖社区开发者自发贡献。
在应用场景方面，OpenSumi 在正式对外开源之前，已经在阿里集团和蚂蚁集团内部持续孵化超过两年，期间沉淀落地了一系列具有代表意义的垂直领域下的研发案例。因此大部分能想到的研发实践场景，可能都可以在 OpenSumi 中找到实践经验。
按照不同的应用场景划分，下面 OpenSumi 目前的内部应用实践部分案例：
在本地客户端场景中，以小程序研发为例，支付宝小程序开发者工具、淘宝小程序开发者工具都使用了 OpenSumi 作为核心框架实现，截至目前，外部月活用户已达到 1.9 W+；在云端研发场景则有阿里云外部的云开发平台、阿里内部的 O2 研发平台、蚂蚁内部的 Ant Codespaces 等，累计月活已达到 2W +；纯前端搭建能⼒是 OpenSumi 在阿⾥及蚂蚁集团内应⽤的最为⼴泛的⼀块能⼒，它提供了⼀种不需要依赖服务端提供编辑器启动所需的 Node.js 服务，而可以直接通过纯前端资源及静态接⼝定义搭建⼀个具备编辑器基本界⾯的能⼒。在纯前端场景中，蚂蚁内部的 AntCode、阿里内部的 O2 CodeReview 平台都是通过 OpenSumi 提供的纯前端能力搭建了代码评审平台，而内部的 Riddle 和 O2 Sandbox 平台则是通过纯前端的能力，搭建了基于前端依赖构建的代码片段分享平台；同时，阿里内部的 Aone IDE 研发中台也能为开发者提供一个无后端环境下可用的研发接口，通过平台上通用的配置，开发者基于前端技术栈就能完成云端 IDE 的研发工作。开发者面对主流框架和 OpenSumi 该如何选择？OpenSumi 项目组建议，可以先简单了解一下各个框架所能解决的具体需求场景。OpenSumi 的核心优势是视图定制上的能力以及不输于主流框架的编码体验，如果对于视图有较强的定制需求，则可以尝试使用 OpenSumi 进行搭建。同时，对于中文开发者来说，选择 OpenSumi 可以一定程度上减少沟通及集成过程中的障碍，尽情参与到 OpenSumi 后续的开发及讨论之中。
历经近三年研发OpenSumi 是由阿⾥集团淘系⼯程团队及蚂蚁集团体验技术部、研发效能团队联合发起、共同研发的 IDE 标准化研发框架，早期在内部使用的名称是 KAITIAN（开天）。在准备开源时，考虑到 KAITIAN（开天）这个名称在国内外已经被大量公司进行了商标注册，为了避免后续由于名称引发一系列侵权问题，内部反复讨论后改成了 OpenSumi 这个新名称。
对于 IDE 研发，市⾯上早就已经有 code-server、Theia 等现成的开源⽅案，为什么当初还要选择⾃研实现一套新框架？一方面，随着阿里及蚂蚁集团内部对 IDE 产品的研发需求日益增长，各个团队在使用开源方案的实践过程中都或多或少遇到了一些问题，如定制能力有限、源码依赖深、维护困难、无法满足内部能力需求等。另一方面，阿⾥及蚂蚁集团内部有许多 IDE 产品，⼤部分 IDE 产品的前期建设⼤抵相同，但这部分前期建设⼯作的经验无法有效沉淀，存在大量重复劳动问题。为了解决这些问题，大家才决⼼集合多个团队的⼒量⾛上⾃研实现的道路。
OpenSumi 项目启动于 2019 年 5 月 8 日，在过去近三年时间里，从初见雏形的 1.0 版本，进阶到了大量应用的 2.0 版本。整体研发历程可以总结为以下三个阶段：
第一阶段：前期建设与核心业务落地。在立项之初，三个团队的研发同学进行了为期一年时间的闭关，目标是通过自主研发的框架承接内部三个较为重要的基础业务，包括蚂蚁的云端编码产品 Ant Codespaces、支付宝小程序开发者工具、淘系工程团队的云端编码产品 O2。在这个阶段，团队的重点工作是完善框架基础能力，以满足原有产品的能力及功能体验。截止闭关结束，共计迭代 67 个版本，实现了对 VSCode 1.37.1 标准 API 88.9%覆盖，发布了 OpenSumi 的 1.0.0 版本。第二阶段：业务落地及多场景验证。在完成 OpenSumi 的 1.0.0 建设工作后，团队开始在公司内部推广框架，进一步完善框架在更多场景和业务中的适用性，完成了纯前端能力、VSCode 1.44.0 标准 API 100% 覆盖、基础性能及体验优化等建设，在更多场景中完成了业务落地，如月服务开发者数量已达到 2W + 的小程序场景、月用户数达到 1.9 W + 的云端编码场景、IDE 研发中台、代码 CodeReview 平台、代码片段平台、场景化的本地研发客户端等。2021 年 3 月，OpenSumi 发布 2.0.0 版本，摒弃了一些不合理的设计，框架更加精简，性能及交互体验都有了大幅提升。第三阶段：内外部开源。经历了两年的能力建设之后，考虑到国内并没有一款真正由国内企业或团队研发的 IDE 框架，另外在国内的开源环境下，想做好开源势必要提前做好相关准备，尽管原来代码就都是内部可见的，但团队还是在 21 年 的 4 月份启动了内部开源，加大了在内部代码分享平台上的宣传及建设，期间吸收了更多感兴趣的团队加入到了 OpenSumi 的代码建设工作中。2021 年 9 月份团队开始了开源建设工作，将工作流程及内容完全迁移到了外部，并完成了内部核心产品的依赖替换，后续将会持续在开源社区中完善好周边及基础能力建设。在自研框架 OpenSumi 落地到内部 IDE 产品研发后，过去困扰大家的大部分问题都得到了比较有效的解决。比如对于定制能力有限的问题，OpenSumi 通过模块 + 插件的方式开放了全视图定制能力；对于源码依赖深的问题，OpenSumi 通过模块管理依赖，项目结构清晰，大部分模块均为 “可插拔” 模式，需要时引入，不需要时也可以不引入。
对于如何搭建一个 IDE 产品，团队也沉淀了丰富的快速开始案例及集成案例，开发者可以基于内部基建能力快速搭建自己的 IDE，不再像以前需要从一个简单的案例去盲人摸象式地探索完成后续需求研发工作。同时，为了满足内部能力需求，团队通过定期的月会机制收集各业务方需求，再通过进一步的需求抽象及逻辑剥离，将公共的能力沉淀在了框架之中，从而实现能力可复用。
前端 IDE 发展的下一步OpenSumi 开源只是团队迈出的⼀⼩步，后续还有大量工作需要继续推进。目前 OpenSumi 每两到三周会进行一次迭代发布任务，由版本管理员统一维护合入相关功能及问题修复等内容。每次迭代过程中都会安排两名 “版本校验员” 进⾏版本检验，在测试通过后，才会升级⼀ 位 minor 版本后发布。团队将会持续性保证最新的两个 minor 版本的有效性，即 “如果发现了影响功能的问题，会向最新的两个 minor 版本同步修复，发布 patch 版本 ”。版本示意如图所示：
以 2022 年 1 ⽉份的迭代计划为例，OpenSumi 版本发布的计划可⻅：Iteration Plan for v2.14.0
当前 OpenSumi 2022 年的 Roadmap 也已经有了初步雏形，⻅ OpenSumi 2022 Roadmap，后续会根据社区反馈及讨论在 2-3 ⽉份正式确定。接下来团队会持续性地完成 VS Code API 的适配、编码/调试体验优化、性能优化等⼯作，同时积极收集社区中反馈的功能需求，以双周迭代的⽅式选择性吸收进框架计划中。
同时，OpenSumi 也有⼀些基础的⻓期⽬标，如下图所示：
前端 IDE 是阿里集团和蚂蚁集团从 2019 年开始就持续重点强调的一个核心技术方向。在 2019 年的 GMTC 全球大前端技术大会上，当时的前端委员会主席圆心在分享《前端路上的思考》中表示，期望通过 IDE 将前端工程领域中研发态与流程态进行整合联通，同时通过插件能力将阿里体系内外的研发模式、能力进行打通，形成生态能力发挥价值。而在 2020 年 12 月举办的 QCon 全球软件开发大会（深圳站）上，阿里巴巴前端技术专家张伟（上坡）在分享《基于 KAITIAN 的前端工程研发模式变革》中表示，KAITIAN 就是面向前述问题的答案。另外，蚂蚁云研发团队工程师王兴龙（蛋总）在 2022 SEE Conf 上也分享了《云原生架构下蚂蚁 Cloud IDE 的应用实践》，讲述了 Ant Codespaces 如何利用 OpenSumi 适配其双容器架构。
这次 OpenSumi 正式开源，意味着阿里集团和蚂蚁集团在前端 IDE 方向的发展进入了一个新阶段。
相比刚开始研发 OpenSumi 的时候，如今团队对于前端 IDE 的发展现状和未来趋势也有了一些新思考。
在 OpenSumi 项目组看来，IDE 的发展依旧离不开业务发展，IDE 的发展趋势一定程度上也可以从业务的发展趋势中窥见一斑。这两年发展比较迅速的 Serverless 未来在 IDE 领域上就有不少结合的可能性，比如提供给前端开发者搭建无后端的 IDE 应用，实现一些轻量的场景需求。同时，IDE 在一部分轻量编码场景下也有不少需求，未来的 IDE 研发可能不单单仅限于完整的一个 IDE 产品的研发，如嵌入网页中的轻量友好的代码编辑器、服务于低代码的可视化编辑器等，未来 IDE 的发展依旧会紧贴业务并为业务服务。
而从大环境看，目前依然没有一个 IDE 可以完全覆盖所有的业务领域，只在某个行业中会有一个比较流行的 IDE，因此 IDE 未来的发展趋势依然是着力于某个特定领域的精细化加工，未来 IDE 研发依旧会继续往更强的定制性、更友好轻量的集成体验上发展。可能未来的某天，会出现这样一个平台，能够根据开发者的需求，自动选择需要的模块及对应服务后为开发者提供一个云端的 IDE 工作空间，那时候可能会真正迎来 IDE “井喷” 的时代。
编辑导语：7月21日，支付宝在杭州举办了2022年合作伙伴大会，会上披露了过去一年支付宝的开放数据，以及与合作伙伴共创的场景解决方案等。在会上，支付宝生态产品总经理陈先达还分享了自身对支付宝生态产品发布的行动和思考，一起来看一下吧。
自确立「去中心化为主、中心化为辅」的开放原则以来，支付宝开放也逐步提速。7月21日，支付宝2022年合作伙伴大会在杭州举办，会上披露了过去一年支付宝的开放数据，累计开放平台通用产品78个；与合作伙伴共创场景解决方案超200个；小程序月活提升近3成。
值得注意的是，支付宝生态产品总经理陈先达在会上分享了自身对支付宝生态产品发布的行动和思考。以下是其现场演讲内容全文。
孙武：在持续开放的道路上，我们收到了大量商家以及合作伙伴给我们宝贵的建议，这些宝贵的建议中不乏一些“刺耳”的声音，在这里，我首先非常感谢大家对我们支付宝产品的包容，正是因为有这些真诚的声音也一直驱动着整个产品体系往前去更好地努力变化。
01 做好生态产品的三大关键原则在做基建以及建私域的各个开放的过程当中，我们一直在思考怎么将支付宝这个复杂的系统以及更好的产品方式开放给生态。通过一段时间实践下来，我们发现如果要做好生态产品，有三个方面是非常重要的。
第一，分类要清晰。分类背后本质是一个抽象与表达，我们怎么基于每个业务领域做好更好的领域模型抽象，同时能很好地表达给客户，在表达层面生态产品有其复杂性，同时会面对消费者，面向商家，面向合作伙伴，以及开发者，不同的角色会带来其复杂性。
原子可重组：原子化背后其实是要内聚，要有边界，内聚比较好理解，要基于这个模型形成一个高内聚低耦合。边界对应的就是让这个产品能力要具备很好的可扩展的设计能力，希望我们的产品以原子的方式被集成到各个行业解决方案当中。接口好集成：如果产品只能以一种方式开放给生态，我们希望是接口，我们希望产品能力可被集成到客户系统产生更大价值为核心目标，由此产品所对应的接口文档、调试环境以及工具不应以配套的方式存在，应该成为产品的核心组成部分。02 4个升级与1个发布：产品迭代创新里的服务升级今天大会上介绍了支付宝C-care模型。其实它不只是商家在支付宝上做精细化用户运营的模型，它背后有一整套产品体系进行支撑。
过往我们也跟大量的商家以及合作伙伴做过交流，大家都普遍会好奇一个问题，我们怎么在支付宝平台上去扩大用户规模，提升活跃，以及去发挥我们的潜在价值，提升经营效率。
今天，我也会跟大家谈一谈大家普遍关心的几个产品，小程序、公域推广、生活号以及商家券，还有一个全新的产品棋盘密云。
1. 小程序首先是小程序。很多人经常问我的一个问题，来支付宝做数字化经营到底有哪些步骤？其实非常简单，三步线上线下联动，五步可以让老客常来。
第一步，一个小程序承接服务；第二步，线下宣发小程序码物料完成线下到店客流散发到小程序；第三步，搭配搜索，线上通过支付宝的搜索来找到服务；第四步，长在首页的“我的小程序”给了我们更多可能，它成为用户直达服务最便捷的路径，你引导用户收藏就可以让你的服务在首页就被用户直达。加上消息功能，可以成为非常好的召回手段来辅助商家经营。
小程序勾联的每个产品能力，都能为商家经营服务。
1）搜索
搜索的使用通过一段时间的持续打磨，开放的能力已经变得非常之简单了，我们可以从一个“基础”到“进阶”两方面来看。
基础功能：如果你想让你的服务在搜索里边能出现，关键词下挂一个服务就可以直达小程序，如果还想更进一步可以将消费券关联在上面，有更多的曝光引导用户来使用你的服务。进阶能力：在过去的一段时间内，我们也将搜索里边直达能力更具开放，原来的直达品牌专区只对品牌商开放，现在我们向普通的小程序也完全开放小程序直达能力，这个BOX不仅提供直达能力，我们也提供大量丰富的装修能力，可以将视频、活动以及各种券的内容组合到BOX里边，可以带来更好的营销效果。2）“我的小程序”
位置已经决定了它给我们提供服务使用的一个最短的路径，通过我的小程序带来的整个转化可以对你的服务有一个非常好的倍增效应。
怎么去享受到这个服务能力？你可以在小程序内外分别来做引导收藏，在小程序外，我们可以将收藏组件内嵌到支付成功页各个场去引导用户收藏，在小程序内部，可以基于渠道、页面，来做智能引导，甚至可以做非常好的场景引导，让喜欢你的用户收藏你的小程序。
3）消息
消息能力已经全面对生态开放。在支付宝生态内，大致可以分为三类。
订单消息：它可以带来非常好的便捷的履约提醒的访问效果，他接入整个订单也相对比较简单，你只要基于API接入订单中心就可以实现让你每个履约过程的状态节点及时反馈给用户，做必要的提醒。订阅消息：它是基于用户主动选择而产生的订阅行为，消息质量变得非常之关键，我们希望生态及合作伙伴用好这个订阅消息，与此同时，我们会对营销诱导类消息做严格控制。支付消息：我们完全将以往支付助手平台的运营空间释放给生态，让每个商家基于你的支付就可以绑定对应的小程序，也可以带来更多的可能性。2. 公域推广在看完整个小程序介绍，接下来重点谈一下公域推广。
谈到“公域”，我相信有一句话非常之应景，对支付宝的公域，每个人心中都有一个“哈姆雷特”，我也听过非常多的伙伴给我们反馈，有些人会觉得支付宝的公域只向KA开放，支付宝的公域只面向于定向行业，或是我是一个小微商家，我怎么能参加支付宝的公域……
这些问题其实非常鲜明地表达出支付宝公域的特点——多样与复杂。
支付宝的公域有会员频道，有支付成功页，也有首页，甚至有消费券的频道，这个多样性其实给我们带来了与之对应的复杂性，背后每个频道每个流量都用户产生了不一样的行为，怎样开放这个能力，这是过往一段时间内，一直在践行与努力的过程。
我们大概的的策略会“成熟一个，开放一个”，但同时我们会优先将最关键的流量位开放出来，比如首页成为第一批的对象，我们将Feeds优先开放给生态，通过这一段时间的努力，将公域流量的形态抽象为基于时间是否付费，以及效果各个维度定义成不同的产品，可供商家选择。
基于每一种形态，我们可以怎么来参加？首先是日常推广，对于整个日常推广，如果我用三个词来总结，第一是门槛低，只要你有一个小程序就有机会参加整个公域推广；第二确定性，我们开放一系列具备流量确定的场域，当前已经将首页，消费券频道，搜索推荐位以及支付成功页已经全面向生态开放；第三是流量机制，它从完全采用一个竞争机制采用优胜劣汰，如果你有好的小程序就有机会得到更多的曝光。
相对有鲜明对比的，是激励与商业化。这一块的特点差异性较大，它有两个核心特点，第一是它可以基于定向人群来做推广，第二是它可以基于定制方案做推广，定向人群与定制方案，我们将数十万的人群标签开放给大家，同时我们也可以基于你需要去转化的目标来定制对应的方案，我们也将繁星计划得到的点数在整个激励与商业化当中来直接投放。
整个公域推广走到今天，我们基本上已经将产品体系的稳固结构确定下来了，在往后我们将大量的场复制到这些结构当中去，让生态合作伙伴以及商家全面拥抱支付宝的公域流量。
3. 生活号在有了大量的用户以后，相信大家都会考虑一个问题，我怎么让用户变得更活跃？
一方面，我们的商家要去经营客群关系，去运营用户资产，同时还希望去强化私域运营。此刻，生活号可以成为大家的一个选择，在过去的一段时间内，生活号在内容互动方向进行了升级，你通过整个种草，你可以去打造品牌故事，去传递服务价值；你也可以基于内容种草，去做场景植入，激发用户的诉求。
有了种草以后相信肯定会带来一系列粉丝的沉淀，我们提供了一系列的互动组件帮你去活跃粉丝，从原先的生活号单向的营销消息触达的方式变为双向内容互动，也可以让我们整个粉丝互动的效果变得更好。
最后，我们还提供直播能力，让直播这个及时性的爆发让你做促销，做导购，都可以带来更好的效果的变化。
我们来看一下这些能力可以怎么用，首先我们让生活号的能力从原来的短图文与长图文的创作方式升级为支持短视频与直播，同时，我们的短视频与直播全面跟小程序打通，从种草到服务交易转化整条链路是全部相通的；
第二，我们的直播也跟对应的内容，刚才讲到整个直播，直播充分发挥支付宝能力特点的特色，直播可以与会员打通，直播可以与数字藏品以及红包做一定的结合，以整个会员为例，我们直播已经与会员登记打通，每个商家或品牌可以基于支付宝不同会员等级的用户来定制道具，在直播时就可以做到非常好的分层精细化运营。
沉淀：我们将整个内容组件变成一个组件化，可内嵌到各个场景中去，与支付宝前端做打通，比如内容现在可以与搜索的BOX打通，做搜索时就可以带来内容的曝光，内容就可以对应到你使用的服务。互通：同时，整个粉丝的关注组件可以与小程序打通，在小程序服务使用时也可以给内容带来流量。互动：另外，有了这些粉丝怎么变得活跃？我们开放了大量的组件能力，这些都是可以去增强互动的，这些互动的组件可以让你无缝地内嵌到各个内容中去，这都可以让你与粉丝之间有更好的活跃的保障。4. 商家券在全渠道运营时代，我们认为商家券将成为最重要的一个营销放大工具，基于这个判断我们做了一个非常重要的选择，支付宝从原来的支付券全面走向商家券，我们对原来的优惠券能力做了一个全面的重构，制、发、领、核，各个环节的能力全部可解耦，而且可以原子叠加，将原来支付券当中的平台控制预算，平台控制核销规则，全面开放给生态，由生态来完成全链路。
今天当下商家券已经可以非常好地与各种场景做结合，整个体系可分为三层。
第一层，商家可以不依赖于支付宝任何能力在自己的小程序里玩转商家券。
第二层，商家如果想更进一步与支付宝的各个私域场景产生联动，商家券的组件能力可以与支付成功页、卡包非常好地联动，你只要按需集成对应的接口就可以实现整个私域之间的联动，
第三层，如果还想跟公域产生更多的可能性，我们也可以将商家券同步给支付宝，提供一些素材，就可以参加整个全域的公域分发。
目前整个商家券的能力完全按照商家价值来选择，你需要什么能力，你要私域就叠加私域，你要叠加公域就叠加公域，什么不需要就玩转自己单家的商家券就行，我们希望将灵活度以及空间开放给生态，让没有一个合作伙伴基于你的价值来选择你要什么样的能力。
5. 棋盘密云在全渠道运营阶段，全用户资产怎么实现精准转化，我相信这是每一个商家都核心关心的问题。由此，我们打造了一个基于支付宝公私域精准营销的产品“棋盘密云”，有三方面的特点：
第一，它将依托于支付宝的小程序云为基础，同时将蚂蚁的可信隐私计算框架作为技术内核，让商家在密态中实现精准运营，这会相对比较抽象，我可以给大家从能力的层面来看一下，其实就是两层能力，在底层可以一起来共建一个可信的融合区，让数据基于密态中实现精准融合；有了精准融合以后，我们就可以结合上面的运营场景实现精细化的运营，你可以结合私域场景，也可以选择公域场景。
对于棋盘密云这个产品，我们现在还在跟一部分合作伙伴进行试点打磨当中，在不远的将来，我们将全面对生态开放。这个产品我们自己也有一个小小的期待，期望让每一个商家有一个自己的棋盘以后，在支付宝App内的全渠道的用户资产运营可以变得更精准。
03 分类与原子化：生态工作台需要注意的两个重点对于整个C-CARE模型，我们不只是提供这些，每个商家可以结合自己的经营阶段来选择对应你想要的整个产品。
对于整个C-CARE的产品矩阵中，我们还提供了其他更多的丰富能力，比如以支付结束页的支付有礼，它的能力已经被非常好的原子化，它可以与券、卡、小程序做很多的好的结合，这些能力都已经被我们大量的商家所应用到日常当中去。
有了这个C-CARE，对应这些产品能力，现在已全面发布在O站、P站以及B站，对于整个C-CARE的产品能力的介绍，第一部分基本到这里，第二块，我们同时会跟大家介绍一下针对开发者、服务商以及商家平台这几个站点做了一个比较大的升级。
在讲这个平台升级之前，我也跟大家先聊聊怎么做好一个站点，做好一个站点有两方面非常之重要。
第一是站点也要做好分类。在这上面，支付宝踩过的坑是不少的，我们原来的站点按用户的自然角色来分，一个人有企业，分个人，原来做成个人版与企业版，我们按业务来分布，比如小程序是一个站点，生活号是一个站点，某个行业是一个站点，这些我们都实践过，带来的问题也显而易见，今天当下一个好的分类，面向一个生态应该按客户的业务决策来分，现在我们会区分为面向开发者，面向合作伙伴，面向商家成为我们的一个选择。
第二是站点要实现原子化。这个“原子”应理解为让一个角色在一个站点里实现完整功能的闭环，如果一个人同时兼具两个角色，应该基于跨站点的动线来实现联动。对于产品而言，原子非常之重要。
我们打个比方感受一线，这些站点就像一个土地型产品，对于前面C-CARE的产品就像一个商铺型产品，如果你想做好一个商圈，底下的整个综合体，而且需要一致的设计理念以及二者之间能相辅相成，过往中产品的设计逻辑也一样，如何上面C-CARE的商业产品能力与平台产品能非常好地融合起来，前期是需要有相对一致的设计理念。
通过过往长时间的进行，这方面我们也让全局有了更多的共识，也让我们更有信心去做出更多好的产品来面向生态伙伴。接下来，来看一下每个站点到底升级了什么样的内容。
1. 开放平台（O站）开放平台全面以开发者为中心。
首先升级了应用频道，让开发者在一个应用频道内的每个应用类型实现他内部管理功能的一站式可发现，让文档、工具、API内聚到每一个应用频道当中。
面向生态伙伴，我们新增了第三方应用开发的方式，让合作伙伴更便捷地实现第三方开发。
有了应用频道再往下做应用的开发就必然会用到API，对于API能力是非常加强的重点，将API的调试过程做了全面的优化，让过程问题可以非常简单易懂的暴露给开发者，实现更好的开发体验，有不同的应用频道以及对应不同的API能力，怎么在一个工作台上实现统一的开发，我们对控制台做了优化，让开发者在我们的开放平台上的开发动线变得更顺畅。
2. 服务商平台（P站）面向合作伙伴，让代运营变得更顺畅是我们所优化的核心目的。
首先我们对于业务中心做了一个信息架构的升级，一个合作商来到我们站点，首先希望看看这里有哪些政策以及业务可以做合作，我们需要将这些东西非常清晰地表达给客户，我们将整个架构做了信息层面的升级。
同时我们新增了两个频道，一个是特约商户授权产品频道，。特约商户授权产品这很容易理解，我们需要站在合作伙伴的视角，怎么让他能更好地帮商家做代运营的核心逻辑。
一个是代运营中心，我们将前面所介绍的小程序的收藏、搜索以及营销工具，或是公域推广能力，让那些不想自己做代开发的合作伙伴能基于我们提供的功能直接完成代运营，对于服务商，我们希望他能基于我们这个平台成为一个补充的存在，我们更希望你的能力可以通过我们的API集成到自己的系统当中更好地去服务于你的客户。
3. 商家平台（B站）为了让商家更好地完成数字化经营，我们对整个动线进行了全面的升级。
首先是产品大全，我们让所有的产品能在再一个大全里完全可看到，也就是C-CARE所发布的产品能力可以在支付宝大全里找到。
有了这个入口的起点外我们怎么让这个能力被商家更便捷地管理，它对应的工作台就至关重要，一个商家会去做非常多的业务合作以及对应的内容，怎么做他定制的商业，这是我们想要满足他的诉求。
运营中心，我们新增了一系列的能力，让商家可以基于这一个频道完成完整的数字化运营原先运营中心基本只提供了支付相关的能力，现在将数字化相关的能力全部集成到这个频道，商家在一个运营中心基本可以完成私域运营，公域推广以及对应的营销工具的配置的所有功能。
前面讲了挺多的，最后我作为产品人，我讲讲自己的感受，前面我将场景、产品、站点介绍了，但这不是目的，不是我们做了一年跟大家发布一下，我们非常真心地希望将这些东西拿出来，能得到大家更好的一个建议以及反馈，在支付宝开放生态这条路上，我们虽然经历了做基建、建私域，现在在深化开放的阶段，但我们深知我们还处于一个非常初级的阶段，只有我们一起共同努力去探索，这个生态才有更多的可能性。
对于一个产品人来说，做好每一个产品必定离不开每一个客户，你们给了我们非常多的建议以及反馈，最后我想说一句，你们服务好客户，我服务好你们。
#专栏作家#井寻，微信公众号：井寻，人人都是产品经理专栏作家。前传统媒体记者，5年互联网一线品牌公关从业经验，人间赝品Kitsch、插一句主理人。关注领域电商、新消费、出行、教育、营销领域。
本文独家发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CCO协议
编辑导语：随着互联网技术的普及和不断发展，互联网医疗也走进越来越多人的生活，这篇文章从互联网医院的现状入手，多方面探讨了这一行业的诸多问题，一起来看看吧。
在互联网医疗领域，功能设计从来不是难点，非技术因素才是关键，在这里带着大家一起交流一下医疗领域的一些问题，行业里的人会比较很理解这几个字，行业外的人可能一头雾水。长期研究和观察中也发现了一些问题，在这里做一些分析，并且抛出来做一些探讨。
从互联网医院的现状开始，医院主导型和企业主导型的差异，从功能的角度、国家政策等展开分析，看到诊疗侧的产业图谱，回归的在线咨询商业模式、业务流程图、产品功能的设计… …
一、互联网医院现状简述大部分公立三甲医院对待互联网医院的态度：一个提供部分医院线上服务的入口，国家医疗信息化建设下最核心的一环，是一项长期的建设工作，疫情过后互联网医院的重要性上升了一大个等级。
1. 互联网医院的建设互联网医院仍在起步阶段，其建设和运营的过程比较复杂，涉及到了系统建设HIS、EMR、LIS、RIS、PACS等多套系统的协同，院内智能硬件设备升级，人员组织、流程梳理等多个细节的问题，很难一蹴而就，互联网医院将会是一个长期积累的过程。
1.1 系统建设
涉及到HIS、EMR、LIS、RIS、PACS等多套系统的协同，原有的系统并不完善；院内的取号机、签到机、自助缴费、打印报告等的机器每一家医院供应商并不同，并且需要非常多的进行接口和系统的研发，环境相当复杂需要和多家医疗设备厂商、软件厂商、硬件厂商协同工作。
1.2 流程梳理
如何让互联网医院的流程符合医院已有流程，然后再加以信息化，本身就是一个非常困难的问题，因为大部分产品和研发都是非医疗体系出身，如何梳理出符合医院流程就比较难，如果需要落地的话又会极度繁琐。
1.3 人员组织
医院系统服务商的协同组织，项目一旦开发完了，服务商们额外做很多开发的意愿很低，院内自己的研发主要任务在于维系院内一些研发需求和对接外部研发；平台运营人员的组织，院内在执行运营平台时，需要不断摸索。
2. 互联网医院的入口在现阶段，互联网行业相对成熟，应用入口基本固定，医院主导型和企业主导型实际上基本都差不多，区别在于以哪些入口优先级更高。
2.1 医院主导型互联网医院的入口
互联网医院的患者入口，大部分以微信公众号、APP和小程序为主要入口；医院主导型互联网医院入口，微信公众号排在第一，剩余依次是APP、小程序。
医院在不断地经营过程中，不断地向其微信公众号内增加新的功能，逐渐将新闻发布、健康科普、预约挂号/门诊缴费/报告查询、远程功能、就诊通知等糅合在了公众号里。公众号本身是比较臃肿的，嫁接着各类小程序和服务，但是用户基本完全沉淀在公众号的居多，例如某省大三甲医院，公众号内有超过400万的精准到院就诊和建档就诊人。
2.2 企业主导型互联网医院的入口
企业主导型，其实是承接了医院的对应互联网医院的建设和运营相关的工作，可以理解为互联网医院建设和运营全套方案一体化。在建设时偏重APP居多，但是在入口方面APP和微信公众号基本差不多，因为在医院里，打新增用户也需要依托医院配合才能完成。
2.3 医院主导型和企业主导型互联网医院入口的差异
相对于微信小程序和支付宝小程序，APP能够自主和定制化研发，实现更加复杂功能设计，这可能是最根本的原因，小程序受限制太多。
企业在经营互联网医院时，期待能够承载更多业务，并且能够较好地进行数据分析，建立患者健康档案，精细化的运营。因此在推广APP上更有动力，而医院主导型，微信公众号能满足基本需求，推广APP的动力有限。
3. 互联网医院功能简要概览互联网医院是指实体医疗机构的互联网化和依托实体机构设立的互联网医院，是互联网与医疗健康产业的结合。互联网医院以服务患者为核心，提供医疗保障、健康服务为主，同时均衡医疗资源和提升医疗服务效率，功能大致包含着就医服务、互联网诊疗、健康管理、院内服务、第三方服务等。
4. 互联网医院的发展情况伴随着互联网医院的不断发展，互联网医院的服务正从线上延伸至线下，线上线下的融合程度不断加深。90%以上的互联网医院已开通在线咨询、复诊开方，互联网医院提供患者在医院内所需的一些列服务，患者可以在线上完成预约、就医、问诊等，这是一个必然的趋势。
O2O模式一样最早是线上服务，然后是从线上不断延伸到线下，最后线上线下不断地融合成为最合适的商业模式，在这个过程中不断地优化服务，不断地淘汰不合适不成熟的伪需求。以美团为例，最早做O2O起家，后来T字型战略下，延伸到酒店、外卖、电影票、本地生活服务等，最后还入局B2B平台服务。
4.1 互联网医院服务发展路径：基础类→延伸类→增值类
发展路径一定是互联网医院的基础服务——延伸到线下的服务——增值类服务，是在发展必然逐渐完善的一个过程。
①基础类服务：在线咨询和复诊开方，预约挂号、在线咨询、复诊开方、报告解读等做为基础功能，满足就诊人在线上完成就医基础需求；
②延伸类服务：从线上延伸到线下的服务，线上预约线下就诊，满足除了线上基础服务外并且和线下就医融合；
③增值类服务：进一步挖掘医院需求，健康档案、慢病管理、随访服务等方面进行拓展，集中于院后管理、健康管理、宣讲等方向上的服务；
4.2 医院主导型和企业主导型的侧重点
医院主导型的互联网医院具备公共服务属性，服务于大众的健康。主导型的互联网医院在治病的同时，期待营收能够获得较大增长。
医院型互联网医院在具备优势医疗资源的情况下，能够较好地实现检查检验预约、住院手术预约等功能服务；企业型互联网医院，需要看企业和医院合作深度，是否连接院内住院预约、手术预约等；企业型互联网医院对通过增值医疗服务加强患者付费转化具备更强的意愿，由于具备资源，在药品配送、预约、处方流转、居家检测等，而企业型互联网医院通过服务包能提升患者付费转化，因而更积极。
医院优势：拥有优质的医疗资源，但是不擅长运营
企业优势：不具备优势医疗资源、医生资源，但是相对擅长运营、商业化、服务等。
二、医院主导型和企业主导型的差异今天在这里主要集中讲述一下医院型互联网医院和企业主导型互联网医院的差异，在线咨询的业务流程、模式、运营等方向上的倾向；一般的医院和企业对于在线咨询的功能需求是如何的，大致业务模式及产品设计方向是如何的呢？
1. 医院主导型互联网医院下对于病患的运营1.1 不以盈利为目的：以国民基础医疗保障为目的
中国享受全世界性价比最高的医疗体系，每一名中国人看病花非常少于在欧美；据B站UP主200万粉丝的口语老炮儿马思瑞（美国人）讲述，在美国医保价钱又贵质量又不太好的原因最核心的问题就是医疗保险私有化、医疗私有化，导致很多穷人看不起病；而在中国医疗是公有化的，为保障全民看病为基础目的，服务于民，让老百姓看得起病。
美国一名得了新冠的病人，在美国医院幸运的治疗好了，但是回家以后看到账单是112.25万美金，约人民币758.81万元，这费用基本等于大部分普通中国人一辈子还赚不到的钱；而在中国老百姓得了新冠病毒后，治疗是全民免费。
公立医院主要以保障国民基础医疗保障为目的，让老百姓能够看得起病。
1.2 稀缺的优质公立医疗资源无法满足精细化运营需求
优质的医疗资源90%以上在公立医院，优质医疗资源包含医学专家、护理资源、医疗器械、治疗环境、护理人员、药品等。按照市场的供需关系来说，作为稀缺的优质医疗资源，只能解决部分患者的问题，无法满足每一名病患的需求。优质医疗资源虽然集中在公立医院，特别是公立三甲医院，承担着及其繁重的医疗任务。
传统三甲医院对于互联网运营理解可能不足，而且受到政策和各种因素影响，无法精细化经营管理患者。
1.3 医院主导型互联网医院的理解误区
医院主导型的互联网医院是为了满足和提供更加优质的医疗服务，院内就医行为变得简单，为了医院的线下主体而服务的。一个非常巨大的误区，为什么医院和医生一定要向互联网企业那样运营病人呢？本质上来说国内公立医院来说，是中国国民健康下的基础医疗服务，健康保障，并非盈利组织。因此，医院主导型的互联网医院基本方向，是如何符合国家政策下的条件下发展分级诊疗、医疗资源共享等领域，建设更加信息化、智能化的医院。
1.4 以国家智慧医院评级要求和标准为目标
医院的信息化改革是一个漫长的进程，因此现在阶段大部分互联网医院的目的都是在不断地试探摸索出适合自己的道路。智慧医院的评级，是国家对公立医院的要求，也是医院信息化建设的目标。
在这里笔者不是太了解，智慧医院评级能给医院带来什么好处，具体需要长期在医院体系内做行政管理和卫健委体系的可能会更清楚一些。
2. 企业主导性的互联网医院2.1 满足医院要求，符合政策范围内适当为更好服务患者做商业化服务
企业主导型的互联网医院，在进行医院信息化建设的同时，优先满足医院的国家智慧医院评级、互联互通、医联体等的需求。然后，在符合政策范围和医院诉求的基础上，做相对深度一些的患者运营、增值服务包，在可控范围内摸索和试验。
2.2 不受限制的思维：较强的用户运营和产品迭代能力
企业主导的企业类型，擅长运营用户，擅长产品迭代，但是并不理解和熟悉医院的看病、治病、科室管理等的标准流程，如果只是产品功能的设计，是比较难地落地到真实的科室运营中。
医院里大部分医疗体系里的人，思维受限于医疗体系、医院体系，较少人具备充足和交叉的IT、互联网化、线上线下运营知识。在真实去迭代产品的时候，会觉得功能有了就可以了；去运营的时候，部分医院会觉得只要宣讲到位了用户就会长期使用；这是普遍会存在的一些现象。
可以理解为信息技术、AI人工智能、数据分析、运营等在新兴技术，和传统医疗服务、医院运营管理、病人管理等做一个糅合，需要跨学科、跨领域的知识和团队相互不断磨合，逐渐摸索的一个长期过程。
换一句比较直白的话来说，医院在原有多个系统的链接和融合升级，由于不同的系统服务商之间数据差异、迁移；人工智能在医疗领域获取医院医生配合下反馈迭代数据模型、诊断库、知识库等；基于中立三甲医院的特殊属性下摸索出符合国家标准的要求的运营方式，涉及到政府政策和监管要求等。
3. 在线咨询是互联网医院的核心功能之一预约挂号、在线咨询、检查检验预约等互联网医院里最常用的功能在线咨询功能。在线咨询，往往会变为基础常见疾病的咨询，深度疾病判断和治疗其实需要一些医疗器械做辅助，往往医生或让患者，到院检查和治疗，或者医院硬性规定下引流到医院。
医院主导型的互联网医院一般来说，很少做网络推广，都是基于医院线下导流、医护人员引导患者关注和使用，因此用户大致上来说地域性特别强，因为服务是基于医院半径来展开的。
互联网企业主导的在线咨询，往往是自建或者签约大量的医生参与，以增强服务的稳定性、及时性、可靠性，因为作为线上服务来说，及时响应患者是第一要求，然后及时和快捷的回答患者提问，并给予处理。
三、以功能为思考维度的格局及侧重点1. 国家政策下的产业图谱：互联网诊疗、互联网医院、远程医疗通过长期的摸索中，国家逐渐健全了对行业的定义，国务院互联网+医疗领域的顶层文件定义了互联网诊疗、互联网医院、远程医疗等，政策也逐渐形成了体系。政策以监督管理准入、职业规则、监督管理，由各级卫健委监管，准入者向政府报备并接受监管。
2. 在功能上的不同侧重点①互联网诊疗：预约挂号、在线咨询、医药电商等；
第三方平台提供轻问诊为主，以实体医疗机构提供严肃问诊；基于预约挂号、在线咨询、检查检验预约等展开；在医、药、险等领域做商业延伸。
②互联网医院：预约挂号、在线问诊、报告查询、电子处方等为主；
一般是医院主导，基于实体医疗机构展开，涵盖诊前、诊中、诊后，更好地服务患者；政策相关性极大，较难进行商业化延伸；
③远程医疗：会诊、远程监测等；
以医院为主体，提升基层医疗能力；实现病患和医疗资源匹配；
3. 一张图看清楚诊疗侧产业图谱3.1 诊疗侧产业图谱
互联网诊疗，也就是我们行业里常说的互联网医疗平台，以平台和互联网化运营为主，一类是为微医、春雨医生、丁香医生、好大夫的在线咨询、预约挂号的医为核心，药、险为辅助的平台；二是阿里健康、京东健康、平安好医生等以卖药为主，在线咨询服务是辅助的。
①互联网诊疗，包含微医、微脉、好大夫、阿里健康、平安好医生等，部分医院建立的诊疗平台；
②互联网医院，包含创业惠康、卫宁健康等，以医院为主导建设的诊前、诊中、诊后一体化全流程平台；
③远程医疗，以会诊、远程监测等为核心的平台；
3.2 目前以阿里健康、京东健康、平安好医生营收规模最大
目前几种模式里，以互联网诊疗–医药电商板块的企业营收规模最大，其次在线咨询平台、远程医疗、互联网医院差距不大，根据对应经营主体的经营管理能力有关。
①阿里健康：营收155.18亿，医药电商业务占比97.82%
医药电商自营业务销售额132.16亿，医药电商业务19.65亿，共计，151.81亿，占比97.82%；医疗服务、数字基建业务共计3.36亿，占比2.18%；
②京东健康：营收194亿，医药和电商业务占比86.6%
京东健康业务是完全自营，使用京东供应链，医药和电商产品销售168亿，占比86.6%；依靠京东的用户规模、供应链、资源优势快速发展。
③平安好医生：68.66亿，消费医疗和在线商城占比74.13%
用户规模3.728亿人，日均咨询量90万，全年营收68.66亿。
“平安集团到底给平安好医生贡献了多少营收？”2018年，包括平安寿险、平安产险、平安健康险等在内的关联方，购买平安好医生的产品和服务总计金额是12.84亿元，而在2019年年报中，这一购买额达到22.48亿元。
4. 互联网诊疗侧角色及其价值互联网医疗诊疗侧的行业，由以下角色构建整个完整的行业链条，就像一个生态系统一样，环环相扣、相互影响；
①用户：患者及其家属，就诊、住院、药品、健康管理等核心基础需求来源；
②实体医院：线下医疗服务提供者；
③诊疗平台：线上医疗服务提供者，提供在线咨询、预约、卖药等服务，例如微医、微脉、好大夫、平安好医生、阿里健康等；
④系统供应商：为医院提供软硬件开发，基于医院的需求进行研发配置，例如创业惠康、卫宁健康、卓建科技等；
⑤互联网医院：实体医院和系统供应基于实体医疗建立的医疗服务平台，服务于用户；
⑥监管单位：政府单位，卫健委等，拨款建设互联网医院，监管整个行业有序发展，服务老百姓；
5. 模糊的边界，容易越线竞争的格局互联网诊疗、互联网医院里、远程医疗，在不同领域里都会有不同的医院、公司在做业务的尝试。但是，这样的分类并不确切。因为，在政府、医院关系到位的情况下，具备研发能力的微医、微脉能够自行研发互联网医院和远程医疗的功能。在确认亏损可控可接受的情况下，卫宁健康、卓建科技也能够做成平台型。
一切基于企业自身的评估，医院由于大部分是公立医院，基本无自行实验的可能性，少量公司合营和私立大型医院，会去做这块的尝试，但是，基本高投入高风险较低回报率。
从项目来看，只要互联网医院、远程医疗在医院落地后，基本不会被替换，替换的成本极大；互联网诊疗平台可选择性很多，线上服务仅占医疗行业整体非常小的一部分。
医疗的信息化建设，是一个医院长期的过程，长期以来在医疗领域关联比较大的IT公司、医疗创业企业、SaaS供应商、医药电商等入局者，一直在政策的引导下摸索，寻找最适合的商业模式；医院也在国家的政策辅助和引导下不断地进行医院信息化建设，进行智慧医院等各项评级，强化院内经营管理、医护人员管理、病患管理、科室管理等。
按照互联网领域的对于平台的划分，一般划分为软件服务商（含定制化软件开发、SaaS、各类系统开发等）、硬件服务商、医药电商、在线诊疗平台、慢病管理+家庭医生、AI+医疗等。但是，按照相对医疗的领域视角来看的话，大概率并不一样。
6. 互联网医院的建设方式和盈利模式互联网医院的建设主要分为三种方式：第三方自建、医院自建、第三方和医院共同建设；第三方自建就是互联网诊疗平台，由平台主导面向C端消费者；医院自建，寻找软件服务商建设互联网医院，医院后期自行负责运营管理；第三方和医院共建，医院寻找第三方软件服务商合作建设互联网医院，后期服务商需要承担平台运营职责。
四、在线咨询——产品设计医疗服务领域最核心的功能预约挂号、在线咨询，是最高频的服务，最大的医疗业务场景。在线咨询的功能连接了患者和医生，患者付费后在一定的时间内，通过图文、电话、视频等方式向医生咨询疾病、用药、健康管理等内容；在线咨询成为了一个载体，线上复诊、诊后随访等功能在流程上其实和在线咨询并没有什么太大的区别。这里将从各个维度分析和拆解在线咨询。
1. 在线咨询的定义在线咨询：指的是患者在线上预约医院或平台的咨询服务，向不同科室的医生去咨询，通过表达阐述自己疾病信息、症状照片、检查检验的报告等，医生根据症状、生病部位等判断疾病情况，以及给到患者病情判断、用药建议、治疗建议等，严重或者需要进一步到医院门诊问诊和检查的，在建议患者到医院进行检查检验后再进一步获取诊断。
在线咨询的重点客户：某些角度来说，在线咨询可以让很多小疾病、慢性疾病等可以被治疗，能够让一些优质的医疗资源得到分享。
在线咨询的图文、电话、视频最终可能成为互联网医院里最核心的一种沟通渠道的工具。在线咨询/问诊流程和沟通方式会基本趋于一致，区别在于价格、咨询后诊断方式。这最终涉及到政策相关的原因，轻问诊和严肃医疗。
2. 互联网医疗的分类：轻问诊与严肃医疗①轻问诊和严肃问诊（严肃医疗）官方标准化定义；
轻问诊的主要模式为符合条件的第三方机构搭建互联网平台，可以提供在线咨询、健康科普及智能导诊等服务；
严肃医疗的主要模式为作为实体医疗机构为主搭建互联网医院，可以提供挂号问诊、预约诊疗与影响诊断等服务，更类似于实体医院的一个科室；
②实际运营中的差异：咨询建议和在线诊断
轻问诊的定价可以根据医生的职称，由医生或第三方机构平台自行定价，并且收益及分层可以较为灵活地处理；但是，在最终出的结果这里，只能做病情、用药、治疗等的咨询建议，无法开医嘱。
严肃问诊的定价由国家卫健委指导定价，收益时每日对公转账，最终分层及收益将会由处理；严肃问诊可以下诊断，在某些角度上和医院门诊室里医生开的医嘱是一样的；由于定价相对较低且固定，医生对在线问诊没有在线咨询的意愿度高。
3. 用户正在逐渐适应线上咨询的就诊方式经历过疫情爆发后，大家正在逐渐适应在线咨询的线上就诊方式。互联网医院数量在快速增长，19年线上咨询诊疗人次3.5亿次，占全国门诊人次不足10%，具备较大的增长空间；医生缺乏和患者互动的主要工具，在线互动逐渐成为主要的方式，便于后期随访和管理；医院内封闭的患者流量与医生资源转向外界释放，导致互联网供需两端都在增长；患者正在逐渐习惯在线咨询来看病。
4. 特殊现象：用户医从性极高用户医从性极高，有利于未来商业模式衍生，这是由于看病、诊疗需要高度专业化的知识，因此大部分患者基本上是愿意相信医生的，医从性极高；学历和文化程度越高的患者，医从性越高；年轻患者较年长患者们医从性更高一些。
用户医从性比想象中更高，需要强化问诊和挂号后买药场景，即医药电商平台；由于医疗资源的局限性，通过线上咨询和问诊，会极大地提高用户对医生和信任和亲密度，提高医疗服务质量，用户付费意愿提高；由于诊后的服务需求频次高、且时间较长，因此产品设计时，应当方便用户再次诊疗和再次医生诊疗该疾病提供便捷通道。
但是，医从性极高的前提是患者对去就诊的医院或者平台有较高的一个信任度，但是这种信任程度，是从长年累月逐渐积累下来的。因此大部分平台不具备这种信任感，患者不知道在后面咨询的那个医生，他具体是什么样的。医疗水平如何？不能治好自己的病，或者解决自己的问题？
因此，我们能够在平台上放心的买药的原因：
第一，国家对医药企业准入的、生产、销售环节的监管；
第二，网上卖药是有较高的准入门槛的；
第三，在网上建设平台并且让线下门店、自营销售药品的平台监管；
第四，如果因为药品质量或出现医疗事故，是一个严肃且巨大的问题，并且会事后追责。
5. 在线咨询的商业模式在线诊疗目前已经成为了互联网医院两大核心基础流量型功能，能够获取用户大量的基础在线就诊需求。患者在互联网医院/在线诊疗平台上下单并且付费，通过由医院/企业支持的平台，将系统订单反馈到医生，医生在线接单后，在预定的时间范围内通过图文、电话、视频等咨询方式，在线处理患者的疾病咨询/用药咨询/报告解读/健康管理等的需求。
医院和企业建立互联网医院平台，提供医生资源，患者可以下单和医生在线咨询问诊，以解决疾病咨询、用药咨询、报告解读、健康管理等方面的问题；医生根据用户的病情描述和实时沟通，给出较为中肯的咨询建议。
6. 在线咨询的主要环节在线咨询的功能，在流程上是标准的一个医疗逻辑，首先无论是任何模式下，必然是患者和医生双向交流，一个人无法完成，因此订单生成、开始咨询、结束咨询等是医生和患者两个角色想和沟通的一个过程。
①订单生成：包含用户选择服务、选择医生、并且描述、支付等；
②开始咨询：医生接受或拒绝，医生发起咨询的时间和条件，用户接受或拒绝；
③咨询中：咨询的约束条件（次数、时间等）；
④咨询结束：结束的条件（用户结束、用户次数用完、时间到达自动结束、医生结束），医生下达咨询建议、用户评价；
7. 在线咨询业务流程图在线咨询从患者发起，到最终结束是个比较长的流程，患者发起时的核心在于选择服务方式（图文、电话、视频等），选择医生，选择就诊人，都是不可少的内容，可以根据自己的实际情况去做一个选择；病情描述是为了节约医生的时间，加快沟通效率；
患者发起并规定医生一定要接受，因此医生会根据自己的时间安排，最终来决定是否接收患者的申请，接受以后咋才能继续进行后续操作；在结束咨询时，不同的业务方式下结束的条件是不一样的，每一种都是相对合理的，因为在约定时间内、次数内患者必然能描述清楚自己的病情，大部分医生都是相对谨慎的，感觉患者在病情严重或者发现有隐患时，会在给了一些治疗方案、建议后，建议患者到院治疗，以患者健康着想，避免医疗风险。
8. 核心判定节点：影响业务模式和产品设计在线咨询的流程里，存在一些关键性的判定节点，不仅影响产品功能的设计，还关系到医院和平台实际在线咨询的开展，也会影响到未来的业务模式。
8.1 订单生成阶段——下单后支付时间
一般会根据医院实际情况，要求在5分钟或15分钟内完成支付，只有完成了支付订单才生成，才会继续下一步；
8.2 开始咨询阶段——医生接诊方式
①有权选择是否接诊：医生根据自己私人时间选择是否接单
医院为主导的互联网医院里，医护人员有繁重的任务，要为病人治疗、手术、随访跟进患者情况等，可能并非完全精力放在在线问诊上；另外，当患者的病情描述，和医生所擅长治疗的疾病不太匹配时，也可能会选择不接单。
②一般是必须接诊：医院/平台安排医生值班
系统分配和患者选择医生本质上是两种不同的业务模式，运营逻辑和产品逻辑都是有一些区别的，这里不做过多的详细描述。
当医院组建在线问诊的医生团队，能够支撑起全科在线问诊时，在当患者发起订单时，一般情况下根据患者选择科室和疾病描述，系统自行分配医生，这种模式下必然需要及时响应；或者患者预约了医生，医生会接受，但是会选择合适的时间和患者沟通；
平台型以微医、杏仁医生、好大夫、平安好医生等平台，签约合作了较多医生的情况下，可以由系统分配医生；但是，当选择了对应医生时，一般情况是在预约的时间和医生进行沟通。
8.3 开始咨询阶段——医生是否发起，患者是否接受
双重判断通过后，在线问诊才算正式开始：医生是否发起，患者是否接受；因为，服务本身就是由医生和患者两个角色在线沟通交流疾病、病情、用药等才能够完成。
8.4 咨询结束——结束方式
咨询会有一个规定的时间内完成，超过时间自动结束；部分咨询是按可咨询次数收费，用完了不续费自动结束，当然医生会根据已知的信息做一个咨询建议；医生或患者结束，当医生觉得交流后已经了解的足够多的信息了，将会主动结束咨询，患者结束的情况比较少一些。
五、简谈在线咨询1. 在线咨询的诉求差异：补充功能VS商业化诉求在线咨询的核心功能在产品的设计上，企业主导和医院主导型的比较大的差异。
医院期望在线咨询是一个补充，重点关注的是能否为用户或者患者提供产品服务的工具属性，能够对线下实体医疗院内医疗已有的流程做补充，没有流量诉求也没有任何的过多的需求，非常重视是否有这样的功能，互联网医院评级的指标之一。
平台型的话，有商业化诉求，基础医疗服务是起点，增值服务商业化是目标。在线咨询，是线上所有业务展开的起点。在线咨询服务做好了之后卖药、卖保险、服务包推荐等的商业化诉求。非常重视用户体验，重视宣传和推广带来的新增用户数、留存率，咨询结束后的增值服务和其他服务购买情况。
1.1 业务展开的差异
医院主导型，医院希望不打扰医生，因为医生资源相对有限，一家大三甲可能医生500+以上可以做线上咨询，但是本身就有大量的医疗工作任务，能够花在在线咨询上的时间有限。短期来看，在线上咨询投入过多后，带来的实际收入、医院流量增长极为有限，并且可能会影响到医生的工作，对平台运营管理能力相对不足，所以暂时无法保证服务响应速度和回复率。
平台型会更多地考虑扩充自营医生团队和医生库，让患者能够更好地、及时地展开在线咨询。在线咨询有一个特点，预约了未来的一个完整的时间、或者定义聊天发送问题次数，次数结束咨询即结束，医生将给出答案。
1.2 即时型和预约型的差异
本质上来说，即时型的在线咨询业务，预约型的在线咨询业务（预约范围时间，或约定制定时间内完成交流、限定沟通次数等）。可能不是很熟悉实际运营的产品同学会觉得其实差异没有那么大，但是实际上从响应速度、医生回复质量等来说，其实并不是一样的。
用户比想象的更加单纯，而且需求不同，有时候需要马上解决问题，有时候需要预约专家来咨询病情。是像笔者这样的多年互联网从业者，也会在确认疾病范围的情况下，选择靠谱三甲知名医生–主治医生以上来进行交流获取信息。
1.3 思路上的差异
①产品维度：
即时型，功能设计时，增加了字段，匹配方式；通过海量的在线医生，然后由患者预约，按照患者咨询内容在一定规则下进行分配，然后快速完成咨询。
预约型，制定时间范围，医生在指定时间或者一定时间内处理，然后以处理完患者的疾病信息，给治疗建议、用药建议为主；如果医生没时间就会直接拒绝患者的咨询申请，如果医生有时间的话，就会接单。
②运营维度：
患者和和医生的线上交流，和医院的关系维护，大概率是需要一个纽带的；一个引流或者医患核心交流渠道，进行后续商业变现，可以说是医疗领域核心的功能之一。
即时型，管理医生和服务质量，运营核心指标是响应速度、医生接诊率、回复率；预约型，运营偏于管理医生的值班出勤、接诊率、回复率。
2. 普通疾病——低频，突发疾病——偶然，慢性疾病——长期用户较少使用在线咨询功能的原因在于，普通疾病是一件低频的事，突发性疾病是一件偶然的事，慢性疾病是一件长期的管理。普通疾病和慢性疾病处理方案首要思考是要不要去医院，其次是不去医院有没有在线咨询工具能解决问题，选择哪一款工具？突发性疾病只能经济去医院或呼叫120。
健康每个人都拥有却不会珍惜，只有经历过重大疾病才会珍惜，因此健康的意识和形态是需要逐步建立的。而不同群体患病情况不一样，白领容易患颈椎病、腰椎间盘突出，程序员容易脱发、偶发性急症；工地上容易拉伤、砸伤、摔伤、长期重体力活带来的劳损（就想像俄罗斯方块一样）。
3.1 在线咨询回复率：虚假–医生回复率很高，现实–回复率不足50%
很多刚入行的医疗产品会有一个误解，觉得在线咨询，可以做成在线实时问询医生，医生持续排班然后完后较好的在线咨询运营，并且医生回复率会很高。
但是，实际上医生在医疗领域是绝对核心的资源，并且医生日常有门诊、治疗、病人管理、科研、科室管理等任务，在没有医院硬性指标的前提下，个人动力不足。相对而言，护士和基层医生会有更大的意愿度来解决患者的问题。
因此能够和病人实际上沟通的时间并不会那么多的，因此功能并不复杂，但是实际运营却很难像一般互联网产品一样做的那样非常精细化的运营，基本上以解决患者的问题为主。
3.2 在线咨询能让患者向专家咨询，但无法解决所有问题
关于专家，其实专家时间更加宝贵，因此“服务质量”更加难以保障。相对于线下预约几周、排队几小时、沟通几分钟，在线咨询至少有一个前提就是能够相对充分地进行沟通，减少了较大的时间成本，较多的沟通。存在无法诊断的疾病，医生会让患者到医院检查后再诊断，因为有一些疾病需要进一步检查以后才能确诊。
3.3 医疗领域受到政府强监管的
医疗行业是一个强监管行业：政府对互联网医院诊疗的业务模式、药品流通、医保覆盖范围等多处限制。医疗领域从药品研发、临床、生产、上市，再到医生的诊疗记录，患者的医疗数据都是被监管的。互联网医院的数据一般部署在医院，并且在线咨询、挂号等数据是定期上传至监管平台审核的，由于医疗数据的敏感性，当出现了问题时责任重大。
六、后记这篇文章是根据自己在实际设计在线咨询/问诊过程中碰到的情况，看了多篇行业报告后做了一些总结归纳，然后断断续续地在自己想起来的时候就写了一点，只能说59分的文。其实还有很多内容没写，①比如在线问诊是属于严肃医疗行为，可以开处方的，处方和医院HIS关联并进入病历；②当然开完处方后还可以带药，院内是一套体系，处方流转院外药店又是一套体系，还有是否30分钟配送到家又是一些不同的延展；③图文、电话、视频咨询有什么不同？
所以，也欢迎相互交流探讨，在互联网医疗领域，特别是互联网医院，很多时候其实是产业互联网思维，功能本身并不复杂，但是政策本身、政府监管、医院诉求、行业发展本身才是复杂的。
最后，也用这篇互联网医院相关的行业研究，来结束自己长达几个月的断更，人生也不能因为之前过往而止步不前，已经准备好燃烧起来迎接未来，开启新的研究，不间断地学习……
七、免责申明本文仅代表个人观点，数据来源于部分互联网公开信息，特此申明。 如需私下交流或侵权等问题，请发邮箱：aigbert.li@qq.com，或加微信Aigbert-Aquarius（请注明原因，否则一般不通过），欢迎各位指正和交流，。
八、引用及参考文献《互联网医疗行业深度：破局之路，行则将至》，国金证券（医药健康研究中心），2020.04；
《互联网医疗研究框架：诊疗篇》，中信证券研究部（计算机行业医疗信息化系列研究5），2020.07；
《2021互联网医院行业研究报告——从外围工具到医疗核心互联网医院再迭代》，动脉网&蛋壳研究院；
《互联网医疗平台专题报告Ⅱ：互联网医疗平台商业模式有哪些？》，民生证券，2020.07；
《2020年中国互联网医疗年度分析》，易观数据；
《2020年中国智慧医院现状及趋势研究》，亿欧智库，2020.07；
《阿里健康2021年财报》；
《京东健康2020年财报》；
《平安好医生2020年财报》；
#专栏作家#LS邋遢道人，公众号：LS邋遢道人，人人都是产品经理专栏作家。资深运营和产品，连续创业者，现任某公司产品负责人。关注虚拟现实、虚拟增强、电商、新零售和生鲜领域，擅长运营分析、行业分析和产品分析。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
