第五章 ITR：从问题受理到解决确认
一芥智能研究院｜《企业数智化转型研究报告》上册｜初稿 v11.0｜2026年10月18日按模板改写
产品交到客户手中以后，仍可能出现故障、操作困难或交付遗留。客户需要供方理解当前影响，组织专业处理，并帮助自己继续原来的工作。客服已经回复、研发已经修改，说明相应动作完成；这些动作是否解决了客户问题，还要追到实际使用和验证。
ITR（Issue to Resolution，从问题到解决）用来观察这段工作。本章以客户原任务恢复或约定问题得到确认解决为结果，沿问题受理、专业接手、排查处置、客户验证和预防改进展开。IPD提供产品版本与支持依据，LTC提供合同承诺与剩余责任，问题处理结果再返回相关业务，支持后续改进。
本章索引
- 5.1 业务现状与问题：回复之后，客户的工作恢复了吗
- 5.2 原因分析：为什么处理动作没有解决客户问题
- 5.3 整体思路：围绕客户工作恢复组织处置与预防
- 5.4 场景应用：数智化方案怎样支持问题解决
- 5.5 效果检验与本章小结
5.1 业务现状与问题：回复之后，客户的工作恢复了吗
ITR负责在约定服务范围内受理客户问题、组织处置并确认结果，既包括咨询与使用指导，也包括故障、异常及交付遗留。简单问题可以在入口处理，需要多方参与的问题则由客服、产品、研发、履约或现场人员继续协作。华为2012年报将客户问题管理与按契约解决问题、支撑客户业务连续性、推动产品和管理改进联系起来；公司治理说明提供流程责任及关键控制点的管理参照。本章借用这些目的与机制，具体工作划分和问题分析为本报告整理。
工作从客户提出问题开始。客户可能通过销售、客服、门店或合作方描述现象，提供照片、日志或操作经过。入口人员了解谁的哪项工作受到影响、何时发生、此前做过什么，再核对相关产品、现场版本与服务责任。来件与初步处理留在聊天、邮件、Excel或工单中，作为后续接手的背景。
能够按有效资料回答的咨询，由接待人员说明步骤并了解客户是否能够继续操作；需要专业处理的，由牵头人组织接手。牵头人将客户影响、现场条件、已做检查与待解决事项交给产品、研发或履约人员，协调专业资源、备件、现场窗口和客户配合，并向客户反馈下一步安排。
专业人员取得背景后，结合产品资料、历史问题和现场证据开展排查，比较可能原因，通过检查逐步核实。客户工作受阻时，还会比较临时恢复与长期修正：先采用替代操作或临时配置恢复使用，还是直接修改产品、补发或调整现场。执行者留下实际动作和结果，必要的产品开发交IPD继续安排，合同交付与剩余义务仍由LTC跟踪。
处理以后，内部检查先确认原现象、相关功能及新影响，再由客户实际使用者验证原来受阻的任务。牵头人核对客户接受什么、还有什么未完成，登记观察、后续修正及剩余责任，满足关闭条件后结束本次服务记录。确认有效的办法可以进入知识资料，重复问题则交产品、工艺或相关流程负责人判断是否改进。
这段工作的前端可能已经留下工单，却仍反复向客户补问，或到专业人员接手时才发现版本、影响和服务范围不清。问题转发到多个群里，各方都看到了消息，却没有人确认能开始；夜间来件或集中故障又可能等待专业资源，客户只得到反复更新的进度。
进入排查以后，也可能按相近案例反复尝试，却没有查清新问题的条件；临时恢复后，长期修正迟迟无人继续。研发记录已经修复，现场仍未更新；工单已经关闭，客户原来的工作还没有恢复。有效办法虽然入库，后续人员仍从头排查，同类问题再次出现，产品和流程改进也未进入实际使用。
这些问题分布在受理、接手、处置和确认的不同位置。观察ITR的现状，需要沿同一问题看到客户受到什么影响、工作停在哪里、已有动作产生了什么结果，再分析为什么处理持续开展，客户问题仍未得到可靠解决。
5.2 原因分析：为什么处理动作没有解决客户问题
5.1中的落差依次表现为背景与影响不清、专业接手等待、排查和修复反复、内部完成与客户结果脱节，以及后续问题持续发生。它们都可能延长客户受影响的时间，但需要补足的条件不同，应沿实际经过分别追查。
5.2.1 来件已经记录，为什么还要反复补问、错判影响
客户最初提供的通常是自己看到的现象，专业排查还需要实际对象、版本、发生条件和已尝试办法。如果入口只记录一句“系统不能用”，没有了解哪项工作受阻、影响多少对象，后续便难以判断紧急程度，也无法决定由谁处理。客户的原因猜测若直接写成结论，还可能使排查从错误方向开始。
材料即使已经取得，也可能在整理时丢失关键区别。聊天摘要省略客户原话，产品系统里的最新发布版代替现场版本，日志时间与故障时间没有对应，都会使一份看似完整的工单缺乏可核对依据。接手者只有重新找客户、销售或现场人员核实，才能开始工作。
重复补问还受到整理投入的影响。多入口来件需要逐件阅读、关联与更新，集中发生时先回复、后补录，容易遗漏后续变化。因此，应区分客户尚未提供、内部已有却未找到，以及已经整理但失真的资料；这些情况都会造成等待，却具有不同原因。
5.2.2 问题已经转交，为什么专业处理仍在等待
转交说明消息到达，专业接手还需要当前背景、明确任务和可用资源。如果只把客户拉进群、转发长聊天，接收者仍不知道需要排查什么、交出什么、由谁继续联系客户。一个问题拆给多个部门后，没有共同牵头，资料缺失和职责分歧就容易在反复退回中延续。
任务明确以后，承接容量也可能限制处理。常见咨询与复杂故障都等待同一位专家，夜间没有合适接手者，现场检查依赖客户窗口或备件，都会造成排队。入口回复加快后，积压还可能移动到专业排查、现场执行或客户验证，整段周期未必缩短。
这些等待若统一标为“处理中”，负责人便看不到究竟缺资料、缺资源，还是尚未取得客户配合。服务时限临近时反复催办，也未必能改变受阻条件。需要回查分派、接受、开始与反馈的时间及原因，才能辨认责任没有落实和处理条件尚不具备两类差距。
5.2.3 办法已经尝试，为什么仍在反复修复
相似现象可能来自不同版本、配置、网络或现场条件。如果只检索到一条相近案例就采用原办法，没有比较支持与不符的证据，处理便容易停在连续试错。一次操作后现象暂时消失，也可能被当成原因已经确认，下一次遇到相同条件又重新发生。
客户工作急需恢复时，临时办法具有价值，但它解决的范围可能有限。如果恢复与长期修正没有分开约定，临时配置生效以后，继续排查、产品修改和现场更新就可能失去责任人。相反，所有问题都等待永久修复，也可能延长本可缩短的客户停顿。
实际动作没有记录，还会使后续判断失去依据。执行使用了哪个环境和版本、操作是否成功、是否产生新影响都不清楚时，下一人无法判断继续、恢复原状还是重新排查。反复修复因而既可能源于原因未核实，也可能源于恢复与修正安排脱节，或执行结果无法验证。
5.2.4 内部已经完成，为什么客户仍然受阻
内部完成与客户结果之间还有部署、采用和实际任务验证。研发修改通过测试，只说明该环境中的检查完成；现场可能还未更新，客户可能没有执行新的步骤，相关依赖也可能仍有问题。如果直接以内部状态结束服务，客户原来受阻的工作便没有得到检验。
客户确认的范围也可能含糊。“收到”“先这样”可能表示知道安排、接受临时恢复，或同意继续观察，含义并不相同。没有事先约定验证任务、确认人和观察条件，牵头人容易把沟通回应当成解决接受，后续再次求助又成为一张新工单。
关闭数量或处理时长如果只统计内部结束记录，未确认、等待和重新打开的问题就可能从视野中消失。表面周期缩短，客户实际停顿仍在延续。判断这类差距，要把原问题、实际执行和客户任务结果放在一起，分别确认恢复、解决及剩余事项处于什么状态。
5.2.5 经验已经入库，为什么同类问题没有减少
处理完成以后，记录中往往混有曾经尝试的办法、原因假设与确认有效的措施。若整理知识时没有区分这些内容，也没有说明适用版本和条件，后续人员即使找到条目，仍要重新判断能否采用。资料数量增加，未必减少重复排查。
重复现象还需要核实是否同因。只按关键词合并，可能把不同问题算在一起；只按工单分别处理，又可能看不到同一产品、批次或条件的共同影响。缺少同因证据，产品与流程负责人便难以判断应该改什么、覆盖哪些对象及投入多少。
原因确认以后，改进是否进入使用仍是另一段工作。产品决定未返回服务人员，知识改了但旧办法仍在用，新版本发布却未到客户现场，都会使同因问题继续发生。复盘停在提出建议或完成发布，尚未接到岗位与客户采用，是预防效果迟迟不出现的另一原因。
沿这些原因可以看到，可靠解决需要当前事实、实际接手、有依据的处置和客户验证共同成立，预防则继续依赖有效方法与改进的采用。整体方案需要把这些要求组织起来，再为持续执行提供可用工具与资料。
5.3 整体思路：围绕客户工作恢复组织处置与预防
ITR的整体改进，以客户原任务恢复或约定问题得到确认解决为共同结果，同时落实剩余责任并减少同因影响。各岗位围绕这一结果配合，将处理要求落实为可交付、可使用的数智化方案。
5.3.1 围绕客户结果组织问题处理
先确定各方共同采用的问题与解决依据。客户说明受阻任务和现场情况，业务人员核对服务范围，专业人员确认产品与技术条件，牵头人据此约定本轮要解决什么、怎样验证、由谁确认。客户原话、已核实事实、原因假设和未知内容分别保留，后续判断随新证据更新。
需要协作时，由牵头人沿同一问题持续组织工作。受理交出可开始排查的背景，专业人员确认接手、产物和反馈安排，执行交出实际动作与结果，验证回到原问题。资料不足返回核实，资源冲突、现场窗口和客户配合分别明确协调责任；处理次序随客户影响与可用容量调整，避免一处提速后继续在下游等待。
恢复与长期修正分别安排、相互接续。客户工作受阻时，比较先恢复与直接修正的时间、可靠性和限制，落实各自的执行、验证及期限。客户接受临时恢复以后，确需的长期修正继续有人承担；修正交IPD安排时，决定返回牵头人，现场采用与客户验证仍持续跟踪。一个问题影响多个客户时，各自的影响、采用和确认分别保留。
客户结果确认后，再把有效办法和同因证据用于后续工作。专业人员确认知识适用范围，产品、工艺及相关流程负责人接收改进请求，记录采纳、暂缓或继续核实的决定。改动落实到产品、交付预检、服务方法或市场表达，并确认相关岗位与客户采用，再观察后续重复影响，形成本次处置与下一轮预防的接续。
5.3.2 数智化方案的建设内容与交付物
ITR数智化方案应明确企业收到什么、能够用它完成哪些工作。交付范围结合主要问题和已有系统确定，以下七类成果共同支持从受理到客户确认，再到改进采用的工作。
业务与数据标准包。 交付经确认的ITR流程、受理与专业接手要求、影响和优先级规则、恢复与解决标准，以及关闭条件和剩余事项移交要求。配套问题、客户、产品、现场版本、合同、检查、动作和验证等对象的数据字典、标识关系、状态与指标口径，说明原话、事实、假设、未知内容怎样记录，由谁核实与维护。典型问题及判定样例用于岗位填写、接手和验收。
ITR数据仓库。 交付问题与影响、接手等待、排查处置、客户验证和重复发生等主题的数据模型、来源映射、接入更新任务及整理后的首批数据。客户、产品、版本、合同与项目相互关联，可以从一张工单回查现场与处理经过，也可以比较同一版本或批次的重复问题。配套数据质量检查、更新时间与查询权限；各客户的结果和同因归并分别保留，已有数据平台可以承载相应建设。
产品与服务知识库。 交付经整理确认的产品说明、版本限制、服务条款、常见问题、检查步骤和有效处置办法，保留原文依据、适用范围、失效条件与维护责任，提供检索和引用功能。当前问题中的待证假设保留在处理记录，验证有效的方法经专业确认后进入知识库；资料变化能够定位需要复核的条目和在用方法。原文可留在原系统，通过索引关联使用。
场景应用与运行看板。 按选定范围交付问题受理与影响判断页面、专业协作与排查工作台、处置及客户验证表单、关闭与改进跟踪应用，明确岗位可以进行哪些操作、资料如何引用、结果保存在哪里。看板按共同口径展示受影响对象、实际接手、等待原因、恢复与确认解决、剩余修正及重复发生，并能回查具体问题。配套角色权限和真实样本验证记录，供人员处理与负责人协调资源。
数据接口与系统集成。 交付连接聊天或来件入口、工单、客户与合同、产品版本、现场记录及研发任务的接口或适配程序，配套对象与字段映射、读写权限、同步配置及联调记录。使问题应用能够取得当前合同与现场依据，研发修正进度返回原问题，执行和客户验证更新对应记录并进入仓库分析。约定各类事实的维护系统，保留失败记录、重试条件和异常接手，支持跨工具查询、传递与回写。
智能体与自动工作流。 交付已配置的问题整理、接手背景准备、证据排查辅助、方案比较或验证检查智能体，明确各项任务的输入输出、可用资料与工具、适用条件、授权和人工确认节点。配套可执行的来件、接手、证据更新、批准处置、到期观察和改进采用工作流，连接查询、服务调用、人员任务及状态回写。配置、测试样例与执行记录随同移交；获准检查或处置中断时，能够核对实际状态并转交人员。
验收与运维移交包。 交付建成部分的部署配置、约定范围的源码或可导出配置、接口说明、操作维护手册、测试与试运行记录。使用者以真实问题完成查询、接手、处置记录、客户验证和异常转交，维护者能够更新资料、调整任务、检查执行并处理故障。账号权限、运行依赖、持续费用和维护责任一并移交，使企业能够接收并持续运行。
咨询阶段形成经确认的业务与数据标准、模型、来源映射、应用原型、接口设计、智能体任务规格及验收清单；建设阶段交付已接入的数据、可操作应用、已联调接口、可调用服务和可执行工作流。标准统一处理与判定，仓库和知识库分别提供当前事实与有效依据，接口连接原有工具，应用与工作流组织处理，看板追踪客户结果，各项成果以实际运行记录确认交付范围。
5.3.3 三化与智力服务的作用
数字化使客户问题、影响、检查、动作与验证能够被记录、查询和比较。智力服务可以协助建设录入、日志整理与检查工具，也可以在运行中阅读来件、整理时间经过、辨认冲突与缺项，保留来源、现场版本和待核实内容，供专业人员判断及后续检验使用。
网络化使同一问题的依据与责任跨工具、跨岗位接续。客户、合同、现场、产品与研发记录通过标识和接口关联，接收者按权限取得当前背景，处置与客户结果返回原问题。智力服务可以协助开发适配工具，也可以查询关联资料、准备交接背景和汇总依赖；程序传递状态和任务，人员确认接手并协调不能按原安排继续的工作。
智能化利用已有记录与连接，支持理解现象、比较假设、选择检查、准备处置和验证结果。智力服务可以对照当前证据与历史方法，查找反例，整理恢复与长期修正选项，并在经过验证和批准的范围执行查询、检查或处置任务。实际结果再进入判断，帮助修订知识与方法，专业人员确认原因、方案和质量。
服务的成本较低、响应快和可7×24小时持续运行，使更多零散来件、执行结果和重复问题有机会得到及时整理，减少集中补录、查找与交接准备。经过验证的接待、检查和观察任务可以持续执行，专业人员接手时已有当前背景。三项能力围绕业务问题共同建设，在实际使用中继续调整；具体可承担的范围与投入效果按任务检验。
5.3.4 人、程序与智力服务的配合
业务与专业人员确定服务范围、问题标准、处理权限及客户验证要求，智力服务协助建设工具与任务，使用者验证可用性，维护者负责资料、方法和运行。例如门店反映无法完成签到时，程序保存来件并关联门店记录，服务整理原话、现场版本与已做检查，专业人员核实影响、选择检查和处置；获准动作由适合的程序、服务或人员执行，牵头人组织客户实际签到验证。客户沟通由人主导，有权人决定费用、变更和承诺，专业人员验收产物，客户确认接受范围，异常与剩余修正交明确人员继续承担。
5.4 场景应用：数智化方案怎样支持问题解决
共同标准、数据与知识、接口、应用及智能体工作流，沿同一问题组合使用。受理形成可接手背景，排查取得处置依据，实际动作进入客户验证，确认结果再用于关闭和预防。各场景留下下一环节能够使用的产物。
5.4.1 问题受理与影响判断
客户来件进入受理应用后，服务整理原话、现象、已尝试办法和待核实项，通过接口查询客户、合同与产品记录，提示实际版本和现场资料的缺项。入口人员补问会改变处置的信息，核实谁的哪项工作受阻、范围和时间，再按规则判断优先级；经过验证的常见问题可以检索有效知识准备或执行获准答复。
受理结果保留来源、时间、已确认事实和未知内容，形成问题背景与影响说明。需要继续处理的，带着已答内容和已做检查交牵头人及专业人员；超出资料、权限或常见处理范围的事项进入人工接手。新增影响回写原记录，供后续调整处理次序；当次能够解决的，也保留客户实际结果与确认，进入验证和关闭记录。
局部实践｜机器人参与入口接待。 森马电商受访者自述约70%的接待由机器人承担，属于局部使用，出处见参考资料[4]。接待后的处理结果和客户验证仍需逐项跟踪。
5.4.2 专业接手与资源协调
牵头人在协作应用中取得当前背景，由服务汇集相关合同、现场记录、已做检查与未决项，准备本次需要完成的任务。接收者核对能否开始、承担哪项产物及何时反馈，工作流分别记录分派与接受；资料不足或分派不当时，带原因退回修正。
涉及多个专业或现场资源时，应用关联各任务的输入、等待与汇合时间，服务整理检查、备件、客户窗口等依赖，供牵头人协调。影响扩大或资源冲突交有权人决定，新的安排由实际承担者和客户联系人确认；未接手、延后与受阻事项继续有明确跟进人。
5.4.3 证据排查与原因核实
专业人员在排查工作台中，对照客户影响、现场版本和时间经过提出可能原因，调用知识检索、日志比较及获准检查。服务整理支持与不符的证据、已排除项和缺项，准备有区分作用的下一步检查，执行结果通过接口返回原问题。
专业人员核实检查与现场是否对应，确认当前判断及尚未证明的部分，再形成带依据的诊断记录，供处置选项比较使用。新发现改变影响或原判断时，返回受理与资源安排；需要新增工具时，由技术负责人验证查询结果、权限和异常处理后纳入使用。
5.4.4 客户恢复与长期修正
客户工作受阻时，处置应用结合诊断记录、产品条件和合同责任，调用服务整理先恢复与直接修正的选项，比较时间、可靠性、影响及限制。专业人员确认可行办法，有权人批准必要费用、变更与承诺，牵头人与客户核对接受范围，再由执行工作流组织获准操作。
执行者留下对象、版本、实际动作、结果与新影响，供后续验证；返回状态不明时先核对实际发生了什么。恢复与长期修正分别有执行、验证和期限，交IPD的产品修正取得接手及决定，现场采用继续跟踪；暂缓修正时，也明确当前办法和剩余责任。处理结果进入客户验证场景。
局部实践｜运行服务持续支撑门店营业。 运动门店SaaS企业的经营者谈到，预约、签到和门禁关系到门店营业，故障可能让会员进不了门。供方还需响应问题、排查网络和维护运行。据其自述，AI主要用于内部研发和内容，属于局部使用。原始出处见参考资料[3]。
5.4.5 客户验证与关闭移交
处置记录进入验证应用后，服务从原问题、影响和执行证据准备检查项，运行获准检查并比较前后结果。专业人员确认内部质量，牵头人组织客户实际使用者完成原来受阻的任务，按约定确认人核对恢复或解决范围；需要观察的，留下期限、条件和再次出现时的接手安排。
结果不符时保留差异、返回排查，无法取得客户反馈时保留未确认和跟进。满足关闭条件的，整理客户确认、证据与剩余事项，由接手者确认后续产物和期限，再更新服务状态。客户只接受临时恢复时，长期修正继续可追踪；重新发生的问题关联原过程，供后续分析使用。
5.4.6 经验采用与预防改进
确认结果进入仓库以后，知识维护应用由服务提取候选办法、引用检查与验证依据，专业人员确认适用版本和条件后更新知识与工具。分析应用比较重复问题的版本、批次和触发条件，服务整理同因证据、反例及受影响对象，供产品、工艺或流程负责人判断是否改进。
获准改进通过工作流落实到IPD产品修正、LTC交付预检或MTL表达与接待资料，接收者记录决定与责任。牵头人继续跟踪当前客户，维护者替换旧方法，相关人员确认受影响岗位和客户实际采用；后续同因问题及投入返回看板，检验改动是否减少重复影响。
需求与设想｜让售后进展和重复问题进入产品决定。 迪欧家具已有售后系统，经营者希望工厂和业务共同了解进展，并由工艺、产品部门判断重复问题是否需要改标准，仍属需求与设想，出处见参考资料[5]。
5.5 效果检验与本章小结
检验从方案可用、场景改善推进到客户结果与完整投入。比较时固定问题批次、类型、影响、服务范围、质量要求和观察截止日，按共同标识追踪；同一问题涉及多个客户时，各客户结果分别保留，同因问题另行归并。未解决、等待客户、观察中及重新打开的事项继续列示。
方案可用。 用真实问题检查5.3的成果能否取得当前依据、完成处理、回传结果并接续任务，检查权限控制、执行状态核对与异常接手。维护人员能够更新产品与服务资料、修订任务和检查运行，实际操作及记录作为验收依据。
场景改善。 沿5.4比较受理缺项与重复补问、专业接手和依赖等待、错误尝试与返工、客户恢复和验证周期，夜间与集中来件分别观察。同时核对处置与知识是否被采用、长期修正是否到达现场、反馈改动是否进入相关岗位，以及后续同因影响是否减少。
整体价值。 核对本批客户任务恢复、客户确认解决的数量和周期，恢复与长期修正分别保留状态；确认解决比例以截至截止日纳入的全部客户问题个案为分母，未确认和未结个案一并呈现。完整成本计入建设配置、接待排查、现场处理、协调判断、验证交接、返工维护、服务调用及外部支持，一次性建设说明分摊。以同范围全部成本除以客户确认解决个案数比较单位成本；尚无确认解决个案时保留总投入与未结情况。新增覆盖、释放工时、重复负担与现金支出变化分别评价。
据此决定保留、调整或扩大哪些应用，让处置能力的改进传到客户实际工作。产品、合同、现场和服务共同影响问题解决，紧急恢复与长期修正也需要协调其他业务的资源，第六章继续讨论这些跨线依赖与共同取舍。
本章参考资料
华为资料用于流程目的与管理机制参照；本章的环节划分、原因分析、方案及人机安排为本报告应用整理。企业案例的事实、阶段和效果范围见所链接的下册场景，以下列出原始来源与定位。
[1] 华为．2012年年度报告．印刷第91页、PDF第94页，“管理变革”。阅读范围：客户关系与线索到回款、客户问题管理、IPD、项目及资源管理；2026年10月17日审读。
[2] 华为．公司治理．“内部控制”之“控制活动”“信息与沟通”。阅读范围：流程责任人、业务关键控制点、职责分离与改进沟通；2026年10月17日复核。
[3] 一芥智能研究院．运动门店SaaS企业AI应用（I04）．《企业数智化转型研究报告》下册，2026。所引场景阶段：局部使用。原始出处：用AI重做To B软件？他还不太着急 AI来了，SaaS会被取代还是会变得更有壁垒？听听服务近万家门店的龚旭东老板怎么说；定位：00:04:32.340；00:08:51.940。
[4] 光羽的平行世界．森马用AI变革增收2个亿 @森创启睿．定位：00:02:00.940；00:09:51.270；00:12:00.390。森马电商AI转型（F02），所引场景阶段：局部使用。
[5] 一芥智能研究院．迪欧家具AI应用（C09）．《企业数智化转型研究报告》下册，2026。所引场景阶段：需求与设想。原始出处：办公需要AI 办公室需要快乐～ 效率交给AI，快乐、碰撞和人与人的连接，还是得在线下发生。这期和黄雅悠聊聊，她是怎么用AI改造二十年的家具企业，怎样让办公更快乐。；定位：00:07:56.440。