本文系该系列的第5篇，内容整理自华为ITR流程变革管理实战老兵分享，其深耕华为海外区域销售与客户服务一线，深度参与华为 LTC、ITR 核心变革项目，亲历服务体系全周期迭代

在上一期关于ITR流程的整体介绍中，我们讨论了华为ITR落地的策略与步骤。

但真正进入流程设计阶段，一个很现实的问题就出现了：同样是 ITR，为什么一套流程放到不同业务里，效果却完全不同？

ToB 业务可能觉得流程不够灵活，核心网络发生故障，客户业务已经受到影响，流程却还在按正常路径流转。

ToC 业务则可能觉得流程太重，客户只是要求更换一个零件，却要经过复杂的技术判断和专家处理。

问题在于ToB 和 ToC 面对的是完全不同的客户与业务场景。从华为的 ITR 体系来看，两类业务虽然共享“受理—处理—关闭”的主流程，但到了具体流程、组织分层，以及与研发体系的接口方式上，都有明显差异。

客户特点

流程设计的底层起点

流程是业务的映射，设计流程之前必须先看清服务的对象。ToB 与 ToC 的差异，决定了后续流程模块与管理规则的走向。

数量少但单点影响大：以华为运营商业务为例，全球核心客户仅数百家。但客户依靠设备生产运营，网络一旦瘫痪将直接影响业务，对时效性和稳定性要求极高。

问题复杂且需深度闭环：故障不仅要求迅速恢复，解决后还需由研发和生产部门复盘，找出隐患，消灭于未然。

需要专属服务：每个大客户通常都配备对应的大客户服务组织和服务经理进行全生命周期管理。

ToC 的客户数量可能达到几十万、上千万甚至更高。面对这样的规模，企业不可能为每一个客户配置专属服务组织，也不可能把大量标准化问题全部交给专家处理。

因此，ToC 更强调规模化承接、标准化处理和服务体验，维修、换货、预约、自助服务等，都可以通过标准化流程承接。

所以，两类业务的流程差异，其实从客户规模和业务特点上就已经决定了。

主流程相同

但具体流程要跟着业务走

从最基本的 ITR 结构来看，ToB 和 ToC 都可以归纳成受理 → 处理 → 关闭。但这只是主干，真正进入业务流程之后，差异会迅速放大。

ITR流程体系常见的四大模块包括管理技术请求、管理非技术服务请求、管理备件服务交付、客户声音管理。

但这里有一个非常重要的提醒，并不是每一家企业都需要完整建设所有模块。

有的软件企业没有备件管理；有些企业非技术服务请求很少，也可能把技术和非技术服务请求合并管理。最终怎么设置，还是要结合企业战略定位、业务特点和商业模式来决定。

ToB 除了标准的技术服务请求流程，还需要针对复杂业务场景建立专项流程。比如：

紧急恢复流程

面对网络瘫痪等重大故障，不能按照普通请求的节奏处理，而要建立独立的快速恢复机制。这里真正重要的不是某一个固定时限，而是针对高影响业务建立区别于普通请求的处理机制。

网络变更流程

加单板、换基站等操作可能发生在客户业务运行过程中，因此不仅要完成服务动作，还要尽量降低对客户运营的影响。

第三方设备问题处理流程

服务器、数据库等第三方设备出现问题时，需要明确责任边界和支撑流程，解决跨厂商、跨专业的问题。

升级管理流程

复杂问题不可能全部由一线解决，因此需要明确什么时候升级、升级到谁，以及谁负责推动解决。

ToB 的流程设计，本质上是在解决，复杂问题如何快速找到正确的人，并形成专业协同。

ToC 则会更多出现维修换货、预约服务、自助服务、服务供应商等场景。这些流程的共同特点，是需要在大量客户同时进入服务体系的情况下，保持相对稳定的服务效率和体验。因此，ToC 更强调标准化、规模化和客户体验。

同样一个产品问题，在不同业务模式下，可能对应完全不同的处理方式。这也是为什么不能简单拿 ToB 的服务流程去套 ToC，反过来也一样。

组织架构

都是三层，但一个直达研发

流程设计到最后，一定会回到一个问题：谁来解决？ToB 和 ToC 的三层组织架构虽然形态相似，但三层背后的能力逻辑并不一样.

ToB 通常形成比较清晰的三级专业组织。

一线更接近客户，通常位于区域维护团队，负责解决常见问题，并在专家支持下处理一般疑难问题。

二线通常位于总部，由技术能力全面、经验丰富的专家组成，负责指导和协助一线解决疑难问题。

三线则进入研发体系，但独立于主线版本开发团队，主要处理产品维护、缺陷、质量以及功能、性能、版本 Bug 等问题。

这意味着当一个问题已经超出服务组织常规解决能力时，可以继续进入产品和研发体系。因此，ToB 的 ITR 实际上连接了区域服务能力 → 专业专家能力 → 产品研发能力。

这里有一个关键的管理标尺——991 法则：一线工程师应解决 90% 以上的问题，最多向二线提交 10%；二线专家应解决其中的 90%，最多向三线提交 10%。如果达不到 991，就要追溯是员工技能不足、人员数量不够，还是产品质量本身存在问题。

ToC 同样可以形成三层服务组织，但角色定位不同，L1 服务顾问 → L2 服务专家 → L3 服务工程师。

L1 服务顾问：面向客户的第一责任人，掌握通用知识与服务礼仪，负责端到端跟踪。

L2 客服专家：问题答案的最终关闭者，面向客户的最终负责人。

L3 服务工程师：问题解决方案的最终提供者，但不直接面向客户。

关键差异在于，ToC 的三层组织不直接覆盖研发。只有当 L3 确实无法解决时，才形成产品问题清单与研发沟通。除非是影响面极广的重大事件，否则非紧急问题通常会放到下个版本去实现。

ToB 的三线则是研发体系的一部分，问题直达产品维护团队，解决效率天然不同。

ITR 不是孤岛

是与 LTC、IPD 的协同接口

无论 ToB 还是 ToC，ITR 都不是独立运行的。在华为的价值链体系中，ITR 与 IPD、LTC构成闭环：

ITR → LTC：服务人员是和客户关系最密切的岗位，在服务过程中获取的客户需求和商机线索，通过接口传递给销售体系，往往比销售人员更能影响客户对产品的感知。

ITR → IPD：产品问题和技术问题在 IPD 中归类提炼，成为产品质量和功能提升的重要来源。

ToB 和 ToC 的 ITR 流程设计差异，本质上是业务特点驱动的。客户数量决定服务组织形态，时效要求决定紧急恢复流程的有无，技术复杂度决定是否覆盖研发，货值高低决定维修还是换货，结算方式决定验收流程放在哪一步。

不是先有流程模板再把业务往里套，而是先看清楚客户是谁、业务有什么特点，再设计对应的流程和组织。