如何构建带客户审批的营销活动 Web 应用

定义产品目标与目标用户

在绘制界面或选技术栈之前，先弄清核心问题：营销活动和审批散落在邮件、聊天和共享硬盘中。一个活动 Web 应用应把简报、素材、反馈和签字集中到一个地方，让每个人都能看到下一步该做什么——不必追着线程跑。

为谁构建

大多数机构的审批工作流涉及四类人群，各自需求不同：

• 客户经理 / 项目经理：需要可靠的时间线、清晰的责任归属，和更少的催促消息。
• 创意人员（设计师、文案、编辑）：需要聚焦的反馈、更少矛盾的意见，以及简便的修订上传方式。
• 客户：需要简单的审阅体验、确认自己看到的是最新版，并能快速批准。
• 审批者（法务、品牌、管理层）：需要上下文、对风险的可见性，以及可审计的“批准人”记录。

设计时要针对的常见痛点

基于邮件的审批会带来可预测的问题：错过截止因为没人看到最新请求、模糊的反馈（例如“让它更有感觉”却没具体说明）、多个版本四处漂浮，以及由于延迟或冲突输入带来的返工循环。

真正重要的成功指标

定义可衡量的结果，便于判断产品是否有效：

• 审批周转时间（请求发送 → 最终批准）
• 每个素材的修订次数
• 活动里程碑的按时交付率
• 客户满意度信号（例如更少的“进展到哪儿了？”消息）

v1 必须包含的内容

对于 v1，把精力放在能把活动和审批放在一起的最小集合：

• 活动时间线
• 素材上传 + 预览
• 与特定版本绑定的评论线程
• 明确的批准/拒绝步骤，并带有到期日

把好用但非必要的功能留到后面：高级报告、深度集成、自动化规则和自定义审批路径。

绘制活动与审批工作流

在考虑界面或技术之前，写下工作在你们机构里真实的流转方式。清晰的工作流能把“这到哪儿了？”变成可预测的步骤，应用可以强制、自动化并报告这些步骤。

从核心对象开始

大多数活动审批应用可以用一小组构建块来描述：

• 客户（及其团队）
• 活动（通常关联目标、预算和日期区间）
• 项目（把活动拆成交付项或渠道）
• 任务（谁在什么时候做什么）
• 素材（文件：概念稿、文案、图片、视频、落地页）
• 审批（与素材/版本关联的决策记录）

把关系记录下来：一个活动包含项目；项目包含任务；任务产出素材；素材经历审批。

定义审批生命周期

一个简单、适合机构的流程是：

Draft → Internal review → Client review → Approved

让每个状态在操作上有明确含义。例如，“Internal review” 可能要求创意负责人和客户经理先签字，然后客户才会看到。

指定如何捕捉反馈

决定产品里反馈的形态：

• 评论（线程化，支持 @提及）
• 标注（在图片/视频帧上钉点评论）
• 变更请求（带结构化字段，例如“必须修复”与“可选建议”）

关键是把反馈绑定到一个素材版本，这样就不会为谁审阅了哪个文件而争论。

找到瓶颈并自动化

常见的慢点：等待审阅者、不清晰的下一步以及重复设置。最有帮助的自动化包括：

• 提醒规则（例如在“客户端审阅”状态下 48 小时后催促）
• 审批模板（默认审阅者、到期日、必检项）

提前考虑边缘情况

真实的审批并不总是干净利落。计划处理：

• 部分批准（批准文案，拒绝视觉）
• 被拒绝项（需附理由 + 下一步到期日）
• 临时变更（重新打开已批准的素材、重新触发审批、记录是谁做的）

如果你能用明白的语言描述这些规则，就可以把它们转成界面和数据模型。

规划 UX：仪表盘、时间线与审阅视图

优秀的活动应用 UX 从简单的信息层次开始，反映机构的思考方式：客户 → 活动 → 交付物（素材）。如果用户总能回答“我在哪里？”和“接下来怎么做？”，审批会更快，漏项更少。

选择清晰且一致的层级

以客户作为顶层锚点，下面显示活动，再到交付物（广告、邮件、落地页、社媒帖子）。在导航、面包屑和搜索中保持同样结构，避免用户在每个页面都要重新学习应用。

一个实用规则：每个交付物应该始终在一目了然处展示其客户、活动、到期日、状态和负责人。

设计关键界面（“日常驱动”）

仪表盘： 机构的首页。重点展示今天需要注意的事：即将到期项、等待内部审阅的项、等待客户审批的项。

