销售操作员发现重复联系人时，联系人记录已经打开。在这个示例工作流中，自动化可以解决重复，但操作员必须打开另一个看板、搜索同一联系人，再回到 CRM 核对结果。自动化可能很快，围绕它的往返却不快。
这提出一个设计自动化时容易漏掉的产品问题：结果应该出现在哪里？
一段关于职场自动化的已收录对话主张在权威记录所在系统内行动，而不是让每位用户学习新界面。这是设计假设，不是特定实现提高采用率的证据。它的用处是把设计单位从屏幕变成已完成的任务。
沿着记录、决定与交接走
画一项真实任务。记录最先出现在哪儿？谁决定它准备好了？此人要查看什么？在哪儿确认变更生效？数清步骤以及需要复制或重新输入上下文的地方。
在想象中的重复联系人案例里，操作员已有客户记录。记录旁边的建议可以展示冲突字段与拟议合并，审核留在决策旁边，结果出现在更新后的记录上。哪怕新看板在演示里更整洁，这条路径也许步骤更少。
- 打开记录现有工作相同上下文
- 审查建议冲突字段由人决定
- 授权变更正确范围后置条件
- 检查结果更新后的记录
来源讨论也区分可移除步骤、确定性动作、需要判断的动作和人工批准。位置对每种情况影响不同。确定性更新可以不显示界面而运行，留下清楚的状态。含糊的合并需要解释和审核点。有后果的动作无论界面在哪里，都需要负责人的权限。
多业务工具集成指南要求确定权威来源。这个决定帮助放置交互：记录负责人所在之处，通常自然适合检查和修正。不过，不是每款工具都能显示所有必要解释。
嵌入的结果仍需可检查的轨迹
“不做新界面”可能变成遮住控制缺失的口号。如果自动化在 CRM 中更改记录，用户要知道改了什么、为何改、另一系统现在是否一致。任务跨两套系统时，一句“完成”的内嵌消息太单薄。
设计可能需要在工作工具里显示紧凑状态，在别处提供更深入的历史。它们服务于不同阶段。操作员要处理当前记录；管理员可能要审查失败任务、权限与跨账户规律。最好的界面因此可能不止一个，每个都对应任务。
Tajo 现有 MCP 活动资源包含结果、阶段和可展开的原始事件数据。下方示意图把这一想法放进对话，并加入拟议的验证面板。操作员可以先读即时结果，必要时再检查证据。这个布局并不证明它兼容所有宿主应用。
写入完成仍需证据
客户同步完成了吗？
写入已应用，验证待进行。
尚未检查目标系统的状态。
同步活动
- 请求已接受
- 更新已应用
- 目标系统检查待进行
示例运行 · 14:32 UTC
已知信息
- 服务商响应
- 已接受
- 写入结果
- 已应用
- 从目标系统回读
- 待进行
调用成功不能证明最终状态。
此拟议布局参考 Tajo 的活动记录。图中增加了验证状态，并不表示目标系统回读功能已经实现。
再看第二个示例：商店经理想知道测试订单是否产生预期客户更新。订单旁的简短结果可显示目标记录与状态；单独的集成控制台可显示映射规则和错误历史。Brevo 与 Shopify 集成指南建议使用同步数据之前，在目标系统核对测试联系人和订单。界面应帮助人做这项检查，而不是只宣布请求已发送。
这一区分防止常见陷阱：工具打开容易，却不容易信任。在用户工作处显示后置条件，可能比从看板里少点一次更有价值。但如果现有应用无法呈现足够背景，把整个决定塞进小通知里会让任务更难。
测试路径，不测偏好
把两种设计交给真正做事的人：嵌入式提示与独立页面。给他们同样的案例。观察他们能否找到记录、理解拟议动作、发现错误建议并确认结果。统计交接与错误假设，而不只统计秒数。
便利与权限要分开。记录旁的按钮仍须遵守调用者权限和工作流的批准规则。任务专家塑造自动化的文章解释了为何懂异常的人应定义异常，同时由系统强制访问和数据契约。
新增屏幕有合理原因：跨系统诊断、设置、批量审核和审计，可能超过 CRM 或商店后台所能清晰展示的范围。正确问题是，新屏幕能否帮助完成它要求用户暂时离开的任务。
测试设计时，要包括处理异常的人，而不只是走通正常路径的人。紧凑的内嵌动作可能很适合普通记录，却不能让异常负责人看到必要历史。界面应让交接可见，同时让顺畅路径短。
界面承载必要决定或证明时，才值得存在。如果工作能在起点完成并核对，另一块屏幕就是绕路。
常见问题
每项自动化都该有自己的看板吗？
不该。先问用户在哪里发现问题并做决定。现有记录、通知或审核队列，可能是显示结果更直接的地方。
什么时候需要独立界面？
当人们需要跨系统调查、配置、监督或历史，而现有工具无法清晰展示时。要衡量它增加了多少步骤。
把结果嵌进另一款工具就不用控制了吗？
不是。访问、审核、审计和失败处理仍需明确设计。按钮的位置不会授予更改记录的权限。