很可惜 T 。T 您现在还不是作者身份，不能自主发稿哦～
如有投稿需求，请把文章发送到邮箱tougao@appcpx.com，一经录用会有专人和您联系
咨询如何成为春羽作者请联系：鸟哥笔记小羽毛（ngbjxym）
全文共12701字，阅读大约需要60分钟
（建议收藏）
互联网的下半场
过去，平台的黄金时代
互联网上半场的商业模式，主要是以满足C端用户需求为核心的平台产品，包括：社交平台、电商平台、团购平台、出行平台、内容平台。平台通过链接人与人，内容与人，商家与人，聚合大规模的流量。
图1：平台产品示例
互联网平台的核心优势
① 超低的边际成本
平台公司的核心业务主要是信息服务，它每多服务一个用户所花费的边际成本极低。根据利润公式可知：
π(总利润) =TR(总收入)-TC（总成本）=TR(总收入)-TFC(总固定成本)-TVC(总变动成本)
其中，TR、TVC都是与Q（用户数量）相关的函数，只要TR-TVC为正数且TFC与Q的关系较弱时，规模效应会摊平TFC，实现整体盈利。
图2：当Quantity大于20时，产生正向的利润
② 赢者通吃的护城河
C端的平台产品显著区别于B端的是：“任一用户对平台的议价能力都很弱，单个用户的离开对业务的影响很小，并且C端平台规模有较强的马太效应（供需趋向于集中化），规模本身就是护城河。”
图3：流量与护城河
③ 网络效应筑造产品壁垒
如果淘宝/天猫只能购买一线城市的商品，那它很难有今天的规模与社会影响力。只有当它成为一款全国性的产品时，用户的需求才能更完整地被满足，它也才有更高的产品壁垒。一个硬币的反面，当一款产品无法通过网络效应提升壁垒时，它的竞争压力也会相对更大一些。
例：滴滴出行的快车业务属于本地生活业务，就算杭州的快车做得再好，对成都的快车业务是没有显著增益的，没有网络效应也就意味着在不同地区都可能直面竞争压力。就像两年前美团打车上海、南京与滴滴直接竞争。
④ 高技术杠杆
上半场的产品大多都是以代码为核心生产力的，技术的高杠杆在于：
1. 能够通过快速的迭代来创造用户价值。因为，
C端平台关注核心用户的画像，产品标准化程度更高。
代码属于很轻的技术资产，不涉类实体行业的库存及现金流占用问题，沉没成本更低。
2. 数据与算法的应用降低了信息/交易的撮合成本，提升了用户获取信息及交易的效率。
其实，每一次新浪潮的开始，我们都能见到很多自信的、跃跃欲试的闯入者。那些一夜暴富的故事，支撑着雾霾下每日4小时的通勤人，他们是造梦者的门徒。直到潮水褪去，我们才在不断地离别、叹息和马后炮中，看见了市场它最冷静的一面。
流量红利殆尽，产业亟待升级
移动端的流量红利是互联网上半场创业市场繁荣的根本原因，海量的新流量，从供给端拉低了平台产品的获客成本。
然而在2018年后，移动端增速见顶。根据Quest Mobile的数据，2019年1~6月移动互联网MAU仅净增570万，Q2甚至净降了193万，预示着移动互联网进入“存量残杀”时代。
图4：移动互联网MAU趋势
1）TO B是顺势而为
2016年7月，王兴提出了“互联网下半场”的概念，他提到：“美团点评作为国内最大的互联网餐饮平台，过去几年做的只是很薄的互联网化，即帮助企业引流。接下来要实现和行业的深度融合，全面帮助它们提升效率，降低成本。”
历史之势从来不是无心为之，那这次为什么是TO B呢？
就在2019年，中国人均GDP正式迈入1万美元梯队，奇迹四十年彰显了中华民族韬光养晦、努力奋斗的民族底色，也给了Z世代的年轻人足够强的文化自信、道路自信。
但是，这个被修昔底德陷阱笼罩的资本世界，并不会手捧鲜花迎接来我们的成功。相反，在外部，富有针对性的遏制措施越来越多，霸权思维主导的国际秩序下，民粹、贸易保护主义抬头。强者间斗而不破，开始进入全方位的战略竞争期。
图5：2020年中美贸易协议双方需要履约的条款统计
在内部，劳动力受旧政策、新环境的复合影响，出现断崖式下降，成本不断攀升。导致低端制造业比较优势丧失，相关产业逐步转移至东南亚、印度、巴西等地区。
中国制造的升级需求急迫。
2018年中国出生人口达1523万，比上年减少200万人，是近40年来中国出生人口环比下降最多的一年。
2019年，中国美国商会（AmCham China）针对239家在华美资企业的调查显示，22.7％的公司将把供应链从中国转移出去，19.7％的公司正考虑将部分或全部制造业迁出中国，33.2％的公司将推迟或取消其投资，只有2.9％的公司将增加其在华投资。
还需要清醒认识的是：“我国的科技实力、大学教育、基础科学，相比美方仍然有巨大的差距。”
应该避免盲目自信稀释了专注度。
宏观层面，仍高度依赖发达国家的高科技产品（进口）；中国智造想要迈向全球，也还长路漫漫。微观层面，传统行业信息化水平低、企业管理粗放、诚信体系缺失、供应链效率不足，制约着中国从量到质的转型。
这是未来10年必须要变革的难点，也是TO B赛道的历史机遇。
图6：半导体、飞机等高端制造，中美差距巨大
2）TO B的快速车道
相比于上半场以C端用户的规模效应、网络效应筑造护城河，下半场转向更多的企业服务，以及传统行业升级，包括，
① 以企业为核心的产品/服务。
包括：餐饮Saas、开店Saas、人力资源（组织发展、员工福利）、协同办公（Confluence、Teambition）、数据服务（神策数据、飞瓜数据）、云服务、人脸识别、无人驾驶等。
② 传统行业数据化、智能化、供应链优化。
包括：新零售、物流科技、长租公寓、K12教育、AI芯片等。
区别于互联网上半场更高频、短链、碎片的移动场景，下半场对产品经理提出了新的挑战，
产品/服务不再完全以系统为核心，产品经理需要更多关注业务的场景、流程、组织、角色、供应链，去设计“服务”而不仅是“系统”。
用户体验由“抽象的主观效用”转换为“可量化的收入与生产成本”，要求产品经理有更强的业务认知、商业敏锐度。
近几年，TO B方向已经诞生了很多优秀产品。例如：有赞、旷视、Teambition、阿里云、钉钉、神策数据、G7等等。相信就在不久的将来，中国也将诞生像Salesforce、Atlassian、ZOOM、Slack这样千亿、百亿美金的企业服务公司，大势之下，只是时间问题。
图7：美股排名靠前的企业服务公司
TO B，业务下沉
业务设计与有效工作
世界上没有完美的规划，但全面、严谨的业务设计，能够大幅提升组织的有效产出。如果在这件事情上懒惰，天天拉着团队打鸡血、画饼、打仗，中长期持续的负反馈，很容易让团队崩盘。
1）业务设计要相信专家。相比较那些聪明、年轻的头脑，业务专家更值得信赖，因为B端很多线下的细节和业务逻辑，需要足够长的项目积累才能有判断力。互联网人在产业中往往不是用户，只能凭借逻辑或者类比法来演绎，决策的有效性不高。
2）业务设计要心怀敬畏。不管你做过多少DAU的产品、多么闪亮的教育背景，面对传统行业，都是从零开始。一定要对行业、前辈心怀敬畏，互联网在这里很难颠覆谁。
3）业务设计要勤于思考。
问：业务设计不是CEO、总经理关注的问题吗？和我有什么关系？我只想扎扎实实做好产品、运营。
答：扎扎实实做产品、运营和关注行业趋势是不矛盾的，这种东西不观察个3年、5年也观察不出什么，思考核心问题不怕早。并且，没有公司需要一个35岁的活动策划专员，努力认知业务是个人从点→面的过程。
TO B的业务设计概述
图8：TO B的业务设计概述
1）业务分析
业务分析是为了“发现机会”与“预警风险”，对于TO B业务，除了常规的行业分析、用户分析，需要重点关注“监管趋势、政策走向”，并不是所有的行业监管都允许先粗放发展再加强监管，死亡可能是突然休克式的（电子烟、比特币）。
① 宏观经济
宏观经济的走势对企业融资成本、现金流压力是直接关联的。对比个人消费者被宏观经济的影响有逐级的传导迟滞，企业一定是更敏感的。
关注的核心模块，包括：出口/内需/投资的战略变化（例：近几年对外资的政策松绑）、货币政策的变化（例：近期的公开市场操作、准备金率变化）、税收政策变化（例：增值税税率变化对业务进销项的影响）、地方政策（包括：人口政策、产业政策）等等。
② 监管趋势
顺势而为，是保障业务能够持续发展的必要前提。滴滴规模近似垄断后迎来的管制压力，我认为本质上是国家对核心民生行业的行政干预预期较高，因为涉及到社会稳定、安全，强管制是有必要性的。
同样，像比特币这类去中心化、发行不由官方控制的所谓“货币”，在当前的监管层面上，肯定也是无法被接受的。以大局为重，是一个取舍的过程，4.025%的年金险下线也是同理。
③ 分析框架
分析框架需要站在行业的角度、客户的角度、需求的角度，评估业务的可行性。
案例：做一款TMS（运输管理系统），解决规模型车队的管车问题。
1. 行业基本情况与发展趋势概述
商流驱动的集约，受电商飞速发展的影响，中国集约性比较强的运输领域以快递为代表，CR5已接近70%，也带动了一些成规模的运输车队（下游）。
成本压力逐级传导，但由于快递行业过于集中，核心企业货量庞大议价能力强，成本压力逐级传导，中下游的运输公司经营压力大。尤其那些重资产、大规模的车队，其资产管理、资产利用率、成本控制等多个方面都对运营能力提出了极高的要求。
.....（不赘述，参考咨询报告）
2. 客户概述及上下游分析
目标客户画像，拥有>100台卡车以上的运输公司，因为这种量级的客户才有优化管理成本的需求，目前这种规模的运输公司全国大概有10000家（假设）。
客户的上下游分析，这些运输公司的上游是通达系、德邦这类大型快递、快运公司，下游有自有购置的车辆，也有社会运力。当前的行业现状是：“运力相比货源大幅过剩，整体议价能力较弱。”除电商外，整体商流的集中度不足、需求个性化，无法形成高度集中的物流市场。
......（多维度、信息详尽）
3. 客户在成本、效率上有什么痛点？
效率瓶颈：公路运输核心还是在成本、履约质量上，为了保障履约，部分企业购入大量固定资产（车头、车挂）自营运力。与其他实体行业一样，这将面临着业务波动带来的周转效率问题。
品质管控：因为快递、快运对于运输的时效要求很高，供应商需要及时了解车辆位置，做好时效控制，降低时效罚款（大概占其总成本的5%（假设））。
边际成本：实体资产无法像代码资产那样，边际成本趋向于一个极低值，相反，每一个时间段内，一个货车只能运送一趟货物，这就决定了该场景下技术杠杆不会特别高，运营的效能非常关键。
现金流压力：中游运输公司需要承担>2个月的账期（甚至半年），相比快递、骑手这类即付现金流的模式，账期带来的资金压力也限制了业务规模。尤其在利润相对微薄的情况下，即使通过保理融资解决了现金流的问题，其所带来的成本上涨，对实体运输企业也可能是不可承受之重。
......（业务经验比逻辑闭环更接近事物的本质）
4. 业务的可行性分析
需求验证：管车的需求是真实的，主要是为了减少管理成本、降低迟到罚款。目前竞品已经切入了100家大客户。付费意愿大概在1500元/年，续费率75%。
注：上述数据皆为假设。
切入路径：目前通达系的供应商（我们的客户）都必须安装一款XX品牌的监控设备，如果想要切入该类客户，本质是需要搞定它的上游，客户不会重复采购两款类似的产品。
......（仅做示例，竞争力评估、关联市场影响等不在此赘述）
总结：只有深入了解供应链上下游的关系、供需基本面，才能更好地做销售、产品、运营的决策。
2）业务设计
业务设计的重点是“知己知彼、产品下沉、运营业务”。
① 知己知彼，百战不殆
不同的业务所处的行业周期、竞争情况都很不一样。但最抽象的一层，仍然是以“解决客户需求”为核心。需要通过持续分析竞品、完善服务体系、制定符合业务发展阶段的增长策略，去构建核心竞争力。
1. 产品分析
调研竞品是一个自省、迭代的过程，主要目的是为了评估客户需求集合的满足程度，以及产品切入场景后的角色体验问题。
关注客户的核心需求满足程度。B端业务需要满足企业的需求集合，而非单点打透。如果产品功能覆盖度不够，难以构建竞争力。
例：一款餐饮Saas，80%的用户不仅需要收银功能，还需要“经营分析、报表管理、营销管理、排号等位”等10项功能。产品A仅能满足其中5项，产品B全部满足，则产品A难以与B竞争（价格相差不大）。 
图9：中国典型餐饮Saas竞争力分析
产品的操作体验是否能被客户的组织接受，也很重要。如果仅仅只是老板买了单，但客户的组织、各关键岗位无法接受系统的流程/交互，产品切入会受到各种各样的阻力，落地困难。
2. 销售策略分析
在有限的预算与HC的条件下，根据竞品的销售资源、销售策略，去制定ROI更高、长线收益更大的销售策略，是很有必要的。
客户：梳理竞品的客户清单，盘点客情关系及服务深度。
策略：梳理竞品的拓展策略，盘点其核心优势区域及下一步重点拓展的区域。
增长：梳理竞品在拉新、留存上的人力配置、补贴策略，能帮助我们更有针对性地开展差异化的增长策略。
例：产品A拉新方面投入了大量的线下力量，且线下销售的核心任务都压在了新增上面。此时，产品A通过“留存激励”的运营策略，即只要商户交易额在次月保持上个月的80%以上，即可获得“高额奖励/折扣”等（通过电销营销），以此减轻线下销售的存量客户维护压力。这笔营销费用需要与所释放销售的获客价值相比较。
② B端产品经理的业务下沉
TO B产品提供的是一套完整的服务，可以分为两个维度来看，
图10：看待服务的两种视角
面向客户（外部），业务需要交付“用户视角的产品与服务”，即：“用户会使用什么软件，体验什么样的服务流程，最终支付多少钱。”产品解决方案要满足需求、服务好、价格合理。
面向组织（内部），产品解决方案是由基础的职能分工（业务运营、业务产品）与多个项目共同构建的，所有的人力资源、财务预算配置，都需要以“保障面对客户视角的服务、体验不断改善”为核心目标。
1. B端产品经理如何创造价值？
抽象来看，产品经理最核心的能力应该是“解决问题的能力”，进而为用户创造价值。
图11：产品经理的核心能力
《俞军的产品方法论》中提到：
对于用户，大家有不同的理解，通常的理解是用户即自然人。以微信为例，一般的统计报告可能显示其“用户”为11亿，如果把微信的其他功能（支付、公众号、小程序、朋友圈、群等）都删掉，只留下通讯功能，它的用户数可能还是11亿，但它的商业估值可能就从2000亿美元变成了200亿美元。这种将用户定义为自然人的做法，显然在大型互联网产品上并不适用。
从产品经理的视角来看，用户不是自然人，而是需求的集合。
关于需求集合，C端与B端产品是有所区别的。
图12：需求集合的差异
做好C端产品，要能够洞察人性本质的需求，要求产品经理除了有较强的逻辑、同理心之外，更要能透过现象看本质。世界上最成功的C端产品，都是人类本质需求的满足者，比如：微信的熟人社交、字节跳动的推荐算法、Pornhub的好人社区、Uber的出行服务。
但做B端产品，还需要产品经理有优秀的商业感觉。产品必须是一个业务专家，要能梳理业务的“供需关系、生产管理、组织管理、供应链管理、财务管理”等相关信息。有能力挖掘企业的效率、成本的痛点，并打造满足企业需求集合的产品。
例：钉钉，一款老板验高于一切的协同办公产品，一款优秀的老板呼叫器、考勤管理利器。只需要轻轻地夺命DING一下，员工24h在(bei)线(po)办公，老板能不喜欢吗（微笑）？
2. B端产品的货币时间价值
现金流
A产品，营业收入105万元，总成本100万元（当期支付），此时的利润是多少？5万吗？
但如果这105万是应收账款，实际1年后才到账：
Ⅰ 假设贴现率5%，未来1年的105万收入在当期仅值100万，所以，考虑货币的时间价值，当期的利润为0。
图13：货币的时间价值
Ⅱ 由于105万的应收是1年后才到账，意味着当期支付的100万需要流动资金支持，此时使用100万自有资金周转业务（假设利率5%），该笔资金当期的机会成本为5万元。
业务的收入现金流是财务模型的关键点，像快递、滴滴这类客户即付，对下游供应商（运输车队、滴滴司机）有账期的业务，资金占用没有压力，有迅速做大规模的条件。但下游供应商如果想做大规模，周转资金反而成为较大的阻碍点。
NPV计算
只要当成本投入与收入有时间错配，NPV计算就是非常必要的。
图14：NPV计算公式
例：当期为了拉新用户，产品A共计投入补贴1000万元，获得的用户在第12个月单月合计贡献了1050万的利润，贴现率5%，当期价值Present Value 为1000万元。故可得NPV=0。
图15：各时段现金流的现值计算
总结：做业务决策时，如果不考虑货币的时间价值，往往会导致做投产比分析结论有误，带来无谓的财务亏损。
3. B端产品的用户调研
图16：B端与C端用户调研的差异
B端业务场景往往是非生活化，需求的搜集与分析，没有过往经验的支撑，更需要产品经理深入当前的业务场景中去，了解：
客户的决策机制、切换成本
实际决策人是核心需求的来源，组织的各角色是产品的实践者，他们的需求都需要了解（以决策人为核心）。
例：为餐饮商户提供外卖接单系统，商户决策因素有：加入美团点评后，店铺的流量获取能力会与哪些指标相关，收入抽成比例，提现规则（资金占用），营销工具包（会员、积分、优惠券）等等。
对于已经使用竞品的客户，除了考虑产品、成本差异，还要考虑切换成本，尤其那些与客户系统打通竞品（可能两边花了几个月时间才打通）。
我们产品的新体验能否超出旧体验+切换成本？如果不能，客户凭什么切给我呢？（答：也许可以通过销售动作补产品不足，为什么会有大保健？）
梳理业务流程、组织角色及其KPI
梳理流程是业务设计最核心的工作之一，它类似C端的用户体验地图，通过梳理各个节点的“效率、成本”痛点，找到产品的核心价值点，并基于此去创造新的用户价值。
图17：瑞幸咖啡的用户体验地图（示例）
梳理各角色及其KPI，更有助于改善服务能力、产品体验。
例1：调研客户组织后了解到，采购经理的KPI除了找性价比更高的供应商，还要求供应商的履约品质必须达到公司设定的标准，这决定了业务的资源投入（例如：客服、Local人员的投入）。
例2：对于订单录入的操作员，每个人负责的线路相对固定，高峰期每日录入100单，每一单都需要重新选择出发地、目的地，操作成本太高，应该设计常用地址库功能解决这个问题。
4. B端产品的设计概述
了解程序设计的MVC范式
Model指数据模型、View指前端交互图，Controller指业务逻辑。任何一套软件系统运作的本质都是相同的；用户在前端交互层操作后，系统通过业务逻辑层处理数据层的数据。
图18：MVC范式
从业务流程到产品架构
业务流程梳理是产品设计的重要基础。
假设做一个外卖系统，一个商家要开店接单，最简易的流程需要有：注册认证→开店→接单→提现。流程之下就是需求的集合：
(1) 注册认证：需要哪些资料、资质？审核标准、时效要求是什么？
(2) 商品管理：支持排序管理？支持哪些信息修改？商品图片支持多大规格？配置商品数量的上限是多少？
(3) 逆向流程（重要）：逆向流程的完备性决定了销售、客服、技术的无谓成本。完备性不足将可能导致技术分散精力去解决偶发的逆向问题，影响开发进度、质量。
3.1 不同订单状态下，客户发起取消的业务逻辑应该有什么不同？
3.2 骑手因故无法取餐，商家端是否需要支持发起重新匹配骑手？
3.3 客户点的某一样商品无货，商家是否支持部分退货？
......
图19：商家入驻外卖平台
基于业务流程对应的需求集合，梳理产品架构。
(1) 基础功能：包括用户、支付、消息、**等，可能会接入统一的中台服务，需要基于业务需求逐个梳理功能细节。
例：因监管要求，营业执照有效日期单独录入字段，做较强的业务限制（超期不更新无法再接单）。
(2) 业务功能：包括订单服务、营销工具包、门店管理、权限管理等。
图20：产品架构图（示例）
Ⅰ订单作为核心服务，其状态设计及各状态下的逆向流程非常重要，决定了商家自助经营的能力。
Ⅱ营销工具，核心是赋能商家销售，包括：送券、卖券、满减、秒杀价、广告投放等等。
Ⅲ权限控制，主要参考RBAC（Role-Based Access Control）模型。其中最简单的用户、角色、权限模型，包含了2种情况：
ⅰ用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。
ⅱ用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。
注：权限管理涉及到子角色、继承、互斥、数量约束等逻辑，在此不一一展开。
图21：RBAC模型
总结：当角色的权限边界较为清晰时，可考虑使用多对一的权限设计。若不满足该条件，则最好使用多对多的权限体系（避免大量用户都要独立建设角色，变成一对一的权限管理），保障系统的可扩展性。
例：小代既是销售运营，也负责财务对账，那小代就应该同时拥有销售运营与财务对账两个角色的权限。
③ 卓有成效的业务运营
1. 业务的增长解构
NDR，增长的试金石
图22：ARR示意图
如上图，客户的年度经常性收入（Annual Recurring Revenue）可按用户新增年份划分为不同的颜色，可以清晰看到，一个有好的收入留存（Net Dollar Retention）的企业软件产品，其增长极大程度由老客户来推动，每年新客的获客压力很小。
注：收入留存Net Dollar Retention，指存量客户在新一年产生的所有收入（包括原有模块的续费与增购，新模块的增购）作为分子，这批客户在前一年产生的所有收入作为分母，两者相除。
商业模式决定增长策略
业务增长由老客户留存收入+新客户收入组成。
Ⅰ 留存周期很短的业务，大量成本都会花在了销售费用上，需要持续拉新才能保持增长。例：英语培训、婚庆服务。
Ⅱ 留存周期很长的业务，收入可以更多转化到技术、产品迭代中去，提升自己的核心竞争力。例：协同办公、知识管理、云服务。
例：Atlassian 的敏捷管理矩阵有“ Trello、JIRA、Confluence”三款产品，其超高的留存率反映了产品的粘性。根据2019年的投资者报告内容，Atlassian为花费5万美元或以上的客户实现了98%的保留率，其中90%的客户购买了3种或3种以上的产品。
图23：Atlassian的留存、购买数据
总结：当商业模式的留存能力较高时，成本投入可以更多倾斜到存量客户的价值满足上，用存量支撑增长的基本面。反之，只能将预算都投入到持续的拉新中去，此时存量客户的体验保障往往成为一个难题，婚纱摄影就是典型的销售大于服务，套路繁多，意图一次榨干的行业。
2. 业务运营的设计概述
业务运营是集增长、服务、数据、研究于一体的运营体系。不仅要对外提供营销策略、客户服务，更需要对内交付决策支持、用户反馈。
图24：业务运营架构图（示例）
对外，业务运营是营销策略、客户服务、培训支持等。要实现业务的增长目标，并为客户提供更好的的业务体验。
对内，业务运营是流程管理、数据分析、行业/用户/政策研究及运营支持，目标是保障业务运作的高效、流畅，保障业务决策的有效性、合理性。
如何实现增长？
业务增长主要还是围绕营销策略展开的，包括产品定价及搭售方案、销售策略。
Ⅰ 定价与搭售
(1) 中小客户标准品，要参考竞品的定价模式，实施与业务节奏匹配的的搭售策略、促销策略。对于高续费率的产品，可在拉新上投入更多预算。
例：假设Teambition给企业版购买者提供知识积累产品Thought半年10人的高级权限，由于知识积累属于切换成本很高的产品，灰度测试续费率约75%（假设），综合收益依然可观，搭售方案可行。
(2) 对于大客户，要有完善的报价机制。包括：客户档案建设、个性化需求搜集、决策人影响（要避免花了很大力气BD，没找对实际决策人）、方案设计与成本评估。
图25：Teambition价格方案
Ⅱ 销售策略
要开展全国性的业务，销售资源的配置是核心决策点，关系到整个业务的成本与产出。
(1) 盘点：围绕增长目标，设定销售指标的拆解逻辑。盘点存量客户的产出预期，评估增量客户规模，并梳理潜在客户列表及对应的HC需求。
(2) 合作：销售与事业部的组织关系，决定了业务在前台推进的效率。
如果销售体系闭环在事业部内部，产研、运营与销售的合作，主要围绕KA需求的敏捷支持以及高优先级Feature List的迭代交付，围绕研发资源的配置，需要高频沟通。
如果销售属于中台体系，承接各事业部需求，业务需要先确认销售的资源配置方案，包括：绩效考核的逻辑、业务的激励规则等等。围绕销售资源的配置，需要重点沟通。
(3) 路径：是先从单一客户突破，还是从重点区域突破？要基于业务实际的竞争情况考虑。如哈罗单车初期就避开了一线城市，在二三线城市站稳了市场，最后切入一线城市。
(4) 模式：直营服务品质更好，为了拿下重点、核心城市，可能会使用直营模式；对于业务量小、基数庞大、单个价值低的中小型城市，可能会使用成本更优、速度更快的加盟模式。
构建服务体系
C端产品，单个客户的流失对平台损失不大，客服体系可能会侧重构建标准、广覆盖的服务能力，尤其要在成本与收益面前做再平衡（例：印象笔记甚至没有电话客服，客服流程通过邮件处理）。
但由于B端产品的客户价值相对更大，需要更完整、深度、个性化的服务，才能提升客户留存水平。为了实现这个目标，至少需要满足三点：
Ⅰ 让客户方便地找到我们，搭建覆盖度高的服务窗口。
Ⅱ 搭建售前、售中、售后多层次的服务能力。
Ⅲ 实现数据闭环，便于高效、全面地评估服务质量。
图26：搭建服务体系的要点
客户服务不单单是一个体系问题，更是一个文化问题。
如何看待用户的反馈？是真的闭环处理，还是记录后石沉大海？客服的应急权限有多大？
这些问题的背后，体现了业务负责人对用户的真实态度。
3. 面向经营的数据体系
数据体系核心是面向经营提供业务观察、业务诊断的能力，它的结构类似MVC结构，前端是可视化的控件，中间层是数据仓库以及对应的报表结构，底层是业务分析的体系。
图27：业务的数据体系
业务分析体系（核心）
分析的目的是诊断、监控。业务分析可以大概分为2个模块：什么样的数据表现是健康的？哪些项目需要重点监控？
根据2个模块的具体内容，再结合业务构建指标体系：
Ⅰ 业务健康度指标：判断业务是否健康发展的核心指标集合，任一指标出现问题都预示着业务存在较大的健康风险。一般健康度指标都有明确的目标，便于做业务发展的过程管理。
Ⅱ 分析型指标：业务分析逻辑链路上的过程指标，以及其他需要重点监控的指标。由于业务不同阶段的侧重点不一样，监控的方向也各不相同。
例：业务冲刺阶段，业务负责人希望重点关注客服质量，避免高成本拉来的客户因为客服质量不满意而流失。
图28：业务分析体系框架（示例）
数据仓库/报表体系
有了业务分析逻辑，就可以开始搭建业务报表了，这是一个从想→做得过程。在MVC的架构中，前端层、业务逻辑层都会有数据上报，形成数据库表/日志。
图29：数据的形成
了解产品数据结构的业务运营，对分析的实现才有更强的判断力，也更能够理解各系统间的交互逻辑。
所以，在产品设计初期，业务运营就需要和业务逻辑层（后端）沟通各个服务、系统的数据记录的字段、规范，避免业务所需的关键数据漏存。
图30：业务数据的表结构（示例）
通常，业务分析体系的指标，往往需要关联多张核心表关联计算，例如：用户表、支付表甚至其他业务的表，单一业务方难以实现。为了解决这个问题，大数据部门通过拉取各业务的数据，经过流程调度、数据清洗、数仓建表，最终提供数据服务（例：可视化平台、用户标签查询、报表服务......），为业务方赋能。
在数仓的建设过程中，最好能有懂业务、数据结构的业务运营与大数据工程师共同建设，保障“业务分析逻辑”→“技术实现”的信息传导足够对称。
图31：数仓整体的技术架构（示例）
数据可视化
数据可视化，实际是将数据信息以更低的阅读成本提供给数据消费者。不同类型的数据适合不同的展示方式。不必过度追求炫酷的效果，时刻关注它的核心价值是“更低成本的阅读”。
推荐工具：Tableau
图32：Tableau展示案例（Hanah Anderson、Matt Daniels）
④ 敏捷的项目管理体系
一个业务要持续前行，有两种工作要做：
重复性工作，例：日常的数据监控、客服等运营工作。
项目型工作，通过完成一个新项目改善产品/运营，从而让业务发展得更好。
图33：业务与项目的关系
互联网行业，业务从0~1的过程中，
需求变化很快、要求整个组织足够敏捷、高适应性地去为组织提供服务。
团队规模的扩张，没有体系化的项目管理，将出现：“信息不对称、进度把控弱、协同成本高、边界不清晰”等问题。
图34：项目管理的急迫性
1. 敏捷的业务运营
如同产品是迭代出来的，运营要持续优化业务，也必须采取迭代交付的模式，以应对多变的业务需求。
图35：迭代式开发的优势
我通过3年的实测与迭代，验证了“建设以Scrum（敏捷）为核心的项目管理体系，确实能有效提升运营团队的自我管理、高效沟通、适应变化的水平”。
下面我会简单介绍下敏捷运营的方法。
2. 什么是Scrum？
Scrum一词来自橄榄球运动中的“并列争球”。在软件开发历史过程中，Scrum 先驱们将 Scrum 这个词的隐喻应用于软件开发。它是一套轻量级的核心价值观、原则和实践，统称为 Scrum 框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。
在这个框架下，我们可以检验团队是否符合 Scrum 原意的要求：
1. 团队成员是否有共同目标？
2. 团队成员是否开诚布公地紧密合作？
3. 团队成员是否经常检视和调整？
4. 团队成员是否各自发一颗球（各做各的用户故事等），各自努力往后场冲刺以争取个人绩效？
......
图36：Scrum Process
3. Scrum的运营实践
Scrum的运营实践，借鉴了Scrum在产品开发上的应用。
它是一种有计划、持续迭代的运营策略。通过多次交付来应对需求的变化，逐步得到一个完善的解决方案，并影响业务的结果。
图37：Scrum运营实践概述
(1) Scrum运营有哪些角色？
Business Owner(BO)：业务负责人
职能：负责勾勒业务愿景、为业务指明方向、计划节奏、考虑成本等。他一方面要理解用户、利益干系人的需求。另一方面，对正在推进的业务，要和产品、运营、研发团队紧密合作，验收各方交付出来的产品。
Scrum Master(SM)：敏捷教练
职能：Scrum Master 既是 Scrum 团队的教练，是团队服务型领导、“保护伞”和“清道夫”。
Ⅰ 负责指导团队在通用的 Scrum 框架上建立并遵循自己的过程，帮助每个参与者理解并乐于接受 Scrum 的价值观、原则和实践；
Ⅱ 充当教练、在过程方面发挥教导作用，帮助团队以及组织中的其他人指定合适的高绩效、有组织特色的 Scrum 方法；
Ⅲ 负责保护团队不收外部干扰和障碍，（在个人无法有效解决遇到的障碍时）发挥领导作用，清楚阻碍团队生产率的障碍；
Ⅳ 他是领导者，不是管理者。
Operation Team(OT)：运营团队
职能：负责确定如何交付业务负责人要求的成果，负责运营的策略设计、数据分析等工作；团队成员整体具备的技能，需要足以实现业务负责人要求交付的业务价值。
Ⅰ 业务计划（ Business Planning）
每月的OKR评审会议将产出“业务代办列表、OKR”。
主R：业务负责人（BO）
待办业务列表：评估业务工作及优先级。
OKR：评估一段时间内业务的目标及关键结果。
图38：Uber的OKR示例
Ⅱ 冲刺计划（Sprint Planning）
主R：Scrum Master
基于“OKR、业务待办列表”，Scrum Master需带领敏捷运营团队，将“业务待办列表”中的工作拆解为下一个冲刺(Sprint)的“工作包”列表。
工作包是一个有明确时间节点的可交付成果。
图39：业务待办事项与工作包的差异
Ⅲ 冲刺（Sprint）
主R：Scrum Master、运营团队
时间盒
以时间盒（例：2个自然周）为单位进行冲刺（Sprint），持续交付工作包。在每个时间盒结束后，重新评估一次“业务待办事项列表”所需交付的工作包是什么，以适应业务的变化。
图40：业务待办事项与工作包的差异
看板
使用“看板”作为“信息发射源”，同步各项目冲刺（Sprint）的工作包状态。
图41：Teambition看板
Ⅳ 冲刺回顾（Sprint Retrospective）
主R：运营团队
每个月结束（约2个Sprint），结合OKR做冲刺回顾（复盘）。回顾的目的是：
评估目标及达成情况
遇到了哪些问题？有什么亮点？
总结经验教训、客观规律
总结接下来冲刺（Sprint）的改善项
团队进行充分的交流、沟通
参考文献：
《2019年中国报告》，麦肯锡全球研究院，2020年；
《企业服务创业者必读：影响公司估值和发展的核心指标 | GGV投资笔记第十一期》，GGV纪源资本；
《俞军产品方法论》，俞军，中信出版社，2019年；
《决胜B端，产品经理升级之路》，杨堃，电子工业出版社，2019年；
《两万字谈谈如何使用 Scrum 框架进行敏捷开发》，@yishuailuo，2017年；
《RBAC模型：基于用户-角色-权限控制的一些思考》，公众号：PM珣玗琪。
本文为作者独立观点，不代表鸟哥笔记立场，未经允许不得转载。
《鸟哥笔记版权及免责申明》 如对文章、图片、字体等版权有疑问，请点击 反馈举报
Powered by QINGMOB PTE. LTD. © 2010-2022 上海青墨信息科技有限公司 沪ICP备2021034055号-6
我们致力于提供一个高质量内容的交流平台。为落实国家互联网信息办公室“依法管网、依法办网、依法上网”的要求，为完善跟帖评论自律管理，为了保护用户创造的内容、维护开放、真实、专业的平台氛围，我们团队将依据本公约中的条款对注册用户和发布在本平台的内容进行管理。平台鼓励用户创作、发布优质内容，同时也将采取必要措施管理违法、侵权或有其他不良影响的网络信息。
一、根据《网络信息内容生态治理规定》《中华人民共和国未成年人保护法》等法律法规，对以下违法、不良信息或存在危害的行为进行处理。
1. 违反法律法规的信息，主要表现为：
1)反对宪法所确定的基本原则；
2)危害国家安全，泄露国家秘密，颠覆国家政权，破坏国家统一，损害国家荣誉和利益；
3)侮辱、滥用英烈形象，歪曲、丑化、亵渎、否定英雄烈士事迹和精神，以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉；
4)宣扬恐怖主义、极端主义或者煽动实施恐怖活动、极端主义活动；
5)煽动民族仇恨、民族歧视，破坏民族团结；
6)破坏国家宗教政策，宣扬邪教和封建迷信；
7)散布谣言，扰乱社会秩序，破坏社会稳定；
8)宣扬淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪；
9)煽动非法集会、结社、游行、示威、聚众扰乱社会秩序；
10)侮辱或者诽谤他人，侵害他人名誉、隐私和其他合法权益；
11)通过网络以文字、图片、音视频等形式，对未成年人实施侮辱、诽谤、威胁或者恶意损害未成年人形象进行网络欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法规禁止的其他内容；
2. 不友善：不尊重用户及其所贡献内容的信息或行为。主要表现为：
1)轻蔑：贬低、轻视他人及其劳动成果；
2)诽谤：捏造、散布虚假事实，损害他人名誉；
3)嘲讽：以比喻、夸张、侮辱性的手法对他人或其行为进行揭露或描述，以此来激怒他人；
4)挑衅：以不友好的方式激怒他人，意图使对方对自己的言论作出回应，蓄意制造事端；
5)羞辱：贬低他人的能力、行为、生理或身份特征，让对方难堪；
6)谩骂：以不文明的语言对他人进行负面评价；
7)歧视：煽动人群歧视、地域歧视等，针对他人的民族、种族、宗教、性取向、性别、年龄、地域、生理特征等身份或者归类的攻击；
8)威胁：许诺以不良的后果来迫使他人服从自己的意志；
3. 发布垃圾广告信息：以推广曝光为目的，发布影响用户体验、扰乱本网站秩序的内容，或进行相关行为。主要表现为：
1)多次发布包含售卖产品、提供服务、宣传推广内容的垃圾广告。包括但不限于以下几种形式：
2)单个帐号多次发布包含垃圾广告的内容；
3)多个广告帐号互相配合发布、传播包含垃圾广告的内容；
4)多次发布包含欺骗性外链的内容，如未注明的淘宝客链接、跳转网站等，诱骗用户点击链接
5)发布大量包含推广链接、产品、品牌等内容获取搜索引擎中的不正当曝光；
6)购买或出售帐号之间虚假地互动，发布干扰网站秩序的推广内容及相关交易。
7)发布包含欺骗性的恶意营销内容，如通过伪造经历、冒充他人等方式进行恶意营销；
8)使用特殊符号、图片等方式规避垃圾广告内容审核的广告内容。
4. 色情低俗信息，主要表现为：
1)包含自己或他人性经验的细节描述或露骨的感受描述；
2)涉及色情段子、两性笑话的低俗内容；
3)配图、头图中包含庸俗或挑逗性图片的内容；
4)带有性暗示、性挑逗等易使人产生性联想；
5)展现血腥、惊悚、残忍等致人身心不适；
6)炒作绯闻、丑闻、劣迹等；
7)宣扬低俗、庸俗、媚俗内容。
5. 不实信息，主要表现为：
1)可能存在事实性错误或者造谣等内容；
2)存在事实夸大、伪造虚假经历等误导他人的内容；
3)伪造身份、冒充他人，通过头像、用户名等个人信息暗示自己具有特定身份，或与特定机构或个人存在关联。
6. 传播封建迷信，主要表现为：
1)找人算命、测字、占卜、解梦、化解厄运、使用迷信方式治病；
2)求推荐算命看相大师；
3)针对具体风水等问题进行求助或咨询；
4)问自己或他人的八字、六爻、星盘、手相、面相、五行缺失，包括通过占卜方法问婚姻、前程、运势，东西宠物丢了能不能找回、取名改名等；
7. 文章标题党，主要表现为：
1)以各种夸张、猎奇、不合常理的表现手法等行为来诱导用户；
2)内容与标题之间存在严重不实或者原意扭曲；
3)使用夸张标题，内容与标题严重不符的。
8.「饭圈」乱象行为，主要表现为：
1)诱导未成年人应援集资、高额消费、投票打榜
2)粉丝互撕谩骂、拉踩引战、造谣攻击、人肉搜索、侵犯隐私
3)鼓动「饭圈」粉丝攀比炫富、奢靡享乐等行为
4)以号召粉丝、雇用网络水军、「养号」形式刷量控评等行为
5)通过「蹭热点」、制造话题等形式干扰舆论，影响传播秩序
9. 其他危害行为或内容，主要表现为：
1)可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好影响未成年人身心健康的；
2)不当评述自然灾害、重大事故等灾难的；
3)美化、粉饰侵略战争行为的；
4)法律、行政法规禁止，或可能对网络生态造成不良影响的其他内容。
二、违规处罚
本网站通过主动发现和接受用户举报两种方式收集违规行为信息。所有有意的降低内容质量、伤害平台氛围及欺凌未成年人或危害未成年人身心健康的行为都是不能容忍的。
当一个用户发布违规内容时，本网站将依据相关用户违规情节严重程度，对帐号进行禁言 1 天、7 天、15 天直至永久禁言或封停账号的处罚。当涉及欺凌未成年人、危害未成年人身心健康、通过作弊手段注册、使用帐号，或者滥用多个帐号发布违规内容时，本网站将加重处罚。
三、申诉
随着平台管理经验的不断丰富，本网站出于维护本网站氛围和秩序的目的，将不断完善本公约。
如果本网站用户对本网站基于本公约规定做出的处理有异议，可以通过「建议反馈」功能向本网站进行反馈。
(规则的最终解释权归属本网站所有)