活动时间线： 类日历或阶段视图，使依赖关系一目了然（例如“文案批准”在“设计定稿”之前）。保持可读——用户应在几秒内了解进度。

素材审阅视图： 赢得时间或浪费时间的地方。让预览更大、评论更易查找、下一步操作清晰。

收件箱： 一个汇总“我需要回复的事情”的地方（新反馈、审批请求、提及），减少邮件和聊天之间的来回。

与真实问题匹配的过滤器

快捷过滤应该能回答常见询问：

• 按 客户（瞬间切换上下文）
• 按 到期日（逾期、本周到期）
• 按 状态（草稿、审阅中、需修改、已批准）
• 按 负责人（谁负责）

让审批不可能被忽视

主要操作按钮应该显而易见：批准 / 请求修改。在审阅视图中保持固定（粘性底部/顶部），这样客户滚动查看评论后不会找不到按钮。

为移动端客户审阅做准备

客户常在会议间隙审阅。优先考虑移动可读性：干净的预览、大按钮、简短的反馈表单。如果一次点按能打开素材，另一次点按能批准，周转时间会更快。

角色、权限与客户访问

一个活动审批应用的生死在于信任：客户必须确信他们只看到应看到的内容，团队需要清晰的边界以免工作被错误覆盖或由不当人员批准。

核心角色（简单开始）

大多数机构可以用五个角色覆盖多数需求：

• 机构管理员：管理工作区设置、账单、模板和用户管理。
• 客户经理：负责活动、时间线和客户关系；可以邀请客户并指定审批者。
• 贡献者（设计/文案）：上传素材、回复反馈、创建新版本。
• 客户：可以查看自己的活动和素材、评论并请求修改。
• 审批者：客户方角色（或内部），拥有明确的审批权。

基于对象的权限（而非“一刀切”）

除了全局权限外，为每种对象类型（活动、交付物、素材、评论）定义可执行动作。典型动作包括 查看、评论、上传、批准、编辑、删除。

一个实用默认是“最小权限”：贡献者可以上传并编辑自己的素材，但删除或更改活动设置由客户经理/管理员限制。

客户专属访问

客户只能看到属于他们的活动、素材和讨论。避免共享“客户文件夹”无意中暴露其他账户。当每个活动都绑定到一个客户账号，并在页面、下载与通知中始终执行访问校验时，这点最容易实现。

多审批者规则

为每个交付物支持两种审批模式：

• 任一审批者通过即可：一个审批通过即可（适用于快节奏的社媒发布）。
• 所有审批者均需通过：每个人都必须批准（品牌敏感项）。

在不公开数据的前提下安全分享

提供分享链接以便捷，但默认保持私密：限时令牌、可选密码、可撤销。

一条好规则：分享不应绕过客户边界——它只应授予用户本来就有权查看的条目访问权。

审批状态、反馈与素材版本管理

客户端审批功能的成败在于清晰度。如果团队和客户无法区分“谁在等待谁”，审批会停滞，“已批准”也会变得可争议。

简单一致的状态模型

从一小组人人都能认同的状态开始：

• Draft（草稿）：内部进行中的作品
• In Review（审阅中）：已共享给客户（或内部审阅者），等待反馈
• Changes Requested（需修改）：收到反馈，团队需响应
• Approved（已批准）：已接受使用

避免为每个边缘情况都新增状态。如需更多细分，用标签（例如“法务审阅”）而不是膨胀工作流。

版本管理：永不覆盖历史

把每次上传当作一个新的不可变版本。不要在原地替换文件——创建 v1、v2、v3… 并关联到同一素材。

这支持清晰的对话（“请更新 v3”）并防止意外丢失。在 UI 中把当前版本突出显示，同时允许审阅者打开历史版本对比。

结构化反馈以便执行

纯自由文本评论往往混乱。加入结构化元素：

• 检查项（每项可标记为完成）
• 必须更改 与 可选建议 的区分
• @提及 用于把任务指派给合适的人

如果支持时间码（视频）或页面/区域打点（PDF/图片），反馈会更易执行。

审批元数据与后续规则

批准时要记录：

• 批准人身份（用户 + 角色）
• 时间戳
• 被批准的版本 ID

批准后定义规则：通常锁定被批准的版本，但允许创建为新版本的轻微修订（这会把状态重置为 In Review）。这样既保证批准的可辩护性，又不阻碍合法的临时调整。

素材管理：上传、预览与存储

