工具替换上线后，推广支持分工要落到一张可填写的职责表上：按推广决策、部门落地、一线答疑、数据跟进、问题升级五类角色，明确每类角色负责的动作、交付物和交接时点。本文给出一份假设情景下填好的完整示例，并逐项解释填写依据与可迁移规律，供你替换上线后分配推广责任时参照。
要点总览（TL;DR）
- 示例按推广决策、部门落地、一线答疑、数据跟进、问题升级五类角色，把推广支持拆成可执行、可交接的条目。
- 填表的关键是每类角色都写明负责动作、交付物、交接对象与节奏，只写部门名称无法追踪责任。
- 一线答疑同时设值班与知识沉淀两条线，重复问题有固定答案，轮值人员更换时也能快速接手。
- 团队规模不同可以合并角色，但五类动作都要有人认领；交接时点跟随团队节奏调整，推广期结束后提前注明职责退出方式。
- 示例适用于已完成切换、进入采用推广阶段的团队，选型阶段与迁移切换窗口需要另行设计分工。
这份示例要解决什么问题
本文的示例设定在一个假设情景中：某团队完成工具替换上线，进入上线后第1至2个月的推广期，需要把推广支持工作分配到具体角色。示例中的团队名称、人员、节奏和数据均为演示用，不代表真实客户案例，也不附带任何成效结论。
示例的目标是把“推广支持”这件笼统的事拆成可执行、可交接的条目：谁做决定、谁在部门内落地、谁回答一线问题、谁看使用数据、谁接收解决不了的问题，以及每类角色在什么时点把什么交付给谁。填完这张表，团队成员能对照自己的名字找到动作，负责人能按节奏检查进展。
需要说明边界：本文不涉及新平台从零实施的选型与部署，也不涉及迁移切换窗口的数据校验与回退。示例只覆盖“已经切换完成、进入采用推广”这一段，其他阶段的职责分工需要另行设计。
完整示例：一张填好的推广支持分工表
下表是假设情景下填写完成的分工表。五类角色分别对应推广决策、部门落地、一线答疑、数据跟进、问题升级，每行写明负责动作、交付物、交接对象与节奏。
| 角色 | 负责动作 | 交付物 | 交接对象与节奏 |
|---|---|---|---|
| 推广决策（示例中由项目发起人担任） | 确定推广目标与优先级；审批推广节奏调整；在周会上裁决跨部门争议 | 推广目标说明；周会议题与决议记录 | 每周一向部门落地角色同步本周重点；决议当日发出 |
| 部门落地（示例中每个业务部门一名联络人） | 把推广目标拆成本部门的使用安排；组织本部门答疑；收集一线反馈 | 部门使用安排表；每周反馈汇总 | 每周三向一线答疑角色提交本周高频问题；每周五向数据跟进角色提交部门进展 |
| 一线答疑（示例中由熟悉工具的骨干轮值） | 按值班表回答日常问题；把重复问题整理成问答条目；标记需要升级的问题 | 答疑值班表；问答条目文档；升级问题清单 | 每日值班结束后更新问答条目；升级问题当日转交问题升级角色 |
| 数据跟进（示例中由运营岗兼任） | 每周汇总使用数据；对照推广目标标注偏差；准备周会数据页 | 使用数据周报；周会数据页 | 每周四向推广决策角色提交周报；周会上说明偏差项 |
| 问题升级（示例中由技术负责人担任） | 接收升级问题；判断是配置、权限还是使用方式问题；给出处理结论或转交 | 升级问题处理记录；需长期跟进的事项清单 | 收到升级问题后两个工作日内给出结论；长期事项每周五同步推广决策角色 |
这张表在示例中的使用方式是：推广决策角色在周会上看数据跟进提交的周报，决定是否调整节奏；部门落地角色按周提交反馈，一线答疑角色据此补充问答条目；问题升级角色处理答疑角色转来的问题，并把需要长期跟进的事项带回周会。整张表形成“决策—落地—答疑—数据—升级”的闭环，每个环节都有明确的输入和输出。
逐项解释：每一栏为什么这样填
为什么把决策与执行分开
推广期常见的冲突是：一线希望少改流程，负责人希望加快覆盖，两边都觉得自己有理。把推广决策单独设为一个角色，作用是让“调整节奏、裁决争议”有明确的人负责，部门落地角色则专注在本部门把安排执行下去。示例中决策角色由项目发起人担任，是因为推广节奏涉及跨部门资源，需要有一定权限的人拍板；如果团队规模小，这个角色可以由负责人兼任，但裁决动作仍要保留。
一线答疑为何要设值班与知识沉淀两条线
只设答疑不设沉淀，同样的问题会被反复回答，答疑人越忙，推广越依赖个人。示例中把一线答疑拆成两条线：值班表保证每天都有人接问题，问答条目文档保证重复问题有固定答案。两条线由同一角色承担，但动作分开记录——值班是当天的响应责任，沉淀是每周的整理责任。这样即使轮值人员更换，新值班人也能先查问答条目再回答。
数据跟进选哪些观察项、由谁看
示例中的使用数据周报只放与推广目标直接相关的观察项，例如各部门实际使用人数、高频问题数量、升级问题数量，不追求指标齐全。选择由运营岗兼任数据跟进，是因为这类角色本来就习惯做汇总和对照；如果团队没有运营岗，可以由部门落地角色轮流汇总，但要避免“自己部门的数据自己报”带来的偏差。观察项的具体口径应在推广开始前写清楚，示例不给出指标定义或阈值。
问题升级的触发条件与接收人
示例把升级条件写成三条：答疑角色判断问题涉及配置或权限、同一问题在一周内出现三次以上、问题影响部门正常使用。接收人设为技术负责人，是因为这三类问题通常需要改动设置或协调资源，一线答疑角色没有权限处理。升级后要求两个工作日内给出结论，是为了避免问题在升级环节再次积压；暂时无法解决的，转入长期跟进事项清单，在周会上同步。
换到你的团队怎么改：可迁移规律
示例的价值在结构，不在具体人名和节奏。换到你的团队时，可以按以下三条规律调整。
- 角色可合并，动作不能缺。五个人的团队可以把推广决策与问题升级合并给同一人，把部门落地与数据跟进合并给同一人，但“做决定、在部门内落地、回答一线问题、看使用数据、接收升级问题”这五类动作都要有人认领。合并后要在表里写清同一人承担的多项动作各自的交付物，避免动作被稀释。
- 交接时点跟随团队节奏调整。示例用“周一同步、周三提交问题、周四提交周报、周五同步进展”的周节奏，适合以周为工作周期的团队。如果团队按双周迭代，可以把交接时点改为双周节点，但每个交接点仍要写明“谁在什么时候把什么交给谁”，不能只写“定期同步”。
- 推广期结束后职责要回收或转常态。示例设定推广期为1至2个月。推广期结束时，推广决策角色的周会裁决可以停止，一线答疑的值班表可以转为常规支持渠道，问答条目文档转为长期知识库，数据跟进从周报改为月度回顾。提前在表里注明每项职责的退出方式，可以避免推广期结束后角色悬空。
适用边界与常见填错方式
这份示例适用于已完成工具切换、进入采用推广阶段的团队，用来分配推广期的支持责任。以下情形不宜直接套用：仍在选型阶段，需要的是评估与决策分工；处于迁移切换窗口，需要的是数据校验、回退预案和切换当日的值守安排，这些内容与推广支持的动作和节奏都不同。团队规模、行业和预算不同，角色设置也应相应调整，示例不作为统一要求。
填写时常见的错误有三类，可以对照检查：
- 只写部门不写动作。例如“由各部门负责推广”，没有说明部门内谁做什么、交什么，责任无法追踪。应改为具体动作加交付物，如“部门联络人每周三提交本部门高频问题汇总”。
- 没有交接时点。写了交付物却没写什么时候交给谁，导致周报积压、问题滞留。每个交付物都应配一个交接对象和节奏。
- 答疑无沉淀。只排了值班表，没有问答条目和整理责任，重复问题反复消耗答疑人。应把沉淀动作写进同一角色的职责，并规定更新频率。
在答疑沉淀和问题升级这两个环节，如果团队已经在使用统一的工作平台，可以把问答条目、升级问题清单和每周使用数据分别放进文档与工作项中管理：答疑角色更新文档，升级问题以工作项流转并记录处理结论，数据跟进角色按周汇总工作项状态形成周报。这样分工表上的交付物有固定的承载位置，交接时点也更容易核对。
常见问题
推广期只有一两个月，这张分工表值得专门填吗？
值得，但可以简化填写。推广期短，问题往往集中在最初几周：谁拍板调整节奏、谁回答一线问题、问题卡住时找谁，这些如果没有提前写明，容易在出现分歧时临时协调。填写时不必追求角色齐全，可以先保证五类动作都有人认领，交付物和交接时点写清即可。推广期结束后，把值班表、问答条目和升级记录转为常态支持方式，填表投入可以延续使用。
部门落地角色由部门负责人担任还是由一线骨干担任更合适？
取决于部门要落地的内容。如果推广重点是调整部门内的使用安排、协调资源，部门负责人担任更合适，因为需要一定权限推动；如果推广重点是日常使用中的具体操作和答疑，熟悉工具的骨干担任更贴近一线。两种安排可以并存：负责人确认本部门使用安排，骨干负责收集反馈和对接答疑。无论谁担任，表里都要写清该角色每周交付什么、交给谁。
推广期结束后，答疑值班表和问答条目怎么处理？
建议在推广期结束前就确定退出方式，避免角色悬空。值班表可以转为常规支持渠道，明确日常问题走哪个入口；问答条目文档转为长期知识库，指定维护人和更新频率；升级问题清单中未闭环的事项移交对应负责人继续跟进。这些安排提前写进分工表，推广期收尾时按表执行，减少临时交接造成的遗漏。
使用数据周报应该放哪些内容，会不会变成额外负担？
周报只放与推广目标直接相关的观察项，例如各部门实际使用人数、高频问题数量、升级问题数量，不必追求指标齐全。观察口径在推广开始前写清楚，避免每周换算法。数据跟进角色可以由运营岗兼任，也可以由部门落地角色轮流汇总，但要注意自己部门的数据自己报可能带来偏差。周报的作用是支撑周会上的节奏判断，内容够用即可。
团队已经在用统一的工作平台，分工表上的交付物怎么落到平台里？
可以把不同交付物放到对应的承载位置：问答条目放进文档或知识库，由答疑角色按固定频率更新；升级问题以工作项形式流转，记录处理结论和长期跟进事项；使用数据按周汇总工作项状态形成周报。这样分工表上的每个交付物都有固定位置，交接时点也更容易核对。具体用哪些工具承载，按团队现有平台和使用习惯选择即可。
