工具替换完成后，推广支持往往卡在“大家都在帮忙、却没人对结果负责”。明确分工的关键，是把推广拆成一件件可交付的支持事项，再为每类事项指定唯一的一线支持人、决策人和交付时限。本文面向替换后的采用阶段，给出一张可直接填写的支持分工表、三类角色的边界规则、请求流转与升级机制，以及判断分工是否有效的检查清单。
要点总览（TL;DR）
- 推广支持分工按“支持事项”拆分，而不是按部门拆分：先列举替换后真实发生的请求类型，再为每类事项指定一线支持人、决策/升级人和交付物与时限，形成四字段分工表。
- 三类角色按“对什么结果负责”划边界：推广负责人管节奏与采用度，领域支持人管本业务域用法与经验沉淀，平台管理员管权限、配置、数据与故障；小团队可合并角色，但每类事项保留唯一责任人。
- 支持请求统一入口并分类，按影响程度设定响应时限，明确升级触发条件与升级对象，以提出方确认可用和知识沉淀作为关闭标准。
- 分工有效性用两条线检验：采用度看活跃使用与关键流程走通比例，闭环看响应达标率、一次解决率与积压量，并按周度问题分布调整分工表。
- 支持请求可登记为工作项并指定处理人与升级人，关闭时关联知识文档，使分工从一张表变成可追踪的记录。
先定支持事项，再定人：分工表的四个字段
推广支持分工落不到人，常见原因是拆分维度选错了。按部门拆，会得到“研发支持、业务支持、IT支持”这类无法直接派工的条目；按事项拆，才能得到“新流程里审批节点怎么配”“历史数据导入后字段对不上找谁”这类可以立刻指派的支持请求。因此第一步是从替换后真实发生的请求出发，列出事项类型，再往里面填人。
列举事项时，可以回顾上线后一到两周内实际收到的提问和求助，按动作归类。替换后常见的支持事项大致包括：
- 使用答疑：登录、入口、常用操作、字段含义等即时问题；
- 培训与上手：新成员入职培训、部门专场讲解、操作手册维护；
- 数据初始化：基础数据导入、字段映射核对、历史数据补录；
- 流程配置：审批流、状态流转、通知规则的调整与新增；
- 权限与账号：角色开通、权限变更、离职交接；
- 问题升级：影响业务运行的故障、性能异常、数据错误；
- 采用度跟踪：活跃情况统计、关键流程走通情况盘点。
事项列出来后，用四个字段把每一项固定下来。四字段的作用是让“谁负责”变成可核对的信息，而不是口头约定。
| 支持事项 | 一线支持人 | 决策/升级人 | 交付物与时限 |
|---|---|---|---|
| 日常操作答疑 | 各部门关键用户（具名） | 领域支持人 | 当个工作日内答复；高频问题沉淀为问答条目 |
| 新成员上手培训 | 领域支持人 | 推广负责人 | 每月一次集中培训；培训材料更新后同步 |
| 基础数据导入与核对 | 平台管理员 | 领域支持人确认业务口径 | 导入清单与核对结果，按约定批次完成 |
| 审批流调整 | 领域支持人提出需求 | 推广负责人审批，平台管理员执行 | 变更说明与生效时间，评估后执行 |
| 权限开通与回收 | 平台管理员 | 部门负责人确认 | 按申请单处理，当日或次日完成 |
| 影响业务的故障 | 平台管理员 | 推广负责人协调资源 | 先恢复使用，再给出原因说明 |
填写时有两个颗粒度要求。一是“一线支持人”写到姓名或岗位加姓名，写部门名等于没有指定人；二是“交付物与时限”要能被验证，例如“当日答复”“导入清单加核对结果”，而不是“及时处理”。日常答疑与需要变更流程或配置的事项要分开列：前者以答复和沉淀为主，后者涉及变更决策，必须经过决策人确认后才能执行，避免一线支持人自行改动流程造成口径混乱。
三类角色怎么分：推广负责人、领域支持人、平台管理员
事项清单确定后，把支持人归入三类角色，职责边界按“对什么结果负责”来划，而不是按“能做什么”来划。三类角色的核心分工如下。
| 角色 | 负责的结果 | 主要动作 | 不承担的部分 |
|---|---|---|---|
| 推广负责人 | 推广节奏与整体采用度 | 制定推广计划、跟踪活跃与流程走通情况、协调跨部门资源、主持周度复盘 | 不直接处理具体操作答疑，不代替管理员做配置 |
| 领域支持人 | 本业务域的用法正确与经验沉淀 | 解释本域流程、提供模板与案例、培训关键用户、判断需求是否需要变更 | 不擅自修改系统配置，不承担跨域协调 |
| 平台管理员 | 系统可用、权限与数据准确 | 权限开通回收、流程配置执行、数据导入核对、故障定位与升级 | 不判断业务口径，不决定推广节奏 |
三者的交接点集中在两处。第一处是“需求转变更”：领域支持人判断某个请求需要改流程或配置时，提交给推广负责人确认必要性和优先级，再由平台管理员执行，执行结果回到领域支持人处验证业务效果。第二处是“故障转业务”：平台管理员恢复系统后，把影响范围和临时处理方式告知领域支持人，由其向本域用户说明，避免同一问题被反复追问。
小团队可以合并角色，例如推广负责人兼任领域支持人，或领域支持人兼任平台管理员。合并的前提是每类支持事项仍保留唯一责任人，并在分工表上写明“该事项由某人兼任”。合并后要特别注意决策与执行分离：同一个人既提需求又执行配置时，变更记录要留痕，便于事后核对。
支持请求怎么流转：入口、响应时限与升级路径
静态分工要靠流转机制才能被检验。流转设计的目标是让每个请求都有明确入口、明确处理人和明确的结束条件，避免请求散落在私聊、群消息和口头沟通中。
第一步是统一入口。所有支持请求从一个固定渠道提交，提交时选择事项类型（答疑、培训、数据、配置、权限、故障），并填写影响范围和期望时间。统一入口的价值在于可以按类型统计问题分布，为后续调整分工提供依据。
第二步是按类型设定时限。时限不必追求统一，按影响程度分档更实际：影响业务运行的故障优先响应，操作答疑按工作日承诺，配置变更按评估排期。时限要写进分工表，让提出方知道预期，也让支持人知道承诺。
第三步是明确升级触发条件。常见触发条件包括：超出约定时限未解决、涉及跨部门口径冲突、需要变更已定流程、影响关键业务节点。升级对象按事项类型对应到决策人，升级时需带上已尝试的处理方式和当前阻塞点，避免升级变成简单转交。
第四步是关闭标准与知识沉淀。请求关闭的条件是提出方确认可用，或问题已转为变更需求并进入排期。关闭时做一次判断：这个问题是否会被再次问到？如果是，整理为问答条目或操作说明，归入对应业务域的知识文档，并在下次培训中引用。
第五步是周度复盘。每周汇总问题分布：哪类事项量最大、哪类超时最多、哪些问题重复出现。问题集中在某个业务域，说明该域的支持人或培训需要加强；配置类请求过多，说明前期流程设计需要复核；重复问题多，说明知识沉淀没有跟上。复盘结论直接用于调整分工表，而不是停留在讨论层面。
示例：一次替换后首月的支持分工落地
以下为演示情景，用于说明分工表的填写与调整过程，不代表特定企业实际情况。
某中型企业的研发与项目管理团队完成工具替换，涉及产品、研发、测试和项目管理四类用户，约百余人。上线首周，推广负责人收集到的支持请求集中在四类：登录与入口找不到、原有项目数据看不到、审批流与旧系统不一致、部分成员权限不足。
据此填写分工表：日常答疑由各部门关键用户承担，当个工作日答复；数据核对由平台管理员负责，领域支持人确认字段口径；审批流差异由领域支持人整理需求，推广负责人确认后交平台管理员配置；权限问题由平台管理员按申请单处理。推广负责人每周统计活跃人数和关键流程走通比例。
首周问题分布显示，审批流差异类请求占比最高，且多次重复。复盘后做了两项调整：一是把审批流差异整理成一份对照说明，由领域支持人在各部门宣讲，减少重复提问；二是将配置类请求的决策人从推广负责人下沉到各业务域负责人，缩短确认链路。第二周该类请求明显下降，答疑类请求随之成为主要工作量，关键用户培训频次相应增加。
这个示例可迁移的规律是：分工表要按实际请求分布调整，而不是一次定死；问题最集中的类型，往往对应着培训、流程设计或知识沉淀的缺口。适用边界在于，团队规模和业务复杂度不同，角色合并程度和时限档位需要相应调整，示例中的具体时限不宜直接照搬。
怎么判断分工有效：采用度与闭环检查
分工是否有效，不能只看“有没有人回复”，要看使用情况和问题闭环两条线。采用度反映推广是否真的发生，闭环指标反映支持机制是否运转。
| 检查维度 | 指标 | 参考通过标准 |
|---|---|---|
| 活跃使用 | 周活跃人数占应使用人数比例 | 连续两周稳定或上升，无明显下滑 |
| 关键流程走通 | 核心业务流程在新工具中完成的比例 | 主要流程均有实际走通记录 |
| 响应达标 | 在约定时限内首次响应的请求占比 | 多数请求按时限响应，超时集中在可解释的复杂事项 |
| 一次解决率 | 首次处理即关闭的请求占比 | 答疑类请求一次解决率保持较高水平 |
| 积压量 | 超过时限仍未关闭的请求数量 | 积压可控且逐周下降，无长期挂起事项 |
除指标外，还可以用几项检查确认分工本身是否清晰：每类支持事项是否都有具名的一线支持人；升级人是否在请求超时前实际介入过；关闭的请求是否留下了可复用的说明；周度复盘是否产出了分工调整动作。四项中任何一项长期为空，说明分工表停留在文档层面。
发现分工失效时，按现象对应调整：某类请求长期超时，检查该事项是否缺少备份支持人；重复问题持续出现，补知识沉淀和培训；决策链路过长，把部分决策权下沉到领域负责人；关键用户负担过重，增加一线支持人数量或调整事项归属。调整后更新分工表并通知全员，避免新旧规则并行。
用工作项承载推广支持：ONES 的衔接方式
上述分工与流转要持续运转，需要一个统一的记录场所。把支持请求登记为工作项，可以让“谁在处理、卡在哪一步、是否超时”变成可查看的状态，而不是依赖记忆和聊天记录。
具体衔接方式可以按一条流程展开：用户从统一入口提交支持请求，登记为工作项并按事项类型分类；工作项上指定处理人和升级人，对应分工表中的一线支持人与决策人；处理过程中的结论和操作说明写入工作项，关闭时关联到对应业务域的知识文档，形成可检索的支持记录；推广负责人按周查看工作项的分类分布、超时情况和积压量，作为复盘和调整分工的依据。ONES 的工作项管理、角色分配、文档知识与统计视图可以承载这条流程，具体配置方式以实际使用环境为准。
这样做的直接结果是，支持分工从一张表变成一组可追踪的记录：每类事项有对应的工作项类型，每个请求有明确处理人，每次关闭都留下可复用的说明，周度复盘有数据可依。分工调整时，只需修改工作项类型与处理人规则，历史记录仍然完整保留。
常见问题
推广支持分工表多久需要更新一次？
建议以周度复盘为固定节奏，根据问题分布决定是否调整。出现以下情况时应立即更新：某类请求连续两周超时、同一问题重复出现且未沉淀说明、决策链路过长导致确认拖延、关键用户负担明显过重。调整后同步通知全员，避免新旧规则并行造成请求投递混乱。分工表本身可以保持结构稳定，只更新事项归属、时限和升级人。
小团队人手有限，三类角色合并后如何避免职责空档？
合并角色的前提是每类支持事项仍保留唯一责任人，并在分工表上注明兼任关系。需要特别处理的是决策与执行分离：同一个人既提配置需求又执行配置时，变更记录要留痕，执行前保留一次确认动作，便于事后核对口径。此外应为高频事项设置备份支持人，避免唯一责任人请假或忙于其他工作时请求无人接手。
支持请求的响应时限应该定多严？
时限按影响程度分档比统一标准更实际：影响业务运行的故障优先响应并先恢复使用；操作答疑按工作日承诺；配置变更按评估排期。时限的作用是让提出方形成预期、让支持人明确承诺，因此要写进分工表并公开可见。时限过严会导致支持人疲于应付，过松则失去约束意义，可以先用两周实际数据校准，再固定下来。
推广期结束后，这套分工还需要保留吗？
推广期结束后，支持事项的数量和类型会变化，但机制本身仍有价值。建议保留统一入口、事项分类和升级路径，把分工表从“推广专项”转为日常支持职责，并将高频问题持续沉淀为知识文档。采用度跟踪可以降低频次，改为月度或季度查看，重点转向关键流程是否稳定运行、新成员上手是否顺畅。
支持记录放在协作平台里，和放在聊天群里相比有什么实际差别？
聊天群里的请求容易被刷走，难以统计类型分布、超时情况和积压量，交接时也缺少上下文。把请求登记为工作项后，处理人、当前状态和关闭结论都可查看，关闭时还能关联到知识文档形成可检索的记录。推广负责人据此按周查看分类分布和超时情况，复盘和调整分工时有数据可依，而不是凭印象判断。