创意审批是否顺利，关键在于人们能否在合适的时间拿到正确的文件。素材管理是很多活动应用暗中变得令人沮丧的地方——下载慢、文件名混乱、以及“哪个版本是最终版？”的循环。

将文件与元数据分开存储

一个清晰的模式是：对象存储用于实际二进制文件（快速、可扩展、成本低），数据库存元数据（可搜索、结构化）。

数据库应追踪诸如：素材名称、类型、活动、当前版本、上传者、时间戳、审批状态和预览 URL。存储层保存二进制文件以及可选的派生项（如缩略图）。

支持机构实际使用的格式

目标是覆盖多数工作流的一个小集合：

• 图片（JPG/PNG/WebP）
• PDF（品牌指南、印刷校样）
• 视频（若支持则可上传，或作为 Vimeo/YouTube/Frame.io 风格托管的链接）
• 文案草稿（作为文本字段，或带注释的简单文档）

在 UI 中明确指出哪些是可上传的、哪些仅支持链接，以减少失败上传和客服工单。

预览与缩略图（避免不必要下载）

预览能加快审阅并提升客户体验。生成：

• 图片缩略图与更大预览
• PDF 的首页缩略 + 浏览器内查看器
• 视频的封面帧（或当提供链接时内嵌播放器）

这让相关人员在不下载高分辨率文件的情况下浏览交付清单。

安全上传：限制、校验与扫描

及早定义文件限制（最大尺寸、每活动最大数量、支持的扩展名）。验证文件类型和内容（不要只信任扩展名）。如果有企业客户或接收大文件，考虑把病毒/恶意软件扫描加入上传管道。

保留与删除规则

审批常需可追溯性。定义“删除”的含义：

• 软删除 用于日常清理（可恢复，仍可审计）
• 永久删除 用于法律要求与存储控制

配合保留策略（例如活动结束后保留 12–24 个月），防止存储成本无计划增长。

架构概览：前端、后端与服务

带客户审批的活动应用不需要奇技淫巧的基础设施。它需要清晰边界：人类友好的界面、执行规则的 API、文件和数据的存储，以及处理基于时间任务（如提醒）的后台工作。

选择团队能交付的栈

从团队能自信构建和运维的技术开始。如果你们已经熟悉 React + Node、或 Rails、或 Django，通常是 v1 的正确选择。托管偏好也重要：若想要“推送即部署”的简单性，选一个支持你栈并便于日志、扩展和密钥管理的平台。

如果想在不开启大量底层构建的情况下更快推进，像 Koder.ai 这类平台可以帮你通过对话式界面原型并迭代工作流（活动、素材、审批、角色），然后在准备好时导出源码。

核心分层（最小可用）

前端（Web 应用）： 仪表盘、活动时间线与审阅屏。与 API 通信并处理实时体验（加载状态、上传进度、评论线程）。

后端 API： 业务规则的事实源——谁可以批准、何时锁定素材、允许哪些状态转换。保持简单可靠。

数据库： 存储活动、任务、审批、评论和审计事件。

文件存储 + 预览生成： 将上传保存到对象存储（如兼容 S3），并生成缩略/预览以便预览。

后台作业： 任何不应阻塞用户的工作：发送邮件、生成预览、定时提醒、定期报告。

单体还是微服务（v1 保持简单）

对多数机构来说，模块化单体 是理想：一个后端代码库但模块分离良好（素材、审批、通知）。只在真正有帮助的地方加入服务（例如专门的 worker 进程），无需拆分成大量部署。

通知与作业队列

把通知当作一级功能：应用内 + 邮件，并提供退订与清晰的线程关系。作业队列（BullMQ、Sidekiq、Celery 等）让你可靠地发送提醒、重试失败并避免拖慢上传与审批流程。

环境：dev、staging、production

从一开始就规划三个环境：

• 开发（Dev）： 快速迭代，有示例活动数据。
• 预发布（Staging）： 模拟生产设置，供内部测试。
• 生产（Production）： 强化配置、备份、监控。

如果想进一步深入数据部分，继续查看 /blog/data-model-and-database-design。

数据模型与数据库设计

干净的数据模型能让你的活动应用在增长时仍保持简单感。目标是让常见界面（活动列表、素材队列、审批页面）快速且可预测，同时保留后续需要的历史记录。

核心表（你会感谢的最小集合）

从一小组反映机构实际工作方式的表开始：

• organizations：每家机构一行（租户）
• users：内部团队成员，关联 organization
• clients：机构下的客户公司
• campaigns：工作容器，归属于某个客户
• assets：创意文件或链接，归属于活动
• approvals：某素材（或素材版本）的当前审批状态

