核心想法
如何定义请求、状态、交付物、渠道和负责人，让营销运营能够准确协调、衡量与学习。
从贯穿工作的对象入手
目标、行动计划、广告活动、请求、交付物、资产、渠道、受众、审批和结果并非同义词。每个对象都需要定义、标识符和关联。广告活动可包含请求；一个请求可产生多个交付物；一项资产可出现在不同渠道。如果一切都叫任务，组织便会失去层级，也无法还原为何开展某项工作。模型应反映真实工作，而不是自动照搬某个工具的结构。
当团队与系统用相同名称指代相同事物时，运营才变得清晰可见。分类体系定义对象、请求类型、状态、优先级、渠道、交付物和负责人。这不是一项行政练习：它让正在发生的事显现出来，支持清晰的自动化，并能比较时间或结果，而不混淆不同类型的工作。
设计请求类型及最低输入要求
社交素材、销售方案、付费媒体活动和公关回应，需要不同的信息。每种类型都应定义必填字段、初始负责人、SLA、阶段和结束标准。表单应索取启动所需的信息，而不是要求申请者成为流程专家。条件式问题能减少噪声：涉及发布时，询问渠道和日期；涉及投入时，询问市场、目标和已确认预算。
状态应描述可观察的条件
“进行中”对每个人往往意味着不同的事。有用的状态应说明已经发生什么、还剩什么：已接收、初步分流、待补充信息、已排定优先级、制作中、内部审核、客户审批、已排期、已发布或已关闭。每次状态转换都有负责人，必要时还应附上证据。如果工作仍待发布或衡量，就不应标记为完成。精确的状态能让积压显现，无需在聊天中追问进度。
区分优先级、紧迫性和影响
紧急描述时间，影响描述后果，优先级表达约定顺序。混淆三者，会让每个声量大的请求都变成关键任务。矩阵可以综合目标、固定日期、依赖、风险、投入与价值，并明确谁有权解决冲突。优先级变化应连同原因及对其他交付的影响一起记录，让组织看到打断的成本，而不只是新增的请求。
把分类体系当作内部产品进行版本管理
新渠道、产品或职责出现时，名称也会变化。每次修改都应有负责人、日期、迁移安排和沟通。在增加字段前，先确认它能支持什么决策；删除字段前，先检查依赖它的报告和自动化。Wiwo.Ops 可以将分类体系落实到模板、状态、角色和仪表盘中，但只有人们理解并使用这些定义，系统才能发挥作用。
