artifact: add FPA analysis outputs through round 6

2026-06-20 14:08:46 +08:00
commit 8bf8795f96
105 changed files with 4324 additions and 0 deletions
@@ -0,0 +1,46 @@
+---
+artifact_type: persona
+slug: accountant
+round: 1
+status: draft
+project: maxcpa
+title: Accountant
+---
+
+# 会计师
+
+## 核心目标
+
+把通过邀请进入的潜在客户转化为正式服务案件，收齐完整资料，在截止日前推进工作，并以清晰归档和更少重复催促完成每一个案件。
+
+## 与其他 Persona 的关键区别
+
+- 相比 `Firm Owner`，这个 Persona 处理的是自己被分配到的客户和案件执行，而不是整个事务所的经营总览。
+- 相比 `Client`，这个 Persona 负责核验信息、确认报价、审核上传资料、推进案件状态，并发起签字流程。
+- 这个 Persona 是服务流程中的主要人工操作者，与 AI 协同工作，而不是只做监督。
+
+## 权限边界
+
+- 可以查看和管理分配给自己的客户与案件。
+- 可以审核新的受邀注册客户，并在正式建档前确认客户接待信息。
+- 可以查看 AI 对客户填写信息和上传资料的初步审核结果。
+- 可以调整报价参考、发送最终报价、催补缺件、更新案件状态，并发起签字。
+- 可以查看与自己工作相关的客户服务历史、客户画像信号和介绍来源。
+- 当案件需要直接介入时，可以在系统自动提醒之外发起人工提醒。
+
+## 不可见页面或能力
+
+- 默认不能访问面向 `Firm Owner` 的事务所级财务总览或全会计师生产力视图。
+- 默认不负责控制全局自动化策略、老板级升级收件箱或全局流失管理视图。
+- 不会把邀请码注册页面作为自己的后台操作界面；他们是触发和跟踪这条流程的人，而不是注册动作的执行者。
+
+## 重要约束与假设
+
+- brief 把时间压力和缺件追踪定义为核心痛点，因此这个 Persona 高度依赖截止日可见性和自动收资支持。
+- AI 在这里明确是辅助性的：系统负责起草、识别和提醒，但建档、报价和资料齐全性的最终确认仍由会计师完成。
+- 这个 Persona 需要端到端案件时间线，因为 brief 反复强调“知道每个案件卡在哪里”。
+- 这个 Persona 很可能需要快速访问历史服务记录和客户偏好，以减少重复询问并避免沟通失误。
+
+## 相关文档
+
+- Story Map: `../story-maps/accountant.md`
@@ -0,0 +1,45 @@
+---
+artifact_type: persona
+slug: client
+round: 1
+status: draft
+project: maxcpa
+title: Client
+---
+
+# 客户
+
+## 核心目标
+
+在可信转介绍的前提下，无需安装额外软件，就能完成注册、理解报价、提交所需资料、跟踪进度并完成签字，且尽量避免重复填写和重复沟通。
+
+## 与其他 Persona 的关键区别
+
+- 相比 `Firm Owner` 和 `Accountant`，这个 Persona 是事务所外部用户，只能通过受邀方式参与。
+- 这个 Persona 不管理其他用户、案件或业务规则，只处理自己的资料、报价、文件、提醒和签字任务。
+- 这个 Persona 的成功标准是低摩擦完成和信息清晰，而不是运营效率或全局管理能力。
+
+## 权限边界
+
+- 只能通过专属邀请链接加邀请码进入系统。
+- 可以提交注册和报价所需的个人或企业信息。
+- 只能查看自己的报价、资料清单、进度状态、提醒信息和签字任务。
+- 可以上传所需文件，并查看每一项资料的状态，例如待上传、已收到、需补充、已确认。
+- 可以接收与自己服务旅程相关的自动提醒、确认消息和后续跟进。
+
+## 不可见页面或能力
+
+- 不能看到事务所级仪表盘、收入数据、其他客户、介绍关系图内部细节、会计师工作负载或老板级提醒。
+- 不能访问内部 AI 画像维度、流失评分、会计师私人备注或仅供事务所内部使用的沟通来源标记。
+- 不能修改报价策略、自动化设置、案件分配或归档分类规则。
+
+## 重要约束与假设
+
+- brief 明确提出“无需安装 App”和“仅受邀进入”，因此这个 Persona 对应的体验应当是轻量 Web 访问，而不是复杂门户。
+- 信任关系非常关键，因为每一个客户都来自转介绍；因此接待和注册体验必须保留介绍关系带来的信任上下文。
+- 系统应尽量减少重复提问，因为 brief 把反复收集基础信息定义为痛点之一。
+- 这个 Persona 需要清晰的状态透明度，因为资料齐全性、提醒链路和签字推进都是产品承诺中的核心体验。
+
+## 相关文档
+
+- Story Map: `../story-maps/client.md`
@@ -0,0 +1,49 @@
+---
+artifact_type: persona
+slug: firm-owner
+round: 1
+status: draft
+project: maxcpa
+title: Firm Owner
+---
+
+# 事务所老板
+
+## 核心目标
+
+维持对客户接待、案件进度、收入、转介绍关系和服务风险的全局可见性，让事务所能够在不依赖碎片化人工汇报的前提下及时做出经营决策。
+
+## 与其他 Persona 的关键区别
+
+- 相比 `Accountant`，这个 Persona 关注的是整个事务所，而不只是自己名下的客户和案件。
+- 相比 `Client`，这个 Persona 不负责提交服务资料，而是负责监督客户管道健康度、团队推进效率、自动化策略和高价值客户关系维护。
+- 这是 brief 里唯一被明确描述为既需要经营可见性，又需要控制自动化粒度的角色。
+
+## 权限边界
+
+- 可以查看全量客户、全量案件、全部会计师、全部转介绍关系，以及事务所级别的收入概览。
+- 可以查看整个事务所范围内的逾期事项、紧急事项和即将到期事项。
+- 可以查看报价管道、重要客户提醒、流失预警，以及 AI 生成的客户画像输出。
+- 可以查看每位会计师当前负责的客户、案件数量、临期压力、缺件积压和整体推进节奏。
+- 可以为会计师分配或调整客户与案件归属，并决定哪些事项需要老板直接升级跟进。
+- 可以接收并处理差评、多次改约、长期未联系客户、介绍来源不清等升级事件。
+- 可以按场景或客户分层配置自动化行为，包括全自动、草稿模式和纯人工模式。
+- 可以对涉及金钱承诺、退款、投诉、VIP 处理等敏感决策进行人工介入。
+
+## 不可见页面或能力
+
+- 不需要把面向客户的注册、邀请码输入、资料自助上传流程作为自己的主工作路径。
+- 不需要只为某一个会计师个人待办队列优化的日常资料确认视图。
+- 不应默认依赖属于个别会计师的私人备注或临时工作记录，除非这些内容已经被明确沉淀到系统中共享。
+
+## 重要约束与假设
+
+- brief 将这个 Persona 定位为涉及金钱敏感或声誉敏感事项时的最终升级处理者。
+- brief 隐含表达了两件战略优先级：转介绍关系网络可见性，以及客户资产留存；这两者不是次级报表功能。
+- 这个 Persona 不只是“看报表”，还需要真正管理会计师的工作分配、负载平衡和升级介入边界。
+- 自动化必须保持细粒度可控，因为 VIP 客户处理和高风险场景不能完全交给系统自治。
+- 这个 Persona 很可能需要移动端友好的摘要访问能力，因为 brief 明确描述了“早上 7 点手机早报”的使用场景。
+
+## 相关文档
+
+- Story Map: `../story-maps/firm-owner.md`
@@ -0,0 +1,7 @@
+# Persona Index
+
+| Persona | Core Goal | Story Map | Notes |
+| --- | --- | --- | --- |
+| [Accountant](./accountant.md) |  | [accountant](../story-maps/accountant.md) |  |
+| [Client](./client.md) |  | [client](../story-maps/client.md) |  |
+| [Firm Owner](./firm-owner.md) |  | [firm-owner](../story-maps/firm-owner.md) |  |