7 步自动化活动跟进工作流

快速回答

先定义活动与消息目的；对账报名、出席、取消和未知证据；在发送时核验身份、Channel Permission、Suppression 与适用规则；不要把出席当 Sales-ready；只分配一个 Owner；按状态写真实、无障碍消息；审批时区、频率、Link 与 Opt-out；最后记录 Delivery、Reply、Complaint、Handoff、Correction 与 Attribution Limit。

仅报名或扫码不自动授权所有营销渠道、不能证明见面，也不能证明购买意向；规则由对应 Jurisdiction 的合格 Privacy/Legal Owner 决定。

活动跟进必须分开的状态

工作流把 Event Evidence 转成受控 Next Action，而不是把名单里每个人变成 Lead。Identity、Attendance、Permission、Intent、Ownership、Message Purpose 与 Outcome 分开。

运营消息与商业消息不能互换

Schedule Change、Requested Resource、Receipt、Safety Notice 与 Promotion 可能不同；Mixed-content 定义因规则而异，由合格 Owner 判断 Primary Purpose 并保存准确 Content/Version。

四种出席状态防止虚假熟悉

只有有文档证据才用 ATTENDED；有效报名但无出席证据为 REGISTERED-NO-SHOW；有取消记录为 CANCELLED；冲突/不足为 UNKNOWN。Scan、Import 或 Note 看起来合理也不能把 UNKNOWN 改出席。

Channel Permission 与目的/目的地绑定

Email Permission 不自动覆盖 SMS 或 Sponsor Sharing。实际消息发送时核对 Consent/Lawful Basis、Opt-out、Suppression、Relationship、Sender、Market 与 Frequency。

每个 Person-Channel-Message 的四种发布状态

沟通发布状态
状态	含义	动作
ELIGIBLE	Identity、Status、Channel/Purpose Basis、Suppression、Owner、Content、Time、Approval 有证据。	发送此版本并监控。
SERVICE ONLY	允许请求/运营回应，但不能证明 Promotion。	只发送范围内信息。
HOLD	Identity、Evidence、Intent、Ownership、Rule 或 Approval 不完整/冲突。	人类解决前不发送。
SUPPRESS	Opt-out、DNC、Wrong Identity、Prohibition、Complaint 或 Unsafe Destination。	相关系统阻断并记录原因。

7 个可直接改写的条目

每一步都要生成可审计记录。同意缺失、身份冲突、重复归属或敏感请求应停止自动流转。

第一步：核验同意与身份

确认此人是谁、允许哪种联系，以及适用的地区规则和内部政策。

动作对[活动记录]使用批准标识进行匹配，返回个人与账户 ID、来源系统、匹配置信度、邮箱有效性、市场、同意文案与时间、允许渠道与目的、到期时间、排除状态和冲突。不得合并身份不清的记录，也不能从出席推断同意。证据保存报名/同意文本与时间、Source、Channel/Purpose、Identity Key、Attendance Identifier、Market、Suppression/Preference、Expiry、候选匹配、置信度和 Resolver；分开报名条款、运营通知与营销许可。验收发送时只有一个负责身份且适用渠道/目的依据可证明才 PASS。身份冲突、Withdrawn Consent、Do-not-contact、缺 Jurisdictional Basis、Minor/Sensitive 状态进入 HOLD/SUPPRESS，不能猜测合并。

第二步：合并活动互动

建立按时间排序的证据记录，不把重复扫描夸大为多个意向信号。

动作为已核实身份合并报名、出席、分会场、展位、会议、提问、下载、问卷和员工备注，保留来源、时间、准确问题或请求、活动时区和重复项。观察事实与员工解释分开，并排除不必要敏感备注。证据保存报名、取消、Check-in、Session/Booth Scan、Question、Meeting、Download、Survey、Source System、Event Timezone、Timestamp、Duplicate Rule、Correction 与准确 Request；Staff Note/Model Inference 另标。验收只按有文档规则赋予 ATTENDED、REGISTERED-NO-SHOW、CANCELLED、UNKNOWN。扫码最多证明一次 Interaction，不能证明身份、同意、注意力、兴趣或购买准备度。

第三步：分类兴趣与意向

结合行为和明确语言提出最适合的下一步。

