金融科技 SaaS 中的交互式入门和应用内提示场景（B2B、KYC 和反欺诈）

初步情况：B2B 金融科技 SaaS 推出了新的自助服务，用于货币转账和公司卡，但根据分析，62% 的用户没有达到 KYC 完成步骤，35% 的验证申请因文件错误而被拒绝。现在提示和文字分散在界面和知识库之间，语气不统一，关键地方没有处理错误和异议的脚本。

技术环境和主题领域：产品在网络上（React），应用内提示和模式窗口通过 Pendo 或 Appcues（我们可以访问其中一种工具）实现，事件和漏斗在 GA4 + Amplitude 中查看。入职流程包括创建公司、添加受益人、上传文件、通过检查（制裁、PEP、地址）、连接第一种付款方式和测试转账。需要仔细研究合规要求和承诺限制的措辞。

任务：开发用于交互式入门和上下文提示的脚本（不仅仅是文本），包括用户行为和系统状态的分叉。

具体结果：
- 包含阶段、触发器、显示条件和预期用户操作的入门场景地图
- 应用内元素的一组文本：工具提示、清单、模式窗口、空状态、微错误、确认、警告、KYC 检查状态文本、指定语气内的 2 个语气选项（中性和更友好）
- 处理错误和返回流程的场景：文档被拒绝时我们会显示什么、我们要求您更正什么、我们如何在不透露内部反欺诈规则的情况下解释原因
- 对应表：分析事件 - 脚本步骤 - 目标 - 文本 - UI 组件 - 本地化键
- 针对 2-3 个漏斗瓶颈和假设制定的 A-B 测试建议

工作阶段：
1) 快速审核当前屏幕和现有文本，分析漏斗和 5-10 个关键 Amplitude/GA4 事件，记录有问题的步骤
2) 场景设计：按角色（公司所有者、会计师）、按 KYC 状态（等待、请求附加数据、拒绝）、按公司类型（有限责任公司/独资经营者）进行分支
3) 编写文本并以方便导入 Pendo/Appcues 和开发人员的格式进行组装
4）根据产品经理的意见和合规性进行2轮编辑，最终校对术语和清晰度

限制：
- 您不能做出法律承诺、使用"之类的语言保证"的通过或披露反欺诈的具体原因/规则
- 考虑到用户经常与文档同时填写表格的事实，文本应该简洁易懂，没有混乱
- 俄语，但 KYC/PEP/制裁等术语如果在第一次出现时得到解释，则可以接受

可衡量的验收标准：
- 覆盖至少 25 个关键入职接触点，包括至少 8 个错误/异常场景
- 每个场景都有显示触发、终止条件和预期的用户操作
- 所有文本均在限制范围内：工具提示最多 140 个字符，模态窗口标题最多 60 个字符，模态窗口的主要文本最多 400 个字符，CTA 按钮最多 18 个字符
- 对应表至少包含 25 行，并包含格式为 onboarding.step_name.element 的本地化键
- 包括两轮编辑，最终版本在术语和状态上没有矛盾

来自客户的访问和材料：访问暂存、Figma 中的当前文本、上传 2-3 个漏斗报告以及通用形式的文档拒绝的典型原因列表（无内部方法）。