保持 ID 一致（UUID 或数字 ID 均可）。重要的是每个子记录（clients、campaigns、assets）都带上 organization_id，以便执行数据隔离。

审计 + 活动：捕捉发生的故事，而不只是状态

仅有状态无法解释发生了什么。添加表例如：

• comments：素材上的线程化反馈（含作者与时间戳）
• events（或 activity）：“素材上传”、“发起审阅”、“批准” 的事件
• status_changes：如果需要报告周期时间，可用此表聚焦记录状态变化

这样可以在不膨胀核心表的情况下，使审计轨迹与责任变得直观。

针对真实列表的索引

大多数界面按 client、status、due_date 过滤。添加索引例如：

• (organization_id, client_id)
• (organization_id, status)
• (organization_id, due_date)

也可以为“当前需要审阅”的查询添加复合索引，比如 (organization_id, status, updated_at)。

迁移与模板种子数据

把模式当作产品代码：每次变更都用迁移管理。为模板（默认阶段、示例状态、标准审批步骤）添加种子数据，让新机构可以快速启动，测试环境也有真实感数据。

认证、邀请与安全基础

一个客户审批应用的成败在于信任：客户要有简单的登录方式，团队要确信只有合适的人能看到合适的内容。从最小且机构友好的认证功能开始，后续扩展。

选择合适的登录方式

若用户多数为偶尔登录的客户，邮箱 + 密码 通常是最顺畅的路径。对于大型组织（或企业客户），考虑支持 SSO（Google/Microsoft），以便使用现有公司账号。可以后期同时支持两者——除非目标用户明确期望 SSO，否则别一开始就强制 SSO。

不拖慢工作的邀请机制

邀请应快捷、具角色信息且容错：

• 通过邮箱邀请团队成员和客户，并在邀请时分配角色
• 允许在接受前重发邀请并更改角色
• 把被邀请用户置为“待验证”状态，直到他们验证邮箱

一个好做法是使用魔法链接设置密码，新用户无需一开始记住密码。

安全会话与找回密码

使用安全会话处理（短生命周期访问令牌、轮换刷新令牌、尽量使用 httpOnly cookie）。加入标准的密码重设流程，使用有时效且一次性的令牌并提供清晰的确认界面。

每个请求都要授权校验

认证回答“你是谁？”，授权回答“你能做什么？”。对每个端点都做权限检查——尤其是活动素材、评论与审批的相关接口。不要仅靠隐藏 UI。

在不收集敏感内容的前提下记录日志

保留对审计友好的日志（登录尝试、邀请接受、角色变更、可疑活动），但避免存储秘密信息。记录标识符、时间戳、IP/设备线索和结果——绝不存原始密码、完整文件内容或客户私密备注。

通知、提醒与面向客户的更新

通知是活动应用要么显得有帮助、要么令人厌烦的地方。目标是：在不把每条评论都变成收件箱火场的前提下推动工作前进。

定义重要事件

从一小组高信号触发开始，并在邮件与应用内保持一致：

• 新的审阅请求（请求客户对特定素材/版本进行审批）
• 新评论或提及（尤其是有人被 @ 提及时）
• 批准或拒绝（会解锁下一步的状态变化）
• 到期提醒（临近到期或逾期的审批）

每条通知都要包含“是什么”和下一步操作的直接链接（例如素材审阅页或客户收件箱）。

让用户选择渠道与频率

不同角色需要不同细节级别。给到用户级别的控制：

• 渠道： 邮件、应用内（后续可选 Slack）
• 频率： 实时、每日摘要或“仅在被分配/提及时”

使用智能默认：客户通常要的邮件较少，且他们通常只关心需要他们决策的事项。

通过批量与智能规则防止噪音

把相似更新打包（例如“首页横幅有 3 条新评论”），而不是为每条评论发一封邮件。加入防护措施：

• 不要通知执行该操作的人自己
• 把短时间内的快速连续编辑/评论合并
• 仅在必要时升级（例如逾期提醒）

构建面向客户的审批收件箱

一个专门的 审批收件箱 页面能减少来回：仅展示客户需要现在处理的事项：“等待您处理”的项、到期日以及一键进入正确审阅视图的路径。保持简洁易访问，并在每封审阅邮件中链接到它（例如 /approvals）。

跟踪投递与失败

邮件并非万无一失。存储投递状态（已发送、退信、失败）并智能重试。如果邮件失败，把信息展示给管理员的活动视图，并以应用内通知作为回退，避免流程无声停滞。