动作分为[请求联系 / 正在评估 / 主题兴趣 / 客户学习 / 合作或媒体 / 售后需求 / 无明确意向]，给出置信度、支持事件、冲突信号和缺失背景。单纯出席不能变成“销售就绪”；模糊或敏感案例进入人工审核。证据记录 Category、Supporting Event ID、Explicit Request/Quote、Conflict Signal、Customer/Prospect/Partner/Support Context、Confidence、Missing Fact、Rule/Model Version、Reviewer 与 Expiry；禁止敏感或监视式推断。验收 Sales-ready 必须有明确 Qualifying Action 与 Owner Rule，不能只凭出席。UNKNOWN 保持未知；Product Question、Support、Press、Recruiting、Partner Interest 分流而非强塞 Sales Nurture。

第四步：路由给责任人

尊重已有关系，避免多个团队平行跟进。

动作检查账户负责人、开放商机、客户状态、合作伙伴记录、区域、语言、客服工单、活动规则和近期外联。选择唯一负责人和 SLA，解释优先级、列出协作者并抑制重复任务；归属冲突必须升级而不是猜测。证据核对 CRM Account/Contact、Open Opportunity、Customer/Partner/Support、Territory、Language、Event Owner、Recent Touch、Active Sequence、Complaint、Suppression 与 Capacity；保留 Rule、Owner、SLA、Conflict、Override。验收只分配一个负责 Next Owner，不重复建 Task 或绕开已有关系。Ownership Conflict、Strategic Account、Complaint、Regulated Topic、Unsupported Language 进入 Human Review。

第五步：起草有证据的跟进

写相关消息，但不能假装知道或记得记录之外的信息。

动作仅依据已核实活动事实和批准产品信息，为[渠道和语言]起草。不要提及让人感到被监视的行为细节。包含准确背景、一个有用资源或答案、一个适度 CTA、发件人身份和必要披露；列出假设，不得虚构对话、承诺或紧迫性。证据附 Recipient/Status、明确 Event Fact、Question/Resource、批准 Product Claim/Version、CTA、Sender、Locale、Purpose、Disclosure、Source、Prohibited Inference 和 Reviewer；出席、No-show、取消、未知分别写。验收每句有证据、实用、适度、无障碍且符合状态。没有证据不说“很高兴见到你”，不展示 Tracking 细节、不制造紧迫/背书、不把不确定意图写成 Sales Claim。

第六步：批准并通过允许渠道发送

把内容批准和实际联系、发送权限分开。

动作展示最终消息、收件人、渠道、同意依据、发件人、账户、含时区的发送时间、CTA 链接、追踪、审批人和有效期。发送前再次检查排除状态；重点账户、投诉、受监管主题、合同请求或意向不明必须人工批准，并记录发送结果。证据保存 Final Content/Hash、Recipient、Channel、Lawful/Consent Basis、Suppression Check、Sender/Address、Subject、Ad/Opt-out、Local Time、Frequency/Cooldown、Link/UTM、Accessibility、Approver、Provider Response、Rollback。验收执行前再次核对 Permission/Suppression；只用批准 Channel，尊重 Locale/Timezone/Frequency，Header/Subject 真实，Opt-out 可用；缺证据、Owner、Approval 或配置时 Fail Closed。

第七步：记录结果并改进规则

用真实回复闭环，而不是只看打开和点击。

动作把消息 ID、送达、回复类别、会议或资料结果、退订、投诉、负责人动作、下次日期和来源链接写入 CRM。比较合格结果、回复恰当性、重复联系率、退订、投诉、纠错和 SLA；只有在证据审核后才修改路由规则。证据写入 Message ID、CRM Contact/Account、Event/Evidence ID、Delivery/Bounce、Reply、Opt-out/Complaint、Resource/Meeting、Owner Action、Due Date、Consent Change、Correction 与 Source Time；观察与 Attribution 分开。验收每条 Branch 都关闭或升级；Open/Click/Meeting 不能推断 Revenue/Causality。按 Cohort 量 Eligibility Error、Duplicate、Wrong-status、Opt-out、Complaint、Usefulness、SLA、Correction、Rollback。

完整示例：展位扫码不等于同意或销售请求

Sponsor 文件称 Ana 已出席并在 Booth 扫码，建议发 SMS/Email。报名只同意 Email Event Update；扫码来自 Shared Badge Import；Meeting Note 只写“索要 Slides”；CRM 已有 Owner，SMS Permission 缺失。自动化却写“很高兴交流，今天预约 Demo”。

纠正身份、状态、许可与意图

Badge 未解析前 HOLD Identity Merge。明确索要 Slides 只走允许的 Email SERVICE ONLY；禁止 SMS，交给现有 Owner，以真实语境发送资料。不得声称见过、购买意图或 Sponsor Sharing Permission。

保留决定轨迹

