Slack 里最常见的协作损耗，不是没人提需求，而是需求进来后散在消息流里。把 Lists 和 Workflow Builder 接起来，才会有真正可追踪的分诊队列。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
团队里最容易失控的，不是需求没人提，而是每个人都在 Slack 里提了需求，却没有一个地方把这些消息变成可分配、可排序、可催办的任务。结果就是提的人以为已经发过了，接的人以为稍后再看，几天后双方都在消息海里找上下文。Slack 现在把 Lists 和 Workflow Builder 接得足够近，只要搭对一遍，请求收集和分诊就能从聊天噪音变成稳定流程。
适用场景
- 你要收内容需求、设计需求、IT 支持、活动物料或内部审批请求。
- 团队已经主要在 Slack 协作，希望减少额外的表格和外部工单工具。
- 你需要每个请求都能看到负责人、优先级、到期时间和讨论上下文。
- 你希望请求一提交就自动入库，而不是靠人工复制粘贴。
不适用场景
- 你的流程需要复杂 SLA、跨部门权限审批和重型报表。
- 团队根本不用 Slack 作为日常工作入口。
- 你还没有明确分诊规则，只想先堆一张表看看。
- 管理员已经把 Workflow Builder 或相关连接器彻底限制住，而且短期内不会开放。
先把 Slack 里的三个对象分清
这条流程的三个核心对象分别是 list、form workflow 和通知自动化。list 负责承载请求本身；form workflow 负责把填写内容标准化并自动写入 list；通知和 due date 自动化负责把“状态变化”变成提醒，而不是让人手动盯着看。少了任何一环，流程都会回到“有人提了，但没人接”的老路上。
Slack 的官方文档还给了两个重要边界。第一，Workflow Builder 在付费计划里默认允许成员创建，但管理员可以收紧。第二，list 可以直接挂 form、字段变化通知和到期提醒，不需要你每个动作都从零拼工作流。也就是说，先用内置能力跑通，再决定哪些地方需要高级扩展，会更稳。
准备材料
- 一个固定承接请求的频道，例如 content requests 或 it help。
- 一张 list 的字段草案，至少有 Request、Category、Priority、Assignee、Due date。
- 团队约定好的优先级含义，不要让“高优先级”人人都能乱用。
- 谁能编辑 list、谁只可查看、哪些频道需要同步状态更新。
- 若要用 connector steps，先确认管理员是否允许相应权限和审批流程。
步骤一：先从 list 结构开始，不要先做表单
很多人一上来就先开表单，最后发现表单问的字段和分诊真正需要的字段并不匹配。更稳的顺序是先搭 list，看后续分诊时真正要用哪些列，再让表单去适配它。Slack 自己的 Help request tracker 模板就是按这个思路来的，先有 Request、Category、Priority，再决定表单暴露哪些问题。
- 先建一个新 list，或者直接从 Help request tracker 模板起步。
- 保留 Request、Category、Priority、Assignee、Due date 这些最低必需列。
- 对每个字段写明用途，避免有人把 Category 当备注区乱填。
- 如果你预期后面会做 board 视图，字段命名要足够稳定，别一周一改。
步骤二：用 form automation 收入口径，而不是让大家自由发消息
真正决定请求质量的，不是你有没有 list，而是入口是否统一。Slack 官方的 list form automation 会把提交内容直接写进 list，对多数团队来说，这已经能解决 80% 的“信息漏填”问题。表单问题太少，后面难分诊；问题太多，提交率会掉。所以要让表单刚好够用。
- 在 list 右上角打开 Workflows，找到 Form 并点击 Set Up。
- 逐项检查默认问题，隐藏那些对提交者无意义、但可以在内部补录的字段。
- 发布 workflow 后，把链接贴到固定频道置顶，或直接在相关频道里 Share Form。
- 如果表单标题不清楚，就到 Workflow Builder 里改名，不要让提交者面对一堆“List form”。
步骤三：分诊动作必须落在 Assignee 和 Priority 上
请求自动进表只是开始，真正减少扯皮的是让每一条请求尽快拥有负责人和优先级。Slack 文档把这两件事放得很靠前：所有 list 默认都有 Assignee 字段，而 triage 的核心就是按责任和优先级整理，而不是让请求永远停在“待处理”这一层。
- 规定一个分诊时间窗口，比如每天两次，由值班人统一分配。
- 优先级最好只有三档，避免 P0 到 P5 这种只有发明者看得懂的体系。
- Assignee 一旦写入，就默认这条请求有 owner；如果需要多人参与，再在线程讨论，而不是多重 owner。
- 对无法接受的请求，增加一个状态字段，让拒绝和延后也有记录，不要只在口头里说过。
步骤四：用字段通知和到期提醒减少“我以为你知道”
很多队列死掉，不是因为没人做事，而是因为状态变化没人知道。Slack 给 list 准备了字段变化通知、due date notifications 和 due date summary，这些能力的价值在于，把真正需要被看见的变化推到频道或个人 Activity，而不是让每个人自己去翻 list。
- 对关键字段，比如 Status 或 Priority，配置 field change notification。
- 只把真正需要公开同步的变化发到频道，避免任何字段一改都刷屏。
- 给有截止时间的请求开启 due date reminders，让执行人提前收到提醒。
- 如果团队负责人只需要汇总视角，再开 due date summary 给固定频道或管理者。
步骤五：把“讨论上下文”留在线程里，不要再把需求扔回私聊
Slack list 的一个真实优势，是每个 item 都可以在自己的消息线程里讨论。这比外部表格最大的好处，是提需求的人和处理需求的人不必在多个工具之间来回找上下文。流程设计时，应该主动要求补充信息、澄清范围和确认交付都尽量落在 item 线程里。
- 把“请补充截图”“请确认截止时间”这类动作统一回到 item 线程。
- 不要把关键决定放在 DM 里，否则 list 只剩结果，没有过程。
- 通过 Share 权限把需要参与的人或频道接入，而不是截图转发。
- 需要只读协作时，把列表开放 view 权限，不必人人都能编辑。
可复制请求分诊模板
频道名称：
list 名称：
必填字段：Request / Category / Priority / Assignee / Due date
表单入口：固定频道 / Canvas / 置顶链接
分诊频率：
优先级规则：高 / 中 / 低
字段变化通知：Status / Priority / Assignee
到期提醒：提前几天 / 逾期提醒给谁
默认线程规范：补充信息、确认范围、验收结论都回 item 线程实际例子：把内容需求从群消息变成有 owner 的生产队列
一个内容团队原来所有需求都扔在频道里，编辑、设计和运营都能看到，但谁都不确定哪条已经被接。后来他们先用 Help request tracker 模板建 list，把“需求标题、栏目、优先级、交付日期”做成表单，运营提交后自动入库；值班编辑每天两次给 Assignee 和 Priority；状态变更自动发到运维频道。这样一来，原本散在消息流里的需求，变成了一个所有人都能追踪、但不会被群消息冲散的生产入口。
验收清单
- list 字段已经稳定，不是靠自由文本硬扛所有需求。
- 表单入口已发布，提交后会自动生成 list item。
- 每条新请求都有明确的 Assignee 和 Priority。
- 关键字段变化和 due date 提醒已配置，但不会制造频道噪音。
- 讨论上下文主要留在 item 线程，而不是散回私聊。
常见坑
- 先发了表单，后面才发现 list 列根本不够分诊用。
- 让提交者填写过多字段，导致大家宁愿继续在频道随手发消息。
- 开了大量通知，最后所有人都把提醒静音。
- Assignee 只是填着好看，实际上没人对结果负责。
- 关键澄清都在私聊完成，list 里没有历史。
排错路径
- 表单没人用：先看问题是不是太多、入口是不是藏得太深。
- 请求进来了但没人接：检查是否明确规定分诊频率和 owner 角色。
- 频道被提醒淹没：缩减 field change 通知，只保留关键状态。
- 队列越来越乱：回头清理字段、合并优先级规则，不要继续叠补丁。
- 成员看不到 workflow：确认管理员是否限制了 Workflow Builder 或相关权限。
后续维护建议
更新日期：2026-07-29。Slack 里的请求分诊，一旦跑通，最值得维护的不是表单样式，而是字段纪律、提醒节奏和 owner 机制。每隔两到四周回看一次：哪些字段没人用、哪些提醒没人看、哪些请求总是卡在同一状态。把这三件事调顺，这套流程会越用越轻，不会越用越重。