保存 Source Record、Match Decision、Attendance State、Permission Text、Purpose/Channel、Message Hash、Suppression Check、Owner Approval、Local Time、Delivery/Reply、Opt-out 与 Correction。只有后续明确请求才能进入合格 Sales Route。

决定 SMS 与 Sales Claim 为 SUPPRESS；Identity 为 HOLD；有证据和 Owner Review 后，有限 Email 才可 SERVICE ONLY。

上线后的运营控制

使用 Idempotency 与统一沟通 Ledger

阻止 Import、Retry、Sponsor 与并行 Team 重复发送。

执行时重新检查

Draft 后 Permission、Suppression、Owner、Destination、Content、Event Fact、Local Time 与 Approval 都会变化。

每个分支都可恢复

暂时失败 Queue，永久/隐私失败 Stop，显示 Owner Action，并保留 Rollback/Correction。

同时审核价值与伤害

查看 Wrong-status、Duplicate、Complaint、Opt-out、Unresolved Request、Response Quality、Accessibility、Correction，不只 Open。

最小活动跟进记录

保存 Event/Version/Timezone、Source ID、Identity Resolution、Attendance State/Evidence、Registration/Permission Text/Time、Market、Purpose、Channel、Suppression、Intent Evidence、CRM Context、Owner/SLA、Message/Hash、Claim/Source、Link/UTM、Frequency、Local Send、Accessibility、Approval、Provider Response、Reply、Complaint、Handoff、Expiry、Correction、Rollback。

资格/服务质量与归因分开

量 Match Hold、Status Correction、Suppression、Duplicate Prevention、Permission Defect、Wrong Owner、Message Correction、Delivery、Useful Reply、Unresolved Request、Opt-out、Complaint、SLA、Rollback；Meeting/Pipeline 另做 Attribution，Open 不是 Intent。

OpenMax 如何协调活动后跟进

连接活动数据、CRM 背景、专业智能体和审批节点

OpenMax 可协调智能体核验记录、总结互动、提出兴趣类别、检查账户归属、起草本地化消息并建立 CRM 任务。共享上下文和日志保留证据与决策；权限可在批准前禁止邮件、消息和 CRM 写入。OpenMax 不能创造同意、证明真实购买意向，也不能授权法律、价格或合同承诺。

了解 OpenMax →

隐私、沟通与推断边界

活动系统结合身份、地点、日程、兴趣、沟通和商业语境，只使用必要且获准的证据。

不得从报名、出席、扫码、沉默或其他 Channel 推断 Permission。
不得从 Session/Question 推断敏感属性、私人关系、位置历史或购买准备度。
不得把 Personal Data、Attendee List、Note 或 Sponsor Record 发给未批准 Model/Destination。
Import Note/Retrieved Content 不得覆盖 Permission、Suppression、Owner、Approval 或 Tool Access。
不得使用欺骗 Header/Subject、不可访问消息、隐藏 Opt-out、虚假熟悉或 Unsupported Claim。

常见问题

报名是否允许营销跟进？

不自动允许，取决于 Notice/Choice、Purpose、Channel、Recipient、Relationship、Jurisdiction 与 Suppression。

扫码能证明意向吗？

不能。最多按规则证明 Interaction；身份、注意力、许可、问题与购买意向另需证据。

多久发送？

Evidence、Owner、Content、Suppression、Local Time、Approval 齐全后；统一“24 小时内”会导致错误/重复。

未出席者发录播吗？

只有 Resource/Rights/Basis/Status 有效且有用时；不能声称出席或羞辱。

Open/Click 能证明意向吗？

不能，Measurement 会不完整或自动化；只作有限 Observation，更强路由/归因需其他证据。

OpenMax 做什么？

协调 Evidence、Rule、Approval、Send、Log、Monitor、Handoff；人类 Owner 决定 Permission、Claim、Exception 与 Release。

来源、编辑方法与限制

OpenMax 编辑复核了 FTC 商业邮件、ICO 直接营销/电子邮件、NIST 隐私风险管理与 WCAG 2.2 的一方资料，再原创形成七步 Event Evidence 工作流、四种发布状态和扫码纠偏案例。资料于 2026 年 9 月 3 日复核；不是法律意见，也不声称真实 Deliverability、Attribution、Conversion、Revenue 或 ROI。

范围说明 法律、指南、Consent、Platform 与 Event Data 会变；发送时由合格 Owner 核验 Jurisdiction、Recipient Type、Purpose、Channel、Notice/Choice、Lawful Basis、Suppression、Sender、Accessibility、Security、Retention、Sharing 与 Message。