artifact: add FPA analysis outputs through round 6
This commit is contained in:
mytool2002
+21
@@ -0,0 +1,21 @@
|
||||
# Local repo-skill development artifacts
|
||||
.agents/
|
||||
|
||||
# Analysis output artifacts that do not belong in the published skill package
|
||||
docs/
|
||||
specs/
|
||||
|
||||
# Legacy local reference kept outside the published skill package
|
||||
frontend-decomposition-methodology.md
|
||||
|
||||
# Python and local workflow state
|
||||
.venv/
|
||||
__pycache__/
|
||||
.pytest_cache/
|
||||
.ruff_cache/
|
||||
.env
|
||||
.frontend-project-analysis/
|
||||
|
||||
# macOS and local temp artifacts
|
||||
.DS_Store
|
||||
tmp/
|
||||
@@ -0,0 +1 @@
|
||||
3.12
|
||||
@@ -0,0 +1,384 @@
|
||||
# 会计师作战指挥部_产品功能规划
|
||||
|
||||
## 文档信息
|
||||
|
||||
- 产品名称：会计师作战指挥部
|
||||
- 英文名：Accountant Command Center
|
||||
- 标语：一个事务所的 AI 管家
|
||||
- 价值主张：把所有熟人介绍来的客户、所有案件、所有跟进动作合到一处
|
||||
- 出品方：Maxta, Inc.
|
||||
- 年份：2026
|
||||
- 版本：产品功能规划 v1
|
||||
|
||||
## 产品定义
|
||||
|
||||
会计师作战指挥部是开在你事务所里的一个 AI 管家。它替你接待通过熟人介绍进来的客户、记得每个客户做过什么、提醒你该跟谁联系、告诉你今天哪一个案件快到截止日期。
|
||||
|
||||
## 它替你解决三件事
|
||||
|
||||
### 第一件 | 熟人介绍来的客户，靠微信备注和 Excel 根本记不住
|
||||
|
||||
老客户今天在微信把新朋友拉进群介绍，你随手回了一句。明天对方发邮件来问价格，后天电话改预约时间，下周到门口签字。你记得这四条消息都是同一个人吗？现在的系统看到的是四条没关联的记录。会计师作战指挥部看到的是一个客户，并且记得他是谁介绍来的。
|
||||
|
||||
### 第二件 | 会计师在处理案件时没时间催资料，客户拖着不交
|
||||
|
||||
会计师核对报表的时候没法一条一条发催促消息。客户资料迟交两周，截止日期就压上来了。会计师作战指挥部替你追每一份缺件，缺什么系统直接显示，不靠会计师自己记。
|
||||
|
||||
### 第三件 | 客户是事务所最值钱的东西，但没有沉淀下来
|
||||
|
||||
办公室的租约会到期，会计师会离职。客户档案才是真资产。每个通过熟人介绍来的客户，他背后的关系网络、他历年的服务记录、他的偏好与雷区，这些只有沉淀在系统里，才是事务所真正的壁垒。
|
||||
|
||||
## 客户进来的唯一方式：熟人介绍
|
||||
|
||||
这里没有公开获客，没有广告，没有陌生人扫码进来。每一个客户都来自老客户、朋友或合作伙伴的介绍。会计师作战指挥部的设计就是围绕这一件事，把口口相传的信任关系，变成可追踪、可管理、可沉淀的系统资产。
|
||||
|
||||
### 引流与建档流程
|
||||
|
||||
1. 熟人介绍
|
||||
老客户、朋友、合作伙伴把新客户介绍给事务所。
|
||||
2. 发出邀请链接
|
||||
会计师一键生成专属邀请链接，发给新客户。
|
||||
3. 邀请码注册
|
||||
客户点击链接，输入邀请码，完成注册。
|
||||
4. 填写信息
|
||||
客户填写基本信息和服务需求，系统初步检查。
|
||||
5. 会计师建档
|
||||
会计师确认后，客户正式建档，进入服务流程。
|
||||
|
||||
系统自动记录谁介绍了这个客户，形成介绍关系图谱。每一个介绍人都在档案里有迹可查。事务所不再靠微信备注、短信记录、Excel 表格手动管理这张关系网。
|
||||
|
||||
## 六大核心能力
|
||||
|
||||
### 01 接客
|
||||
|
||||
客户通过专属邀请链接进入，系统自动记录客户来源与介绍关系，不靠微信备注手动管理。
|
||||
|
||||
### 02 建档
|
||||
|
||||
AI 初步审核客户填写的信息，会计师做最终确认。确认后自动形成客户档案，长期可查。
|
||||
|
||||
### 03 报价
|
||||
|
||||
系统根据客户情况生成报价参考，会计师确认修改后一键发送，客户收到清楚的报价单。
|
||||
|
||||
### 04 收资料
|
||||
|
||||
客户按清单上传文件，AI 自动识别审核，实时显示每项状态：待上传 / 已收到 / 需补充 / 已确认。
|
||||
|
||||
### 05 推案件
|
||||
|
||||
系统自动催促客户，截止日期清单一目了然，会计师全程可追踪，也可一键手动再次提醒。
|
||||
|
||||
### 06 归档
|
||||
|
||||
服务完成后资料、签字文件、历史记录全部归档，AI 形成客户画像，帮会计师分类管理。
|
||||
|
||||
## 三类用户，一个平台
|
||||
|
||||
### 事务所老板
|
||||
|
||||
定位：全局视角，管人管钱管进度
|
||||
|
||||
- 今日案件总览（过期 / 紧急 / 正常）
|
||||
- 每位会计师的工作进度
|
||||
- 哪些客户还没交资料
|
||||
- 哪些案件快到截止日期
|
||||
- 哪些新客需要人工确认建档
|
||||
- 收入概况与待确认报价
|
||||
- 客户转介绍记录与关系图谱
|
||||
- 重要客户提醒与流失预警
|
||||
- 客户分类与 AI 画像
|
||||
|
||||
### 会计师
|
||||
|
||||
定位：只看自己负责的客户
|
||||
|
||||
- 我的客户列表与今日待办案件
|
||||
- 新客来源审核与最终建档确认
|
||||
- 查看 AI 初步审核结果
|
||||
- 确认客户资料是否交齐
|
||||
- 确认并一键发送最终报价
|
||||
- 一键催客户补交缺件
|
||||
- 查看客户历史服务记录
|
||||
- 发起签字 / 更新案件状态
|
||||
- 完成后归档
|
||||
|
||||
### 客户
|
||||
|
||||
定位：凭邀请码进入，无需安装任何 App
|
||||
|
||||
- 通过专属邀请链接注册
|
||||
- 输入邀请码完成身份确认
|
||||
- 填写基本信息与服务需求
|
||||
- 查看会计师发来的报价单
|
||||
- 按清单上传所需文件
|
||||
- 接收缺件提醒，查看进度
|
||||
- 查看资料是否已全部确认
|
||||
- 在线签字
|
||||
- 接收会计师主动提醒
|
||||
|
||||
## 案件全程状态追踪
|
||||
|
||||
案件状态链路：
|
||||
|
||||
`新客户 -> 待审核 -> 待建档 -> 待报价 -> 待客户确认 -> 待上传资料 -> 资料初审中 -> 待会计师确认 -> 会计处理中 -> 待签字 -> 已完成`
|
||||
|
||||
说明：每个案件在哪个阶段，老板和每位会计师随时看得清楚。
|
||||
|
||||
## 客户旅程：从被介绍到长期资产的五个阶段
|
||||
|
||||
客户生命周期：
|
||||
|
||||
`被介绍客户 -> 注册客户 -> 报价客户 -> 服务中客户 -> 长期客户`
|
||||
|
||||
### 阶段一：让熟人介绍变成可追踪的客户
|
||||
|
||||
- 老客户或合作伙伴把新客户介绍给事务所
|
||||
- 会计师一键生成专属邀请链接发给新客户
|
||||
- 客户点击链接，输入邀请码，完成注册
|
||||
- 系统自动记录来源：谁介绍了这个人
|
||||
|
||||
### 阶段二：让客户快速完成注册和信息提交
|
||||
|
||||
- 客户填写姓名、电话、邮箱、公司名
|
||||
- 填写 SSN / EIN / 地址等基础信息
|
||||
- 系统初步检查，会计师做最终确认
|
||||
- 不需要来回问十几遍基础信息
|
||||
|
||||
### 阶段三：让建档和报价更清楚
|
||||
|
||||
- 系统根据客户填写情况生成报价参考
|
||||
- 会计师确认修改后一键发送最终报价
|
||||
- 客户看到：做什么 / 多少钱 / 需要哪些资料
|
||||
- 客户确认报价后正式进入服务流程
|
||||
|
||||
### 阶段四：让资料收集不再混乱
|
||||
|
||||
- 系统按服务类型自动生成资料清单
|
||||
- AI 识别并审核客户上传的每份文件
|
||||
- 每项状态实时显示：待上传 / 已收到 / 需补充 / 已确认
|
||||
- 系统自动催促，会计师也可一键手动再次提醒
|
||||
|
||||
### 阶段五：把一次服务变成长期客户资产
|
||||
|
||||
- 服务完成后资料、历史文件、签字记录全部归档
|
||||
- AI 形成客户画像：个人 / 公司 / 高价值 / 资料慢 / 需跟进
|
||||
- 下次客户再来，不需要从头问一遍
|
||||
- 客户变成事务所长期可维护的资产
|
||||
|
||||
## 客户档案 | 事务所最值钱的资产
|
||||
|
||||
传统系统的客户档案是表格：名字、电话、发票记录。会计师作战指挥部的客户档案是客户战史：可累积、可迁移、可继承。
|
||||
|
||||
### 档案维度
|
||||
|
||||
| 类别 | 内容 |
|
||||
| --- | --- |
|
||||
| 基础信息 | 姓名、公司名、主电话、主邮箱、SSN / EIN、地址、生日 |
|
||||
| 全渠道身份 | 邮箱、WhatsApp、电话、付款记录，多渠道行为归一档案 |
|
||||
| 全渠道消息流 | 所有渠道消息按时间合并，AI 回复和人工回复都标记来源 |
|
||||
| 服务历史 | 每次服务内容、负责会计师、报价、最终收费、完成时间 |
|
||||
| 文件档案 | 历年上传文件、签字记录、报告 PDF，按年份分类可随时调取 |
|
||||
| 介绍关系图谱 | 谁介绍过来的、推荐过谁、家庭或公司关联账户 |
|
||||
| AI 综合画像 | 消费力等级、忠诚度、流失风险、推荐价值，4 个维度自动更新 |
|
||||
| 偏好与雷区 | 喜欢什么沟通方式、对什么问题敏感、哪些话题会触雷 |
|
||||
| 会计师自定义 | 自由打标签、写私人备注（客户不可见）、分配负责人 |
|
||||
|
||||
### AI 综合画像四个维度
|
||||
|
||||
#### 消费力
|
||||
|
||||
基于近 12 个月平均客单价 + 服务频次。High / Mid / Low 三档。
|
||||
|
||||
#### 忠诚度
|
||||
|
||||
0-100 评分。到店次数 + 复购率 + 推荐贡献加权。
|
||||
|
||||
#### 流失风险
|
||||
|
||||
基于上次服务间隔、改约次数、沉默天数、负面沟通信号。
|
||||
|
||||
#### 推荐价值
|
||||
|
||||
推荐到店的客户数乘以这些客户的 LTV。高推荐人单独标记。
|
||||
|
||||
## 会计师的一天
|
||||
|
||||
### 早上：作战台
|
||||
|
||||
按优先级查看今日案件（过期 / 紧急 / 正常）。系统显示：今天多少客户要处理、哪些资料未交齐、哪些快到截止日期、哪些新客待建档确认。老板看全所，会计师看自己的。
|
||||
|
||||
### 上午：新客与报价
|
||||
|
||||
查看通过邀请链接注册的新客户资料，确认来源无误后正式建档。系统生成报价参考，会计师确认后一键发送给客户。
|
||||
|
||||
### 中午：确认文件
|
||||
|
||||
AI 先识别客户上传的文件并提示：哪些已上传、哪些不完整、哪些和客户信息不匹配、哪些还缺。会计师做最终确认，系统自动或手动催客户补交。
|
||||
|
||||
### 下午：推进案件
|
||||
|
||||
查看每个案件当前状态。案件卡在哪里一目了然。系统持续提醒客户，避免错过截止日期。会计师可以随时追踪每一个案件的完整过程。
|
||||
|
||||
### 傍晚：签字收尾
|
||||
|
||||
发起客户在线签字，客户收到提醒后完成签署，签字记录自动归档，会计师完成提交与归档。
|
||||
|
||||
### 晚上：复盘明日
|
||||
|
||||
系统自动整理：今天新增多少客户、哪些来自推荐、哪些报价已发、哪些资料还没齐、明天哪些案件优先处理。老板不用问人，会计师不用靠记忆管理客户。
|
||||
|
||||
## 早报 | 早上 7 点推送到手机
|
||||
|
||||
一打开手机第一屏就是今天该关心的事，不是日历，不是收入数字，是决策建议。每一项都可以一键展开看详情、一键执行、一键忽略。
|
||||
|
||||
| 模块 | 示例内容 |
|
||||
| --- | --- |
|
||||
| 今日案件概况 | 今日 12 个案件待处理 | 3 个过期 | 2 个今日截止 | 7 个进行中 |
|
||||
| VIP 客户提醒 | 王女士公司报税今日截止，建议你亲自确认文件是否齐全 |
|
||||
| 风险预警 | Johnson LLC 材料缺 2 项，截止日期后天，建议今天催 |
|
||||
| 新客待确认 | 3 位新客通过邀请链接注册，等待会计师最终建档确认 |
|
||||
| 报价待回复 | 已发出 2 份报价，客户尚未回复，一键查看并跟进 |
|
||||
| 流失客户 | 4 位老客户超 90 天未联系，一键查看召回建议 |
|
||||
| 收入概况 | 本月已确认收入 $12,400 | 报价中 $6,200 | 较上月 +15% |
|
||||
| 介绍关系审核 | 1 位新客来源待确认，谁介绍的？一键标记 |
|
||||
|
||||
## AI 管家 | 你可以问任何关于生意的问题
|
||||
|
||||
AI 管家不是 ChatGPT。它接入了你事务所所有数据：客户、会计师、案件、收入、消息、介绍关系。你用中文或英文问任何问题，它都答得上。
|
||||
|
||||
### 可提问问题与 AI 动作
|
||||
|
||||
| 你可以问 | AI 管家做什么 |
|
||||
| --- | --- |
|
||||
| 上月做公司报税的客户里，谁 3 个月没回来？ | 查档案 + 算流失风险 + 推荐召回方案 |
|
||||
| Sarah 这月的案件利润率怎么样？ | 查 commission + 算案件平均耗时 + 给出效率排名 |
|
||||
| 个人报税涨 $50，影响是什么？ | 查历史价格敏感度 + 算预期影响 + 流失风险评估 |
|
||||
| 最近哪些客户最值得我亲自维护？ | VIP 三维评级排序 + 推荐最佳沟通时间与方式 |
|
||||
| 哪些老客户今年还没联系过？ | 档案匹配 + 生成个性化召回文案 + 一键发送 |
|
||||
| 王先生介绍过来几个客户，这些客户合计贡献多少？ | 关系图谱追踪 + 汇总介绍链的 LTV |
|
||||
| 上周哪些案件差点超期？原因是什么？ | 聚合风险事件 + 找出流程瓶颈 + 给出改进建议 |
|
||||
|
||||
### AI 管家的边界
|
||||
|
||||
不替你做最终决策，给你数据和建议。涉及钱的承诺、退款、投诉自动停下来转给你。所有回答都附带数据出处，可点开追溯。
|
||||
|
||||
## 一个完整客户的全流程实例
|
||||
|
||||
### Linda Chen | 从被老客户王先生介绍，到成为事务所长期客户的全过程
|
||||
|
||||
客户状态流转：
|
||||
|
||||
`新客 -> 建档 -> 报价 -> 资料收集 -> 服务完成 -> 第二年主动回来`
|
||||
|
||||
#### Day 1 • 14:32 王先生介绍
|
||||
|
||||
王先生在微信里跟会计师张先生说：“我朋友 Linda，刚开了个网店，要报税，你帮她看一下。”
|
||||
|
||||
张先生在作战指挥部里一键生成 Linda 的专属邀请链接，发给她。
|
||||
|
||||
系统自动记录来源：由王先生介绍。王先生成为 Linda 关系图谱的第一个节点。
|
||||
|
||||
#### Day 1 • 15:05 Linda 点击链接完成注册
|
||||
|
||||
Linda 填写：姓名、电话、邮箱、公司名（Linda's Shop LLC）、大概年收入、需要的服务（LLC 年报 + 个人报税）。
|
||||
|
||||
系统做初步检查，信息完整，自动推送给张先生待建档确认。
|
||||
|
||||
张先生看了一眼，点确认建档。Linda 的客户档案正式建立。
|
||||
|
||||
系统自动发给 Linda：“您好，档案已建好。我们会根据您的情况准备一份服务报价，请稍等。”
|
||||
|
||||
#### Day 3 • 上午 张先生发出报价
|
||||
|
||||
系统根据 Linda 填写的情况（LLC、网店、首次报税）生成报价参考：$650-$850。
|
||||
|
||||
张先生看了看，改为 $720（含 LLC 年报），点一键发送。
|
||||
|
||||
Linda 收到清楚的报价单：做什么服务、$720、需要提供哪些资料、下一步怎么操作。
|
||||
|
||||
Linda 当天确认报价。系统自动生成资料清单，进入收资料阶段。
|
||||
|
||||
#### Day 3 至 Day 12 资料收集
|
||||
|
||||
清单：EIN 证明 / 1099-K / 银行对账单（全年）/ 上年报税记录（如有）。
|
||||
|
||||
Linda 陆续上传，每上传一项状态自动更新为“已收到”。
|
||||
|
||||
Day 8，AI 发现“银行对账单”只上传了 10-12 月，缺 1-9 月。
|
||||
|
||||
系统自动提醒 Linda：“还差一份完整的银行对账单，目前只有 10 月到 12 月，请补上 1 月到 9 月的部分。”
|
||||
|
||||
Linda Day 10 补交。张先生确认资料齐全，案件进入“会计处理中”。
|
||||
|
||||
#### Day 18 服务完成，发起签字
|
||||
|
||||
张先生处理完，在系统里发起签字。Linda 手机收到提醒，3 分钟完成电子签字。
|
||||
|
||||
签字记录自动归档。案件状态变为“已完成”。
|
||||
|
||||
系统自动发感谢消息 + 满意度问卷。Linda 给 5 分。
|
||||
|
||||
#### 次年 1 月 AI 主动召回
|
||||
|
||||
AI 看到 Linda 的档案：LLC 网店，距上次报税快 12 个月了，今年还没联系过。
|
||||
|
||||
系统自动发：“Linda，税季快到了！去年您的材料都很齐全，今年应该更顺利。张先生还有空位，要提前预留吗？”
|
||||
|
||||
Linda 当天回复：“好，还是找你们。”案件自动重新开启。
|
||||
|
||||
#### 两年后 Linda 是 VIP，并且带来了新客户
|
||||
|
||||
来了 3 次，累计消费 $2,100。推荐了 2 个朋友（Emily、Grace），都进入了系统。
|
||||
|
||||
作战指挥部把她升为 VIP，进入张先生亲自维护清单。
|
||||
|
||||
她的关系图谱：王先生 -> Linda -> Emily -> Grace，4 个客户，全部可追踪。
|
||||
|
||||
下次税季，张先生打开档案第一眼就知道上次做了什么、交了哪些资料、Linda 不喜欢被催太急。
|
||||
|
||||
## 客户运营自动化
|
||||
|
||||
| 场景 | AI 自动动作 |
|
||||
| --- | --- |
|
||||
| 客户通过邀请注册完成 | 发送欢迎消息，提示等待会计师建档确认 |
|
||||
| 会计师确认建档后 | 发送确认消息 + 资料清单 + 下一步指引 |
|
||||
| 报价发出后 48 小时未回 | 自动跟进提醒 | 预警给会计师 |
|
||||
| 资料清单有缺件 | 主动提醒客户补交，显示具体缺哪几项 |
|
||||
| 截止日期前 7 天 | 升级提醒频次，同步推送给负责会计师 |
|
||||
| 服务完成 | 感谢消息 + 满意度问卷 + 引导 Google 评价 |
|
||||
| 3 个月后 | 基于客户历史档案的个性化复诊提醒 |
|
||||
| 客户改约多次 | 推送预警给老板 | 标记可能流失 |
|
||||
| 客户 90 天未联系 | 升级到老板亲自跟进清单 |
|
||||
| 客户留差评 | 立即推送给老板，暂停所有自动消息 |
|
||||
| 客户推荐新客注册成功 | 自动归因，更新介绍关系图谱 |
|
||||
|
||||
## 店主控制粒度
|
||||
|
||||
每一个自动动作老板都可以：
|
||||
|
||||
- 完全打开（AI 全自动）
|
||||
- 草稿模式（AI 起草，老板一键发送）
|
||||
- 关闭
|
||||
- 按客户细化（VIP 客户必须人工，普通客户可自动）
|
||||
|
||||
## 和现有产品比，作战指挥部不一样在哪
|
||||
|
||||
| 维度 | Canopy / TaxDome / Karbon | 会计师作战指挥部 |
|
||||
| --- | --- | --- |
|
||||
| 客户进入方式 | 填在线表单，会计师手动建档 | 邀请链接 + 邀请码，来源自动追踪 |
|
||||
| 客户记录 | 各渠道各一条，手动合并 | 所有渠道归一档案，自动合并 |
|
||||
| 介绍关系 | 没有追踪，靠人记 | 自动记录介绍链，形成关系图谱 |
|
||||
| AI 程度 | AI 写写邮件模板、提示缺件 | AI 接待 | 追料 | 召回 | 决策建议 |
|
||||
| 客户档案 | 名字、电话、文件列表 | 战史 + 雷区 + 介绍图谱 + AI 画像 |
|
||||
| 老板视角 | 看报表，手动问进度 | 每天早报 + AI 管家可问任何问题 |
|
||||
| 客户档案迁移 | 数据孤岛，难以迁出 | 档案可迁移，真正属于事务所 |
|
||||
| 老板负担 | 需要切 5 个 App | 一个收件箱搞定所有事 |
|
||||
|
||||
## 结束语
|
||||
|
||||
会计师作战指挥部。
|
||||
|
||||
少漏单，少漏资料，少反复沟通。
|
||||
|
||||
把每个熟人介绍来的客户，沉淀为事务所长期可维护的资产。
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: accountant-workload-and-assignment
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 会计师负载与分配管理
|
||||
---
|
||||
|
||||
# 会计师负载与分配管理
|
||||
|
||||
## Page
|
||||
|
||||
- 团队推进页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
让老板按会计师维度查看当前客户数、案件数、临期压力、缺件积压和风险事项，并据此调整客户或案件归属，明确下一步由谁跟进。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于老板经营总览中的团队摘要与案件升级分配流程。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 3 / Step 1`: 查看每位会计师当前的推进情况
|
||||
- `事务所老板 / Activity 3 / Step 2`: 调整会计师的客户与案件分配
|
||||
- `事务所老板 / Activity 3 / Step 3`: 确认哪些事项需要老板或会计师额外跟进
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成团队负载判断与任务分配。
|
||||
- 有独立数据来源：会计师名下客户、案件、截止日、缺件和风险事项。
|
||||
- 有独立交互流：查看负载、调整归属、确认跟进责任。
|
||||
- 有跨页面复用潜力：老板总览与升级处理都会消费同一团队分配结果。
|
||||
- 可独立测试：可覆盖负载均衡、重新分配、无人跟进和升级介入等场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: automation-effect-observability
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 自动化效果观察
|
||||
---
|
||||
|
||||
# 自动化效果观察
|
||||
|
||||
## Page
|
||||
|
||||
- 自动化策略页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
让老板看到自动提醒与自动跟进是否真的在减轻团队负担、提升推进效率，而不是只看规则是否开启。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于老板经营总览中的自动化摘要。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 4 / Step 1`: 观察自动提醒和自动跟进的效果
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：评估自动化效果。
|
||||
- 有独立数据来源：提醒发送记录、客户响应、案件推进结果。
|
||||
- 有独立交互流：查看效果、比较前后、识别异常。
|
||||
- 有跨页面复用潜力：摘要报表可复用同一指标。
|
||||
- 可独立测试：可覆盖效果提升、无变化和反向干扰场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: automation-sensitivity-rules
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 敏感场景自动化规则
|
||||
---
|
||||
|
||||
# 敏感场景自动化规则
|
||||
|
||||
## Page
|
||||
|
||||
- 自动化策略页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
支持老板按客户等级、关系敏感度和业务风险调整自动化粒度，避免高价值或敏感场景被一刀切规则伤害。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可与升级异常处理和客户资产页联动。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 4 / Step 2`: 对敏感客户或敏感场景调整处理方式
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：按敏感度控制自动化边界。
|
||||
- 有独立状态与规则：全自动、草稿模式、纯人工等策略。
|
||||
- 有独立交互流：选择范围、调整规则、保存生效。
|
||||
- 有跨页面复用潜力：多个流程都将消费同一策略结果。
|
||||
- 可独立测试：可覆盖 VIP、普通和高风险场景。
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: case-closeout-and-signoff
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 收尾确认与签字发起
|
||||
---
|
||||
|
||||
# 收尾确认与签字发起
|
||||
|
||||
## Page
|
||||
|
||||
- 案件工作台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在案件接近完成时发起最终确认、签字和闭环状态更新，确保服务不是停留在“看起来做完了”，而是完成正式收尾。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 5 / Step 1`: 发起最终确认动作
|
||||
- `会计师 / Activity 5 / Step 2`: 确认客户已完成必要回应
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成案件闭环。
|
||||
- 有独立状态流：待确认、待签字、已完成。
|
||||
- 有独立交互流：发起确认、跟踪回应、完成归档前置状态。
|
||||
- 具备独立演化潜力：后续可能加入更多签字规则。
|
||||
- 可独立测试：可验证未签、已签、超时未回应等情况。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: case-progress-and-risk-tracking
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 案件进度与风险跟踪
|
||||
---
|
||||
|
||||
# 案件进度与风险跟踪
|
||||
|
||||
## Page
|
||||
|
||||
- 案件工作台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
显示案件当前阶段、卡点、截止日和风险信号，帮助会计师决定下一步推进动作，也让老板能在必要时下钻干预，并为团队分配调整提供依据。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于老板经营总览、团队推进和异常处理视图。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 4 / Step 2`: 跟踪每个案件当前卡住的位置
|
||||
- `会计师 / Activity 4 / Step 3`: 在截止日前完成关键推进
|
||||
- `事务所老板 / Activity 1 / Step 2`: 区分逾期、紧急和正常事项
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：识别案件卡点与风险。
|
||||
- 有独立数据来源：案件状态链路、截止日、资料状态、提醒事件。
|
||||
- 有独立交互流：查看时间线、识别卡点、触发下一步处理。
|
||||
- 有跨页面复用潜力：多个老板端页面都会消费同一风险信号。
|
||||
- 可独立测试：可覆盖正常、临期、逾期和阻塞等场景。
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: client-history-archive
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 客户历史归档
|
||||
---
|
||||
|
||||
# 客户历史归档
|
||||
|
||||
## Page
|
||||
|
||||
- 客户档案页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
按客户维度沉淀基础资料、历次服务、文件与签字记录，让团队下次服务时不必从头重问，也让老板能理解长期资产积累。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于案件工作台客户摘要和老板资产视图。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 5 / Step 3`: 让本次服务留下完整记录
|
||||
- `事务所老板 / Activity 5 / Step 3`: 形成可持续维护的经营判断
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成长期客户档案。
|
||||
- 有独立数据来源：客户信息、服务历史、文件与签字记录。
|
||||
- 有独立交互流：查看历史、按年份检索、回看关键记录。
|
||||
- 有跨页面复用潜力：多个页面都依赖档案摘要。
|
||||
- 可独立测试：可覆盖新客户、老客户和历史缺失场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: client-portfolio-segmentation
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 客户资产分层
|
||||
---
|
||||
|
||||
# 客户资产分层
|
||||
|
||||
## Page
|
||||
|
||||
- 客户资产与关系页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
按客户价值、忠诚度、流失风险和推荐价值对客户资产进行分层，让老板能从经营角度理解长期客户池健康度。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于老板经营总览和高价值客户提醒。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 5 / Step 3`: 形成可持续维护的经营判断
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成客户资产分层视图。
|
||||
- 有独立数据来源：客户画像、服务历史、LTV、流失风险。
|
||||
- 有独立交互流：切换分层、查看标签、筛选高价值人群。
|
||||
- 有跨页面复用潜力：多个老板视图都会复用分层结果。
|
||||
- 可独立测试：可覆盖高价值、流失和推荐人群场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: client-profile-intake
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 客户基础信息采集
|
||||
---
|
||||
|
||||
# 客户基础信息采集
|
||||
|
||||
## Page
|
||||
|
||||
- 注册与需求填写页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
收集客户身份、联系方式和基础业务信息，为后续建档、报价和资料清单生成提供完整起点。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于后续客户档案补录与资料核验。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 2 / Step 1`: 填写自己的基本情况
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：建立客户基础档案。
|
||||
- 有独立数据来源：姓名、电话、邮箱、企业与身份字段。
|
||||
- 有独立交互流：填写、校验、保存进度。
|
||||
- 有跨页面复用潜力：客户档案和后续表单会使用同一信息结构。
|
||||
- 可独立测试：可覆盖必填、格式错误、断点续填场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: client-reminder-orchestration
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 客户补件提醒
|
||||
---
|
||||
|
||||
# 客户补件提醒
|
||||
|
||||
## Page
|
||||
|
||||
- 案件工作台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在资料缺失或临近截止时自动或人工发起提醒，并追踪客户后续是否补交，让催办从个人记忆变成系统动作。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可延展到老板端异常升级和自动化策略页。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 3 / Step 3`: 在必要时再次提醒客户补交
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：推动客户补交缺件。
|
||||
- 有独立状态与规则：自动提醒、人工提醒、提醒后等待响应。
|
||||
- 有独立交互流：选择提醒对象、触发提醒、查看结果。
|
||||
- 有跨页面复用潜力：自动化策略会消费同一提醒能力。
|
||||
- 可独立测试：可验证触发条件、频率限制和提醒结果记录。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: client-return-path
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 后续合作入口
|
||||
---
|
||||
|
||||
# 后续合作入口
|
||||
|
||||
## Page
|
||||
|
||||
- 服务完成页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
为客户保留后续再次联系、查看历史结果或继续合作的清晰入口，让一次服务自然沉淀为长期关系。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可用于召回与长期客户维护场景。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 5 / Step 3`: 在未来需要时继续回来合作
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：建立服务后的持续关系入口。
|
||||
- 有独立交互流：查看历史、发起联系、准备再次合作。
|
||||
- 有独立数据来源：历史案件、联系渠道、推荐动作。
|
||||
- 有跨页面复用潜力：长期客户运营会复用同一入口逻辑。
|
||||
- 可独立测试：可覆盖回访、再次合作和无历史场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: client-service-closure
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 服务完成确认
|
||||
---
|
||||
|
||||
# 服务完成确认
|
||||
|
||||
## Page
|
||||
|
||||
- 服务完成页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
明确告知客户本次服务已经正式完成，并把关键完成结果与后续联系预期说清楚。
|
||||
|
||||
## State Type
|
||||
|
||||
- server
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于其他服务类型的完成页模板。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 5 / Step 2`: 获得服务完成的明确信号
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成服务闭环通知。
|
||||
- 有独立数据来源：完成状态、结果摘要、归档信息。
|
||||
- 有独立交互流：查看完成状态、确认结果。
|
||||
- 有跨页面复用潜力：不同案件类型完成页可共用。
|
||||
- 可独立测试：可覆盖完成、部分完成和回退场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: daily-priority-board
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 今日优先级看板
|
||||
---
|
||||
|
||||
# 今日优先级看板
|
||||
|
||||
## Page
|
||||
|
||||
- 会计师作战台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
按过期、临期、新客待审和进行中案件等维度组织当天工作列表，让会计师能先处理最急、最值当先做的事项。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可延展到老板早报或团队总览。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 4 / Step 1`: 根据优先级安排当天要处理的工作
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：生成当天可执行优先级视图。
|
||||
- 有独立数据来源：案件状态、截止日、缺件状态、新客状态。
|
||||
- 有独立交互流：切换分组、筛选优先级、进入具体案件。
|
||||
- 有跨页面复用潜力：老板端也有相似优先级需求。
|
||||
- 可独立测试：可验证排序、分组、空状态和异常状态。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: document-checklist-delivery
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 资料清单交付
|
||||
---
|
||||
|
||||
# 资料清单交付
|
||||
|
||||
## Page
|
||||
|
||||
- 资料提交与进度页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
把当前服务所需资料按清单方式明确交给客户，让客户知道现在需要逐步提交什么，而不是被模糊要求压住。
|
||||
|
||||
## State Type
|
||||
|
||||
- server
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于会计师端资料核验视图。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 4 / Step 1`: 按要求逐步提供资料
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：明确提交任务清单。
|
||||
- 有独立数据来源：服务类型、资料规则、案件要求。
|
||||
- 有独立交互流：查看清单、进入上传、分批完成。
|
||||
- 有跨页面复用潜力：会计师端也消费同一清单结构。
|
||||
- 可独立测试：可覆盖不同服务类型清单与空清单场景。
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: document-completeness-review
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 资料完整性核验
|
||||
---
|
||||
|
||||
# 资料完整性核验
|
||||
|
||||
## Page
|
||||
|
||||
- 案件工作台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
让会计师逐项判断客户资料是否已收到、是否可用、是否需补充，并把结果沉淀成清晰状态，减少来回沟通。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于客户端资料页和老板风险查看。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 3 / Step 1`: 查看还缺哪些资料
|
||||
- `会计师 / Activity 3 / Step 2`: 判断已提交内容是否完整可用
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成资料齐全性判断。
|
||||
- 有独立数据来源：资料清单、上传文件、AI 审核结果。
|
||||
- 有独立交互流：查看、核验、标记状态、写补充说明。
|
||||
- 有跨页面复用潜力：客户端也依赖相同资料状态。
|
||||
- 可独立测试：可覆盖缺件、已收、需补充、已确认等状态。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: document-status-visibility
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 资料状态可视化
|
||||
---
|
||||
|
||||
# 资料状态可视化
|
||||
|
||||
## Page
|
||||
|
||||
- 资料提交与进度页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
向客户实时展示每项资料当前处于待上传、已收到、需补充还是已确认，减少客户对进度的猜测。
|
||||
|
||||
## State Type
|
||||
|
||||
- server
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于会计师资料核验与老板风险查看。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 4 / Step 2`: 查看哪些已经被收到或还不够完整
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：提供清晰状态透明度。
|
||||
- 有独立数据来源：上传记录、AI 初审、人工确认状态。
|
||||
- 有独立交互流：查看状态、展开补充说明。
|
||||
- 有跨页面复用潜力：多个角色都依赖相同状态模型。
|
||||
- 可独立测试：可覆盖四态展示与说明缺失场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: document-upload-submission
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 资料上传提交
|
||||
---
|
||||
|
||||
# 资料上传提交
|
||||
|
||||
## Page
|
||||
|
||||
- 资料提交与进度页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
支持客户按资料项完成上传与替换提交，让资料真正进入案件处理流，而不是只停留在待办列表中。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 4 / Step 1`: 按要求逐步提供资料
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成资料入库。
|
||||
- 有独立交互流：选择资料项、上传文件、查看提交结果。
|
||||
- 有独立状态变化：未提交、上传中、已提交。
|
||||
- 具备独立演化潜力：后续可支持批量上传或重传策略。
|
||||
- 可独立测试：可覆盖成功、失败、替换上传场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: escalation-exception-handling
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 升级异常处理
|
||||
---
|
||||
|
||||
# 升级异常处理
|
||||
|
||||
## Page
|
||||
|
||||
- 升级处理页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
把投诉、差评、反复改约和长期沉默等异常情况聚合到统一工作面，支持老板判断是否需要亲自介入以及如何处理。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可与团队分配和自动化策略联动。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 2 / Step 3`: 接收差评、反复改约或长期沉默的升级信号
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：处理高影响异常事件。
|
||||
- 有独立数据来源：投诉信号、改约记录、沉默天数、负面反馈。
|
||||
- 有独立交互流：查看异常、分派处理、记录结论。
|
||||
- 有跨页面复用潜力：后续可联动自动化与团队分配。
|
||||
- 可独立测试：可覆盖投诉、沉默、重复改约等场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: fee-and-preparation-clarity
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 费用与准备项说明
|
||||
---
|
||||
|
||||
# 费用与准备项说明
|
||||
|
||||
## Page
|
||||
|
||||
- 报价确认页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
把费用、资料准备要求和关键前置条件讲清楚，避免客户在进入服务后才发现成本或准备范围超出预期。
|
||||
|
||||
## State Type
|
||||
|
||||
- server
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于后续补件说明和追加服务报价。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 3 / Step 2`: 理解费用和所需准备内容
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成费用与准备项透明化。
|
||||
- 有独立数据来源：价格明细、资料要求、附加说明。
|
||||
- 有独立交互流：查看总价、理解明细、阅读准备要求。
|
||||
- 有跨页面复用潜力：追加报价与补件说明可复用。
|
||||
- 可独立测试：可覆盖单价、套餐和附加条件场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: high-value-client-alerts
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 高价值客户提醒
|
||||
---
|
||||
|
||||
# 高价值客户提醒
|
||||
|
||||
## Page
|
||||
|
||||
- 升级处理页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
把需要老板优先关注的高价值客户、关键关系客户和高影响风险客户聚合出来，避免重要关系在日常处理中被淹没。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于老板经营总览和移动早报。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 2 / Step 1`: 查看高价值客户和高风险客户提醒
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：识别高价值客户关注事项。
|
||||
- 有独立数据来源：客户价值评级、风险评分、案件紧急度。
|
||||
- 有独立交互流：查看提醒、判断是否介入、进入详情。
|
||||
- 有跨页面复用潜力：多种老板摘要都会消费此能力。
|
||||
- 可独立测试：可覆盖 VIP、普通和误报场景。
|
||||
@@ -0,0 +1,40 @@
|
||||
# Feature Index
|
||||
|
||||
| Feature | Responsibility | Page | Persona Served | State Type | Cross-Page Reuse |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| [会计师负载与分配管理](./accountant-workload-and-assignment.md) | 让老板按会计师维度查看当前客户数、案件数、临期压力、缺件积压和风险事项，并据此调整客户或案件归属，明确下一步由谁跟进。 | 团队推进页 | Firm Owner | both | 是，可复用于老板经营总览中的团队摘要与案件升级分配流程。 |
|
||||
| [自动化效果观察](./automation-effect-observability.md) | 让老板看到自动提醒与自动跟进是否真的在减轻团队负担、提升推进效率，而不是只看规则是否开启。 | 自动化策略页 | Firm Owner | both | 是，可复用于老板经营总览中的自动化摘要。 |
|
||||
| [敏感场景自动化规则](./automation-sensitivity-rules.md) | 支持老板按客户等级、关系敏感度和业务风险调整自动化粒度，避免高价值或敏感场景被一刀切规则伤害。 | 自动化策略页 | Firm Owner | both | 是，可与升级异常处理和客户资产页联动。 |
|
||||
| [收尾确认与签字发起](./case-closeout-and-signoff.md) | 在案件接近完成时发起最终确认、签字和闭环状态更新，确保服务不是停留在“看起来做完了”，而是完成正式收尾。 | 案件工作台 | Accountant | both | 否 |
|
||||
| [案件进度与风险跟踪](./case-progress-and-risk-tracking.md) | 显示案件当前阶段、卡点、截止日和风险信号，帮助会计师决定下一步推进动作，也让老板能在必要时下钻干预，并为团队分配调整提供依据。 | 案件工作台 | Accountant | both | 是，可复用于老板经营总览、团队推进和异常处理视图。 |
|
||||
| [客户历史归档](./client-history-archive.md) | 按客户维度沉淀基础资料、历次服务、文件与签字记录，让团队下次服务时不必从头重问，也让老板能理解长期资产积累。 | 客户档案页 | Accountant | both | 是，可复用于案件工作台客户摘要和老板资产视图。 |
|
||||
| [客户资产分层](./client-portfolio-segmentation.md) | 按客户价值、忠诚度、流失风险和推荐价值对客户资产进行分层，让老板能从经营角度理解长期客户池健康度。 | 客户资产与关系页 | Firm Owner | both | 是，可复用于老板经营总览和高价值客户提醒。 |
|
||||
| [客户基础信息采集](./client-profile-intake.md) | 收集客户身份、联系方式和基础业务信息，为后续建档、报价和资料清单生成提供完整起点。 | 注册与需求填写页 | Client | both | 是，可复用于后续客户档案补录与资料核验。 |
|
||||
| [客户补件提醒](./client-reminder-orchestration.md) | 在资料缺失或临近截止时自动或人工发起提醒，并追踪客户后续是否补交，让催办从个人记忆变成系统动作。 | 案件工作台 | Accountant | both | 是，可延展到老板端异常升级和自动化策略页。 |
|
||||
| [后续合作入口](./client-return-path.md) | 为客户保留后续再次联系、查看历史结果或继续合作的清晰入口，让一次服务自然沉淀为长期关系。 | 服务完成页 | Client | both | 是，可用于召回与长期客户维护场景。 |
|
||||
| [服务完成确认](./client-service-closure.md) | 明确告知客户本次服务已经正式完成，并把关键完成结果与后续联系预期说清楚。 | 服务完成页 | Client | server | 是，可复用于其他服务类型的完成页模板。 |
|
||||
| [今日优先级看板](./daily-priority-board.md) | 按过期、临期、新客待审和进行中案件等维度组织当天工作列表，让会计师能先处理最急、最值当先做的事项。 | 会计师作战台 | Accountant | both | 是，可延展到老板早报或团队总览。 |
|
||||
| [资料清单交付](./document-checklist-delivery.md) | 把当前服务所需资料按清单方式明确交给客户，让客户知道现在需要逐步提交什么，而不是被模糊要求压住。 | 资料提交与进度页 | Client | server | 是，可复用于会计师端资料核验视图。 |
|
||||
| [资料完整性核验](./document-completeness-review.md) | 让会计师逐项判断客户资料是否已收到、是否可用、是否需补充，并把结果沉淀成清晰状态，减少来回沟通。 | 案件工作台 | Accountant | both | 是，可复用于客户端资料页和老板风险查看。 |
|
||||
| [资料状态可视化](./document-status-visibility.md) | 向客户实时展示每项资料当前处于待上传、已收到、需补充还是已确认，减少客户对进度的猜测。 | 资料提交与进度页 | Client | server | 是，可复用于会计师资料核验与老板风险查看。 |
|
||||
| [资料上传提交](./document-upload-submission.md) | 支持客户按资料项完成上传与替换提交，让资料真正进入案件处理流，而不是只停留在待办列表中。 | 资料提交与进度页 | Client | both | 否 |
|
||||
| [升级异常处理](./escalation-exception-handling.md) | 把投诉、差评、反复改约和长期沉默等异常情况聚合到统一工作面，支持老板判断是否需要亲自介入以及如何处理。 | 升级处理页 | Firm Owner | both | 是，可与团队分配和自动化策略联动。 |
|
||||
| [费用与准备项说明](./fee-and-preparation-clarity.md) | 把费用、资料准备要求和关键前置条件讲清楚，避免客户在进入服务后才发现成本或准备范围超出预期。 | 报价确认页 | Client | server | 是，可复用于后续补件说明和追加服务报价。 |
|
||||
| [高价值客户提醒](./high-value-client-alerts.md) | 把需要老板优先关注的高价值客户、关键关系客户和高影响风险客户聚合出来，避免重要关系在日常处理中被淹没。 | 升级处理页 | Firm Owner | both | 是，可复用于老板经营总览和移动早报。 |
|
||||
| [信息用途说明](./information-purpose-guidance.md) | 在客户填写资料前说明为什么需要这些信息、信息将如何被使用，从而降低顾虑并提升配合意愿。 | 注册与需求填写页 | Client | client | 是，可复用于资料提交与签字前说明区域。 |
|
||||
| [新客接纳决策](./intake-acceptance-decision.md) | 支持会计师对新客户做出接纳、退回补充或暂缓处理的明确决定，并记录原因，让建档进入可追踪的状态流转。 | 新客审核台 | Accountant | both | 否 |
|
||||
| [新客资料审阅](./intake-submission-review.md) | 把新客户提交的基础信息、服务需求和 AI 初审结论组织成可快速阅读的审阅面，帮助会计师完成首轮判断而不必在多处来回拼信息。 | 新客审核台 | Accountant | both | 否 |
|
||||
| [邀请码身份确认](./invite-code-verification.md) | 在客户正式进入注册流程前完成邀请码验证与身份确认，确保受邀入口只服务正确对象并减少误入。 | 邀请进入页 | Client | both | 否 |
|
||||
| [邀请信任入口](./invite-trust-entry.md) | 承接客户通过熟人介绍进入系统的第一触点，展示邀请来源与服务身份，让客户确认这是可信、明确且可以继续的入口。 | 邀请进入页 | Client | both | 是，可复用于后续召回或再次邀请场景。 |
|
||||
| [人工接管边界](./manual-override-governance.md) | 在涉及金钱承诺、投诉处理或其他敏感决策时，确保系统停在需要人工判断的位置，并由老板保留最终控制。 | 自动化策略页 | Firm Owner | both | 是，可复用于升级处理与案件干预场景。 |
|
||||
| [老板每日经营简报](./owner-daily-briefing.md) | 在老板进入系统时快速汇总今日经营态势、工作分布和关键变化，让老板几分钟内进入可判断状态。 | 事务所经营总览页 | Firm Owner | both | 是，可延展到早报推送与移动端摘要。 |
|
||||
| [老板优先级预判](./owner-priority-forecast.md) | 基于当日完成情况与风险走势，告诉老板今天收尾和明天开局最需要优先关注的事项。 | 事务所经营总览页 | Firm Owner | both | 是，可复用于老板早报和异常升级排序。 |
|
||||
| [报价回应确认](./quote-decision-response.md) | 记录客户是否接受当前合作条件、是否暂缓或是否需要进一步确认，使报价从展示进入正式决策状态。 | 报价确认页 | Client | both | 否 |
|
||||
| [服务说明展示](./quote-package-presentation.md) | 清晰展示事务所将提供的服务内容、边界和交付预期，让客户先理解“会做什么”，再决定是否继续合作。 | 报价确认页 | Client | server | 是，可复用于历史服务回顾和再次合作场景。 |
|
||||
| [转介绍关系洞察](./referral-relationship-insight.md) | 展示客户由谁介绍、推荐过谁以及关联关系上下文，让事务所能把信任网络当作长期资产来理解与维护。 | 客户档案页 | Accountant | both | 是，天然跨档案页与老板资产页复用。 |
|
||||
| [介绍来源核验](./referral-source-verification.md) | 在正式建档前确认客户由谁介绍、关系链是否清楚、来源信息是否可信，避免后续服务建立在模糊来源之上。 | 新客审核台 | Accountant | both | 是，可复用于老板视角的客户资产与关系检查。 |
|
||||
| [服务需求采集](./service-need-capture.md) | 帮助客户准确说明自己要解决的问题和服务背景，让事务所能基于真实需求推进建档与报价。 | 注册与需求填写页 | Client | both | 是，可复用于后续追加服务或历史需求回顾。 |
|
||||
| [服务范围与报价工作流](./service-scope-and-quote.md) | 帮助会计师在案件中判断客户需求、调整系统报价参考，并把合作条件清楚传达给客户，形成正式报价推进链路。 | 案件工作台 | Accountant | both | 否 |
|
||||
| [签字内容确认](./signoff-content-confirmation.md) | 在客户签署前让其清楚看到需要确认的结果与签字内容，确保最后一步不是盲签而是有明确理解的确认。 | 在线签字页 | Client | server | 否 |
|
||||
| [提交就绪反馈](./submission-readiness-feedback.md) | 在客户提交基础信息与需求后明确告知当前是否可以继续、还缺什么，以及接下来会发生什么，减少提交后的不确定感。 | 注册与需求填写页 | Client | both | 是，可延展到资料提交后的阶段反馈。 |
|
||||
| [补件响应处理](./supplement-request-response.md) | 在客户收到缺件提醒后，把缺什么、为什么缺、下一步怎么补说清楚，并支持客户直接完成补件响应。 | 资料提交与进度页 | Client | both | 是，可与会计师端提醒编排能力共用提醒结果。 |
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: information-purpose-guidance
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 信息用途说明
|
||||
---
|
||||
|
||||
# 信息用途说明
|
||||
|
||||
## Page
|
||||
|
||||
- 注册与需求填写页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在客户填写资料前说明为什么需要这些信息、信息将如何被使用，从而降低顾虑并提升配合意愿。
|
||||
|
||||
## State Type
|
||||
|
||||
- client
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于资料提交与签字前说明区域。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 1 / Step 3`: 理解为什么需要我继续提供信息
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：降低理解成本并建立配合意愿。
|
||||
- 有独立交互流：阅读说明、展开常见问题、继续填写。
|
||||
- 具备独立演化潜力：后续可能随合规或服务类型变化扩展文案。
|
||||
- 有跨页面复用潜力：多个关键提交节点都需要同类说明。
|
||||
- 可独立测试：可覆盖不同服务类型说明与理解阻塞场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: intake-acceptance-decision
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 新客接纳决策
|
||||
---
|
||||
|
||||
# 新客接纳决策
|
||||
|
||||
## Page
|
||||
|
||||
- 新客审核台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
支持会计师对新客户做出接纳、退回补充或暂缓处理的明确决定，并记录原因，让建档进入可追踪的状态流转。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 1 / Step 3`: 决定是否正式接纳进入后续服务
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成正式接纳决策。
|
||||
- 有独立状态流：接纳、退回补充、暂缓处理。
|
||||
- 有独立交互流：选择结果、填写原因、提交决策。
|
||||
- 具备独立演化潜力：后续可能加入审批规则或例外策略。
|
||||
- 可独立测试：可验证不同决策下的状态变化。
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: intake-submission-review
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 新客资料审阅
|
||||
---
|
||||
|
||||
# 新客资料审阅
|
||||
|
||||
## Page
|
||||
|
||||
- 新客审核台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
把新客户提交的基础信息、服务需求和 AI 初审结论组织成可快速阅读的审阅面，帮助会计师完成首轮判断而不必在多处来回拼信息。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 1 / Step 1`: 查看新进入客户提交的信息
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成新客首轮审阅。
|
||||
- 有独立数据来源：客户注册信息、需求信息、AI 初审结果。
|
||||
- 有独立交互流：查看摘要、展开细节、标记已审阅。
|
||||
- 可独立测试：可单独验证信息完整展示与异常提示。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: invite-code-verification
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 邀请码身份确认
|
||||
---
|
||||
|
||||
# 邀请码身份确认
|
||||
|
||||
## Page
|
||||
|
||||
- 邀请进入页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在客户正式进入注册流程前完成邀请码验证与身份确认，确保受邀入口只服务正确对象并减少误入。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 1 / Step 2`: 完成身份确认
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成受邀身份验证。
|
||||
- 有独立数据来源：邀请码、邀请状态、客户匹配信息。
|
||||
- 有独立交互流：输入、校验、通过或驳回。
|
||||
- 具备独立演化潜力：后续可能加入过期规则或二次验证。
|
||||
- 可独立测试：可覆盖正确、错误、过期和已使用场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: invite-trust-entry
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 邀请信任入口
|
||||
---
|
||||
|
||||
# 邀请信任入口
|
||||
|
||||
## Page
|
||||
|
||||
- 邀请进入页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
承接客户通过熟人介绍进入系统的第一触点，展示邀请来源与服务身份，让客户确认这是可信、明确且可以继续的入口。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于后续召回或再次邀请场景。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 1 / Step 1`: 通过邀请进入服务流程
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成可信入口建立。
|
||||
- 有独立数据来源：邀请链接、介绍人信息、事务所身份信息。
|
||||
- 有独立交互流：打开邀请、查看来源、决定继续。
|
||||
- 有跨页面复用潜力：复邀与召回可复用同一信任入口逻辑。
|
||||
- 可独立测试：可覆盖有效邀请、失效邀请和来源缺失场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: manual-override-governance
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 人工接管边界
|
||||
---
|
||||
|
||||
# 人工接管边界
|
||||
|
||||
## Page
|
||||
|
||||
- 自动化策略页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在涉及金钱承诺、投诉处理或其他敏感决策时，确保系统停在需要人工判断的位置，并由老板保留最终控制。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于升级处理与案件干预场景。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 4 / Step 3`: 保留对金钱承诺和投诉处理的最终控制
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：守住高风险人工边界。
|
||||
- 有独立规则来源：金额阈值、投诉类型、敏感客户标签。
|
||||
- 有独立交互流：识别命中条件、暂停自动化、等待人工接管。
|
||||
- 有跨页面复用潜力：异常处理与案件工作台都需遵守。
|
||||
- 可独立测试：可覆盖命中阈值、未命中阈值和人工恢复场景。
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: owner-daily-briefing
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 老板每日经营简报
|
||||
---
|
||||
|
||||
# 老板每日经营简报
|
||||
|
||||
## Page
|
||||
|
||||
- 事务所经营总览页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在老板进入系统时快速汇总今日经营态势、工作分布和关键变化，让老板几分钟内进入可判断状态。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可延展到早报推送与移动端摘要。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 1 / Step 1`: 查看今日工作的总体分布
|
||||
- `事务所老板 / Activity 1 / Step 3`: 了解客户、案件和收入的变化
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成当日经营摘要。
|
||||
- 有独立数据来源：案件分布、客户变化、收入变化。
|
||||
- 有独立交互流：查看摘要、展开模块、进入下钻。
|
||||
- 有跨页面复用潜力：移动端早报可复用同一摘要结构。
|
||||
- 可独立测试：可覆盖正常日、风险日和空数据场景。
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: owner-priority-forecast
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 老板优先级预判
|
||||
---
|
||||
|
||||
# 老板优先级预判
|
||||
|
||||
## Page
|
||||
|
||||
- 事务所经营总览页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
基于当日完成情况与风险走势，告诉老板今天收尾和明天开局最需要优先关注的事项。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于老板早报和异常升级排序。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 5 / Step 1`: 回顾今日新增、推进、完成和风险情况
|
||||
- `事务所老板 / Activity 5 / Step 2`: 识别明天最需要优先关注的事项
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成优先级预判建议。
|
||||
- 有独立数据来源：完成情况、积压事项、临期与风险信号。
|
||||
- 有独立交互流：查看建议、展开原因、进入处理。
|
||||
- 有跨页面复用潜力：多处摘要与预警都可消费。
|
||||
- 可独立测试：可覆盖低风险、高风险和突发积压场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: quote-decision-response
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 报价回应确认
|
||||
---
|
||||
|
||||
# 报价回应确认
|
||||
|
||||
## Page
|
||||
|
||||
- 报价确认页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
记录客户是否接受当前合作条件、是否暂缓或是否需要进一步确认，使报价从展示进入正式决策状态。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 3 / Step 3`: 给出是否继续的回应
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成正式报价回应。
|
||||
- 有独立状态流：接受、暂缓、待确认。
|
||||
- 有独立交互流：选择回应、补充说明、提交结果。
|
||||
- 具备独立演化潜力：后续可加入有效期与二次确认。
|
||||
- 可独立测试：可覆盖接受、拒绝、超时未回场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: quote-package-presentation
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 服务说明展示
|
||||
---
|
||||
|
||||
# 服务说明展示
|
||||
|
||||
## Page
|
||||
|
||||
- 报价确认页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
清晰展示事务所将提供的服务内容、边界和交付预期，让客户先理解“会做什么”，再决定是否继续合作。
|
||||
|
||||
## State Type
|
||||
|
||||
- server
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于历史服务回顾和再次合作场景。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 3 / Step 1`: 查看对方给出的服务说明
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：让客户理解服务范围。
|
||||
- 有独立数据来源：报价单、服务范围说明、交付内容。
|
||||
- 有独立交互流：查看说明、展开细项、对照需求。
|
||||
- 有跨页面复用潜力：历史服务查看可复用同一展示结构。
|
||||
- 可独立测试：可覆盖完整说明、缺失说明和多服务组合场景。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: referral-relationship-insight
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 转介绍关系洞察
|
||||
---
|
||||
|
||||
# 转介绍关系洞察
|
||||
|
||||
## Page
|
||||
|
||||
- 客户档案页
|
||||
- 客户资产与关系页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
- Firm Owner
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
展示客户由谁介绍、推荐过谁以及关联关系上下文，让事务所能把信任网络当作长期资产来理解与维护。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，天然跨档案页与老板资产页复用。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `事务所老板 / Activity 2 / Step 2`: 识别来源不清或关系敏感的客户
|
||||
- `事务所老板 / Activity 5 / Step 3`: 形成可持续维护的经营判断
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：识别并维护介绍关系资产。
|
||||
- 有独立数据来源：邀请记录、关系图谱、客户关联信息。
|
||||
- 有独立交互流：查看来源、展开关系、识别异常。
|
||||
- 有跨页面复用潜力：档案页与资产页都复用。
|
||||
- 可独立测试：可覆盖单一来源、多层介绍和来源异常场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: referral-source-verification
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 介绍来源核验
|
||||
---
|
||||
|
||||
# 介绍来源核验
|
||||
|
||||
## Page
|
||||
|
||||
- 新客审核台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在正式建档前确认客户由谁介绍、关系链是否清楚、来源信息是否可信，避免后续服务建立在模糊来源之上。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于老板视角的客户资产与关系检查。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 1 / Step 2`: 核对客户来源和基本情况
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：保证新客来源可信。
|
||||
- 有独立数据来源：邀请链接、邀请码、介绍关系图谱、客户基本档案。
|
||||
- 有独立交互流：查看来源、比对异常、补充标记来源。
|
||||
- 有跨页面复用潜力：老板端也会关心来源真实性。
|
||||
- 可独立测试：可验证来源缺失、冲突、正常三类结果。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: service-need-capture
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 服务需求采集
|
||||
---
|
||||
|
||||
# 服务需求采集
|
||||
|
||||
## Page
|
||||
|
||||
- 注册与需求填写页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
帮助客户准确说明自己要解决的问题和服务背景，让事务所能基于真实需求推进建档与报价。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可复用于后续追加服务或历史需求回顾。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 2 / Step 2`: 说明自己需要解决的事情
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成可用于判断的需求描述。
|
||||
- 有独立数据来源：服务类型、时间要求、补充说明。
|
||||
- 有独立交互流：选择需求、补充上下文、确认提交。
|
||||
- 有跨页面复用潜力：历史服务与追加需求场景可复用。
|
||||
- 可独立测试：可覆盖单项需求、多项需求和描述不足场景。
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: service-scope-and-quote
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 服务范围与报价工作流
|
||||
---
|
||||
|
||||
# 服务范围与报价工作流
|
||||
|
||||
## Page
|
||||
|
||||
- 案件工作台
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Accountant
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
帮助会计师在案件中判断客户需求、调整系统报价参考，并把合作条件清楚传达给客户，形成正式报价推进链路。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `会计师 / Activity 2 / Step 1`: 评估客户当前需求
|
||||
- `会计师 / Activity 2 / Step 2`: 形成价格判断并做必要调整
|
||||
- `会计师 / Activity 2 / Step 3`: 把合作条件清楚传达给客户
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成服务范围确认与报价发送。
|
||||
- 有独立数据来源：客户需求、历史服务记录、报价参考。
|
||||
- 有独立交互流：评估、修改、确认、发送。
|
||||
- 具备独立演化潜力：后续可能加入更多定价规则。
|
||||
- 可独立测试：可覆盖价格调整、发送前校验、报价状态变化。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: signoff-content-confirmation
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 签字内容确认
|
||||
---
|
||||
|
||||
# 签字内容确认
|
||||
|
||||
## Page
|
||||
|
||||
- 在线签字页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在客户签署前让其清楚看到需要确认的结果与签字内容，确保最后一步不是盲签而是有明确理解的确认。
|
||||
|
||||
## State Type
|
||||
|
||||
- server
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 否
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 5 / Step 1`: 对最终结果做必要确认
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：完成签字前内容确认。
|
||||
- 有独立数据来源：待签文件、结果摘要、确认说明。
|
||||
- 有独立交互流：查看内容、确认理解、进入签署。
|
||||
- 具备独立演化潜力：后续可加入版本差异或补充说明。
|
||||
- 可独立测试：可覆盖单文件、多文件和内容缺失场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: submission-readiness-feedback
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 提交就绪反馈
|
||||
---
|
||||
|
||||
# 提交就绪反馈
|
||||
|
||||
## Page
|
||||
|
||||
- 注册与需求填写页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在客户提交基础信息与需求后明确告知当前是否可以继续、还缺什么，以及接下来会发生什么，减少提交后的不确定感。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可延展到资料提交后的阶段反馈。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 2 / Step 3`: 等待对方确认我已经可以继续往下走
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：形成提交后的清晰反馈。
|
||||
- 有独立状态流：可继续、待补充、待人工确认。
|
||||
- 有独立交互流：提交后查看反馈并决定是否修改。
|
||||
- 有跨页面复用潜力：类似反馈机制可用于资料补件阶段。
|
||||
- 可独立测试：可覆盖通过、待补充、审核中场景。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
artifact_type: feature
|
||||
slug: supplement-request-response
|
||||
round: 4
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 补件响应处理
|
||||
---
|
||||
|
||||
# 补件响应处理
|
||||
|
||||
## Page
|
||||
|
||||
- 资料提交与进度页
|
||||
|
||||
## Persona Served
|
||||
|
||||
- Client
|
||||
|
||||
## Business Responsibility
|
||||
|
||||
在客户收到缺件提醒后，把缺什么、为什么缺、下一步怎么补说清楚，并支持客户直接完成补件响应。
|
||||
|
||||
## State Type
|
||||
|
||||
- both
|
||||
|
||||
## Cross-Page Reuse
|
||||
|
||||
- 是，可与会计师端提醒编排能力共用提醒结果。
|
||||
|
||||
## Source Story
|
||||
|
||||
- `客户 / Activity 4 / Step 3`: 在收到提醒后补齐缺失内容
|
||||
|
||||
## Independence Signals
|
||||
|
||||
- 有独立业务目的：推动提醒后的补件闭环。
|
||||
- 有独立数据来源：提醒事件、缺件原因、资料状态。
|
||||
- 有独立交互流：查看提醒、进入补件、完成再提交。
|
||||
- 有跨页面复用潜力：与会计师提醒能力天然关联。
|
||||
- 可独立测试：可覆盖单项补件、多项补件和重复提醒场景。
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: accountant-workload-and-assignment
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 打开团队推进页，且系统已汇总每位会计师的客户数、案件数、临期压力、缺件积压与风险事项
|
||||
When Firm Owner 查看会计师负载并将一个案件重新分配给更合适的会计师
|
||||
Then 系统应更新案件归属与后续跟进责任，并让团队负载判断保持清晰可追踪
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试进入会计师负载与分配管理区
|
||||
When Accountant 查看团队级负载与分配入口
|
||||
Then 系统应限制其执行团队分配调整，并保持该能力只属于 Firm Owner
|
||||
|
||||
Scenario: Error Case
|
||||
Given Firm Owner 发起案件重新分配，但目标会计师不可用或分配写入失败
|
||||
When Firm Owner 提交新的归属关系
|
||||
Then 系统应明确提示分配失败原因，并保持原有负责人不被静默覆盖
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看团队负载时，发现两位会计师的总体案件数相近，但其中一位存在更高的临期压力与风险积压
|
||||
When Firm Owner 比较团队负载
|
||||
Then 系统应突出显示真实的推进压力差异，而不是仅按案件数量给出误导性结论
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器浏览团队推进页
|
||||
When Firm Owner 顺序查看负载指标、负责人列表与分配动作
|
||||
Then 系统应让负载信息、责任变化与操作结果可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: automation-effect-observability
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 打开自动化策略页，且系统已汇总自动提醒发送记录、客户响应情况与案件推进结果
|
||||
When Firm Owner 查看自动化效果观察区
|
||||
Then 系统应展示自动化是否真正减轻团队负担并提升推进效率，而不是只显示规则开启状态
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试访问自动化效果观察区
|
||||
When Accountant 查看自动化效果指标
|
||||
Then 系统应限制其使用老板级效果评估视图，并保持该能力仅对 Firm Owner 开放
|
||||
|
||||
Scenario: Error Case
|
||||
Given Firm Owner 查看自动化效果时，发现自动化执行日志不完整或统计周期内关键指标缺失
|
||||
When Firm Owner 查看效果观察区
|
||||
Then 系统应明确提示数据不足或统计异常，而不是输出看似准确但不可依赖的效果结论
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 复盘自动化效果时，发现自动提醒发送量增加，但客户响应率和案件推进速度没有改善
|
||||
When Firm Owner 比较当前周期与上一个周期的效果
|
||||
Then 系统应把这种无效自动化识别为需要关注的异常，而不是默认判断为效果提升
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器查看自动化效果指标
|
||||
When Firm Owner 浏览摘要指标、趋势对比与异常提示
|
||||
Then 系统应让关键数据关系、趋势变化与异常结论可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: automation-sensitivity-rules
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 打开自动化策略页，且系统已识别客户等级、关系敏感度与业务风险标签
|
||||
When Firm Owner 将高价值客户的自动化模式从全自动调整为草稿模式
|
||||
Then 系统应保存新的敏感场景自动化规则，并让后续相关流程按该粒度执行
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试修改敏感场景自动化规则
|
||||
When Accountant 提交新的自动化粒度设置
|
||||
Then 系统应拒绝写入规则变更，并保持只有 Firm Owner 可以调整该类策略
|
||||
|
||||
Scenario: Error Case
|
||||
Given Firm Owner 选择的规则范围冲突或保存配置失败
|
||||
When Firm Owner 提交敏感场景自动化规则
|
||||
Then 系统应明确提示失败原因，并保持旧规则继续生效
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看某客户的自动化适用范围时，发现同一客户同时命中 VIP 标签与高风险投诉标签
|
||||
When Firm Owner 查看该客户适用的自动化模式
|
||||
Then 系统应以更保守的敏感规则优先，避免较宽松的自动化设置覆盖高风险边界
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器调整自动化规则
|
||||
When Firm Owner 浏览规则选项、范围说明与生效提示
|
||||
Then 系统应让规则层级、当前模式与保存结果可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: case-closeout-and-signoff
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开一个已接近完成的案件，且交付结果已准备好进入收尾阶段
|
||||
When Accountant 发起最终确认与签字流程
|
||||
Then 系统应把案件推进到待确认或待签字状态，并持续跟踪客户是否完成必要回应
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 直接进入案件工作台内部的收尾控制区
|
||||
When Client 尝试发起或改写案件收尾状态
|
||||
Then 系统应拒绝该内部收尾操作，并保持只有 Accountant 可以发起正式收尾
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 发起收尾时缺少待签文件或关键完成信息
|
||||
When Accountant 提交收尾动作
|
||||
Then 系统应提示缺失前置条件，并阻止案件被误标记为已完成
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Accountant 已发起签字，但客户长时间未回应
|
||||
When Accountant 再次查看案件收尾状态
|
||||
Then 系统应保留待签字状态并清楚标记超时风险，而不是自动把案件视为完成
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器执行收尾操作
|
||||
When Accountant 浏览确认动作、签字状态与异常提示
|
||||
Then 系统应让收尾阶段、当前状态与后续动作可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: case-progress-and-risk-tracking
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开一个正在推进中的案件，且系统已记录案件阶段、截止日、提醒事件与资料状态
|
||||
When Accountant 查看案件进度与风险跟踪区
|
||||
Then 系统应清楚展示当前阶段、卡点位置、截止风险与下一步推进依据
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 尝试访问案件进度与风险跟踪区的内部风险细节
|
||||
When Client 查看案件风险视图
|
||||
Then 系统应限制内部推进与风险判断细节，只向内部角色开放该工作面
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 查看案件进度时，发现案件状态链路记录不完整或截止日数据异常
|
||||
When Accountant 查看进度与风险跟踪区
|
||||
Then 系统应提示状态信息不完整，并避免输出具有误导性的风险结论
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看案件风险跟踪时，发现案件当前没有逾期，但资料缺失与多次提醒未响应已使其接近阻塞
|
||||
When Firm Owner 下钻查看风险跟踪区
|
||||
Then 系统应把这种隐性阻塞识别为需要提前干预的风险，并明确标记为需关注的介入对象
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器查看案件跟踪信息
|
||||
When Accountant 浏览阶段时间线、风险提示与下一步动作
|
||||
Then 系统应让进度结构、风险等级与状态变化可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: client-history-archive
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开一个已有历史服务记录的客户档案
|
||||
When Accountant 查看客户历史归档区并按年份回看服务记录
|
||||
Then 系统应展示基础资料、历次服务、文件与签字记录，支持团队回看长期客户信息
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 尝试访问客户历史归档区中的内部服务沉淀记录
|
||||
When Client 查看档案历史详情
|
||||
Then 系统应限制内部归档视图的访问，并保持该能力仅面向内部角色开放
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 查看客户历史归档时，发现某次历史服务的文件记录或签字归档丢失
|
||||
When Accountant 查看该客户的历史归档
|
||||
Then 系统应明确标记缺失记录，而不是把不完整的历史呈现为已完整归档
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看客户历史归档时，发现客户存在多次服务记录且不同年份的服务类型差异较大
|
||||
When Firm Owner 回看历史归档
|
||||
Then 系统应区分各次服务上下文与长期服务积累，并按年份或服务阶段清楚展示差异
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器浏览客户历史归档
|
||||
When Accountant 查看年份分组、服务记录与文件状态
|
||||
Then 系统应让归档结构、记录顺序与缺失提示可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: client-portfolio-segmentation
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 打开客户资产与关系页，且系统已计算客户价值、忠诚度、流失风险与推荐价值
|
||||
When Firm Owner 切换客户资产分层视图
|
||||
Then 系统应按分层标准展示客户池健康度，并支持识别高价值与高风险人群
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试进入客户资产分层视图
|
||||
When Accountant 查看事务所级客户分层结果
|
||||
Then 系统应限制老板级经营分层能力的访问，并保持该能力只面向 Firm Owner
|
||||
|
||||
Scenario: Error Case
|
||||
Given Firm Owner 查看客户资产分层时，发现某批客户画像指标缺失或分层计算失败
|
||||
When Firm Owner 查看客户资产分层
|
||||
Then 系统应提示分层结果不完整，并避免输出伪精确的客户分类
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看客户资产分层时，发现某客户具有高客单价但同时存在明显流失风险
|
||||
When Firm Owner 查看该客户所在分层
|
||||
Then 系统应同时体现其高价值与风险属性，而不是简单落到单一正向分类
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器浏览客户资产分层
|
||||
When Firm Owner 查看分层标签、筛选结果与风险提示
|
||||
Then 系统应让分层结构、筛选条件与分类含义可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: client-profile-intake
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 通过邀请进入注册与需求填写页
|
||||
When Client 填写姓名、联系方式与基础业务信息并保存
|
||||
Then 系统应校验并保存客户基础信息，为后续建档、报价与资料清单生成提供起点
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试在 Client 自助入口代替 Client 修改基础信息
|
||||
When Accountant 提交客户基础资料
|
||||
Then 系统应限制未授权代填行为，并保持该采集流程以 Client 本人为主
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 提交的必填字段缺失或联系方式格式错误
|
||||
When Client 保存客户基础信息
|
||||
Then 系统应明确指出校验失败的字段，并阻止不完整信息进入后续流程
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 在填写过程中中断离开，且此前已保存部分基础信息
|
||||
When Client 再次进入注册页
|
||||
Then 系统应恢复已保存进度，避免 Client 需要从头重复填写
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器填写基础信息
|
||||
When Client 逐项输入字段并查看校验提示
|
||||
Then 系统应让字段名称、必填状态与错误说明可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: client-reminder-orchestration
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开一个存在缺件或临近截止日的案件
|
||||
When Accountant 在客户补件提醒区发起一次提醒
|
||||
Then 系统应记录提醒事件、把案件推进到等待响应状态，并跟踪客户后续是否补交
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 进入案件内部提醒控制区
|
||||
When Client 尝试主动发起或改写补件提醒规则
|
||||
Then 系统应限制该内部催办能力，并保持提醒编排由 Accountant 控制
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 发起提醒时缺少有效联系渠道或提醒发送失败
|
||||
When Accountant 提交提醒动作
|
||||
Then 系统应提示发送失败原因，并避免把提醒误记为已成功触达
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Accountant 查看提醒编排区时，发现同一客户在短时间内已收到多次提醒且仍未响应
|
||||
When Accountant 再次查看提醒编排区
|
||||
Then 系统应显示频率风险或历史触达记录，帮助 Accountant 避免无差别重复催办
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器发起补件提醒
|
||||
When Accountant 浏览提醒类型、历史记录与发送结果
|
||||
Then 系统应让提醒结构、状态变化与失败原因可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: client-return-path
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 已到达服务完成页，且本次服务已正式闭环
|
||||
When Client 选择查看历史结果或再次联系事务所
|
||||
Then 系统应提供清晰的后续合作入口，并展示查看历史结果或再次联系事务所的可用路径
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 尝试通过该后续合作入口查看其他 Client 的历史内容
|
||||
When Client 进入不属于自己的返回合作路径
|
||||
Then 系统应限制其访问他人历史结果，并保持入口只服务当前 Client 的后续动作
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 点击后续合作入口，但历史结果地址失效或联系通道不可用
|
||||
When Client 继续该动作
|
||||
Then 系统应明确提示入口异常，并提供可理解的替代指引而不是静默失败
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 当前没有更多历史结果可查看，但仍希望再次合作
|
||||
When Client 打开后续合作入口
|
||||
Then 系统应仍然保留重新联系或继续合作的路径，而不是因为历史为空就让流程中断
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器访问后续合作入口
|
||||
When Client 浏览历史查看、再次联系与继续合作选项
|
||||
Then 系统应让入口目的、目标动作与结果说明可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: client-service-closure
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 完成签字或最终回应，且案件已进入正式完成状态
|
||||
When Client 打开服务完成页
|
||||
Then 系统应明确告知本次服务已完成，并展示关键完成结果与后续预期
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试直接访问当前 Client 的服务完成页
|
||||
When Accountant 查看服务完成确认内容
|
||||
Then 系统应限制其访问正式完成结果，并保持完成确认只面向对应 Client
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 打开服务完成页时，案件实际尚未完成或完成状态回退
|
||||
When Client 打开服务完成页
|
||||
Then 系统应避免展示误导性的完成信号，并清楚提示当前仍存在待处理事项
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 查看服务完成确认时，案件主体已完成，但部分归档信息仍在同步中
|
||||
When Client 查看服务完成确认
|
||||
Then 系统应优先明确服务已闭环，同时把仍在整理的附加信息标记为后续可补充查看
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器查看服务完成页
|
||||
When Client 浏览完成状态、结果摘要与后续说明
|
||||
Then 系统应让完成信号、结果内容与后续动作可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: daily-priority-board
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开会计师作战台，且系统已聚合过期、临期、新客待审与进行中案件
|
||||
When Accountant 查看今日优先级看板
|
||||
Then 系统应按优先级组织工作列表，并突出最急和最关键的事项
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 尝试访问会计师作战台中的今日优先级看板
|
||||
When Client 查看该工作列表
|
||||
Then 系统应限制内部工作优先级视图的访问，并保持看板只对 Accountant 开放
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 查看今日优先级看板时，发现案件状态或截止日数据缺失导致排序依据不完整
|
||||
When Accountant 查看今日优先级看板
|
||||
Then 系统应提示数据异常并避免输出误导性的优先级排序
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Accountant 查看今日优先级顺序时，发现两个案件的截止日相同，但其中一个存在严重缺件或高风险阻塞
|
||||
When Accountant 查看今日优先级顺序
|
||||
Then 系统应把更高风险的案件放在更靠前的位置，而不是只按截止日做机械排序
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器浏览今日优先级看板
|
||||
When Accountant 顺序查看分组、案件摘要与风险标签
|
||||
Then 系统应让优先级结构、状态说明与导航目标可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: document-checklist-delivery
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 已进入资料提交与进度页，且系统已根据服务类型生成所需资料清单
|
||||
When Client 查看资料清单交付区
|
||||
Then 系统应按清单方式明确展示当前需要提交的资料项与提交顺序
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看 Client 自助提交流程中的资料清单
|
||||
When Accountant 进入资料清单交付区
|
||||
Then 系统应限制其访问当前服务清单，并保持清单只服务对应 Client
|
||||
|
||||
Scenario: Error Case
|
||||
Given 服务类型已确定，但资料规则加载失败或清单未正确生成
|
||||
When Client 打开资料清单交付区
|
||||
Then 系统应提示清单生成异常，并避免把空白页面伪装成无需提交资料
|
||||
|
||||
Scenario: Edge Case
|
||||
Given 某服务同时包含通用资料项与特定补充资料项
|
||||
When Client 查看资料清单
|
||||
Then 系统应把不同类型的资料要求区分清楚，避免 Client 误以为只需提交一部分
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器浏览资料清单
|
||||
When Client 顺序查看资料项、说明与提交入口
|
||||
Then 系统应让清单结构、资料名称与提交关系可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: document-completeness-review
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开一个已有上传资料的案件
|
||||
When Accountant 在资料完整性核验区逐项判断资料是否已收到、可用或需补充
|
||||
Then 系统应保存每项核验结果，并把资料状态沉淀为可追踪的判断结论
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 进入会计师端资料完整性核验区
|
||||
When Client 尝试直接修改内部核验结论
|
||||
Then 系统应限制该内部核验能力，并保持只有 Accountant 可以确认资料是否可用
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 需要核验某项资料，但上传文件损坏或 AI 初审结果无法读取
|
||||
When Accountant 查看该资料项
|
||||
Then 系统应提示核验依据异常，并避免把无法判断的资料直接标记为通过
|
||||
|
||||
Scenario: Edge Case
|
||||
Given 某项资料已上传，但内容与客户身份信息不匹配
|
||||
When Accountant 执行资料完整性核验
|
||||
Then 系统应允许将该资料标记为需补充或异常，而不是只根据是否上传做通过判断
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器执行资料核验
|
||||
When Accountant 浏览资料项、状态选项与补充说明
|
||||
Then 系统应让资料名称、当前状态与核验结果可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: document-status-visibility
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 已提交部分资料并进入资料提交与进度页
|
||||
When Client 查看资料状态可视化区
|
||||
Then 系统应实时展示每项资料当前处于待上传、已收到、需补充或已确认的状态
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看 Client 自助提交流程中的资料状态
|
||||
When Accountant 进入资料状态可视化区
|
||||
Then 系统应限制其访问当前 Client 的资料处理状态
|
||||
|
||||
Scenario: Error Case
|
||||
Given 某项资料的审核状态尚未成功同步
|
||||
When Client 查看资料状态
|
||||
Then 系统应提示状态暂不可用或仍在处理中，而不是展示错误的最终结论
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 在短时间内多次替换同一资料项
|
||||
When Client 查看该资料项的当前状态
|
||||
Then 系统应只突出当前有效版本的处理状态，避免历史替换记录干扰当下判断
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器浏览资料状态
|
||||
When Client 顺序查看每项资料的状态与补充说明
|
||||
Then 系统应让状态名称、变化含义与说明内容可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: document-upload-submission
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 已进入资料提交与进度页并看到待提交的资料项
|
||||
When Client 选择某个资料项上传文件并完成提交
|
||||
Then 系统应记录该资料项的新文件，并把提交结果反馈给 Client
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试在 Client 自助提交流程中上传案件资料
|
||||
When Accountant 进入资料上传提交流程
|
||||
Then 系统应限制其提交行为，并保持上传入口只服务对应 Client
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 上传的文件类型不支持或上传过程失败
|
||||
When Client 提交资料文件
|
||||
Then 系统应明确提示失败原因，并保持该资料项不被误记为已提交
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 需要替换之前已提交的一份资料
|
||||
When Client 对同一资料项再次上传新文件
|
||||
Then 系统应把新文件视为当前有效版本，同时保留可追踪的替换结果
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器完成文件上传
|
||||
When Client 浏览资料项、选择上传入口并查看提交反馈
|
||||
Then 系统应让上传目标、当前进度与结果说明可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: escalation-exception-handling
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 打开升级处理页，且系统已聚合投诉、差评、反复改约与长期沉默等异常信号
|
||||
When Firm Owner 查看异常列表并决定由谁跟进处理
|
||||
Then 系统应记录异常处理动作与结论，并保持高影响例外情况集中可追踪
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试在升级处理页执行老板级异常决策
|
||||
When Accountant 提交异常处理结论
|
||||
Then 系统应限制其老板级处置权限，并保持异常处理由 Firm Owner 主导
|
||||
|
||||
Scenario: Error Case
|
||||
Given 某条异常事件缺少核心上下文或处理写入失败
|
||||
When Firm Owner 提交处理动作
|
||||
Then 系统应提示异常记录不完整或处理失败，并避免把事件误记为已闭环
|
||||
|
||||
Scenario: Edge Case
|
||||
Given 同一客户同时出现投诉与长期沉默两类升级信号
|
||||
When Firm Owner 查看异常处理队列
|
||||
Then 系统应把这些信号归并为同一客户上下文中的复合风险，而不是分散成彼此孤立的事项
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器处理异常事件
|
||||
When Firm Owner 浏览异常类型、处理责任与结论记录
|
||||
Then 系统应让异常上下文、风险等级与处理结果可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: fee-and-preparation-clarity
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 进入报价确认页，且系统已生成费用明细与资料准备要求
|
||||
When Client 查看费用与准备项说明区
|
||||
Then 系统应清楚展示价格、准备要求与关键前置条件，并让当前报价范围可以被直接确认
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看当前 Client 的报价费用说明
|
||||
When Accountant 进入费用与准备项说明区
|
||||
Then 系统应限制其访问当前 Client 的报价内容
|
||||
|
||||
Scenario: Error Case
|
||||
Given 报价费用明细不完整或准备项规则加载失败
|
||||
When Client 查看费用与准备项说明
|
||||
Then 系统应明确提示说明信息不完整，并避免把模糊费用展示为可直接确认的报价
|
||||
|
||||
Scenario: Edge Case
|
||||
Given 某报价同时包含基础服务与额外补充要求
|
||||
When Client 查看费用与准备项说明
|
||||
Then 系统应把基础费用与附加条件区分清楚，避免 Client 误解总成本或准备范围
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器查看费用说明
|
||||
When Client 浏览价格明细、准备要求与附加条件
|
||||
Then 系统应让金额信息、资料要求与说明层级可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: high-value-client-alerts
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 打开升级处理页，且系统已识别高价值客户、关键关系客户与高影响风险客户
|
||||
When Firm Owner 查看高价值客户提醒区
|
||||
Then 系统应聚合最需要优先关注的客户提醒，并支持 Firm Owner 快速进入详情判断是否介入
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试访问高价值客户提醒区
|
||||
When Accountant 查看老板级高价值提醒列表
|
||||
Then 系统应限制其老板级提醒视图的访问，并保持该能力仅面向 Firm Owner
|
||||
|
||||
Scenario: Error Case
|
||||
Given 客户价值评级或风险评分未成功更新
|
||||
When Firm Owner 查看高价值客户提醒
|
||||
Then 系统应提示提醒依据不完整，并避免把重要客户从提醒列表中静默遗漏
|
||||
|
||||
Scenario: Edge Case
|
||||
Given 某客户价值很高，但当前风险较低；另一客户价值较低但风险极高
|
||||
When Firm Owner 查看提醒排序
|
||||
Then 系统应帮助区分“重要关系关注”和“高风险介入”两类优先级，而不是简单混成单一排序
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器浏览高价值客户提醒
|
||||
When Firm Owner 查看客户名称、提醒原因与风险等级
|
||||
Then 系统应让提醒结构、优先级含义与详情入口可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: information-purpose-guidance
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 刚进入注册与需求填写页，尚未开始正式填写资料
|
||||
When Client 查看信息用途说明区
|
||||
Then 系统应说明为什么需要这些信息以及信息将如何被使用，并提供与当前填写流程一致的解释上下文
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看 Client 受邀流程中的信息用途说明上下文
|
||||
When Accountant 进入说明区域
|
||||
Then 系统应限制其使用当前邀请上下文的说明入口，并保持说明服务于对应 Client 的受邀流程
|
||||
|
||||
Scenario: Error Case
|
||||
Given 某服务类型需要特殊说明，但当前说明内容未成功加载
|
||||
When Client 查看信息用途说明
|
||||
Then 系统应提示说明暂不可用，而不是让 Client 在无解释状态下继续填写敏感资料
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 对某些敏感字段存在明显顾虑
|
||||
When Client 展开信息用途说明中的常见问题或补充解释
|
||||
Then 系统应提供更具体的用途说明，帮助 Client 判断为何仍需要继续填写
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器阅读信息用途说明
|
||||
When Client 浏览说明文本、补充解释与继续填写入口
|
||||
Then 系统应让说明结构、重点信息与后续动作可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: intake-acceptance-decision
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 已完成对新客户资料与来源的初步判断
|
||||
When Accountant 在新客接纳决策区选择接纳并提交原因
|
||||
Then 系统应记录该正式决策并推动客户进入后续服务流程
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 进入新客审核台内部的接纳决策区
|
||||
When Client 尝试替自己提交接纳结果
|
||||
Then 系统应限制该内部审核能力，并保持接纳决策只由 Accountant 执行
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 提交接纳决策时缺少必要原因或写入失败
|
||||
When Accountant 确认该决策
|
||||
Then 系统应提示决策未成功记录，并避免客户状态被误更新
|
||||
|
||||
Scenario: Edge Case
|
||||
Given 新客户信息基本可用，但来源仍存在待确认疑点
|
||||
When Accountant 评估接纳结果
|
||||
Then 系统应允许选择暂缓处理或退回补充，而不是只提供接纳与拒绝的二元结果
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器执行新客接纳决策
|
||||
When Accountant 浏览决策选项、原因输入与提交结果
|
||||
Then 系统应让状态选项、原因说明与结果反馈可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: intake-submission-review
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开一个刚通过邀请完成注册的新客户记录，且客户已提交基础信息、服务需求与 AI 初审结果
|
||||
When Accountant 查看新客资料审阅区并展开关键信息摘要
|
||||
Then 系统应按统一结构展示基础信息、需求信息与 AI 初审结论，并标明可供首轮审阅使用的关键信息摘要
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 进入新客审核台对应的新客资料审阅入口
|
||||
When Client 尝试查看新客资料审阅内容
|
||||
Then 系统应拒绝展示该审阅面，并保持只有 Accountant 可以执行首轮审阅
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 打开一个新客户记录，但客户提交信息缺失或 AI 初审结果未成功生成
|
||||
When Accountant 进入新客资料审阅区
|
||||
Then 系统应明确提示缺失项或异常状态，而不是把不完整信息伪装成可直接审阅的结果
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Accountant 打开一个信息量较大或包含多项补充说明的新客户记录
|
||||
When Accountant 在审阅区查看摘要并展开细节
|
||||
Then 系统应先提供可快速扫读的核心摘要，同时允许继续展开完整内容，而不打断首轮判断节奏
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器进入新客资料审阅区
|
||||
When Accountant 逐段浏览摘要、状态提示与展开内容
|
||||
Then 系统应让审阅结构、标题层级、状态说明与展开关系可被顺序访问和清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: invite-code-verification
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 通过邀请链接进入邀请进入页，且持有有效的邀请码
|
||||
When Client 输入邀请码并提交验证
|
||||
Then 系统应完成身份确认并允许 Client 进入后续注册流程
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Firm Owner 尝试代替受邀 Client 进入邀请码验证后的注册流程
|
||||
When Firm Owner 提交验证请求
|
||||
Then 系统应拒绝其进入后续注册步骤，并保持受邀入口只服务正确对象
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 输入的邀请码错误、已过期或验证服务异常
|
||||
When Client 提交邀请码
|
||||
Then 系统应明确提示验证失败原因，而不是让 Client 落入不明状态
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 打开的邀请链接有效，但输入的邀请码已被其他流程标记为已使用
|
||||
When Client 尝试完成身份确认
|
||||
Then 系统应把该状态解释清楚，并指导 Client 联系事务所或重新获取邀请
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器输入邀请码
|
||||
When Client 浏览输入框、校验提示与继续按钮
|
||||
Then 系统应让字段名称、错误信息与验证结果可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: invite-trust-entry
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 通过熟人介绍收到事务所邀请链接
|
||||
When Client 打开邀请进入页
|
||||
Then 系统应展示邀请来源、介绍人上下文与事务所身份信息，并明确当前入口与受邀流程的对应关系
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 尝试通过不属于自己的受邀入口进入正式邀请流程
|
||||
When Client 打开邀请进入页
|
||||
Then 系统应限制其进入正式受邀流程，并避免暴露不必要的内部关系上下文
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 打开邀请进入页时，发现邀请来源信息缺失或事务所身份信息加载失败
|
||||
When Client 打开邀请进入页
|
||||
Then 系统应提示入口信息不完整，而不是把缺失上下文伪装成正常邀请
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 来自熟人转介绍，但对事务所仍有初始顾虑
|
||||
When Client 查看邀请信任入口中的来源说明
|
||||
Then 系统应优先突出介绍关系与服务身份，并明确展示与继续进入相关的信任说明
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器查看邀请进入页
|
||||
When Client 浏览介绍来源、事务所身份与继续入口
|
||||
Then 系统应让信任信息结构、来源说明与后续动作可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: manual-override-governance
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 已配置自动化策略，且某个流程命中金额承诺或投诉处理等高风险条件
|
||||
When 系统执行到人工接管边界
|
||||
Then 系统应暂停自动化继续推进，并把最终处理权交给 Firm Owner
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试绕过人工接管边界直接放行高风险自动化动作
|
||||
When Accountant 提交该放行动作
|
||||
Then 系统应限制其越权放行，并保持最终控制属于 Firm Owner
|
||||
|
||||
Scenario: Error Case
|
||||
Given Firm Owner 处理人工接管事项时，系统命中人工接管条件，但暂停或通知写入失败
|
||||
When 自动化执行到边界点
|
||||
Then 系统应明确标记该异常，而不是在未确认的情况下继续自动处理高风险动作
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看人工接管命中原因时，发现一个场景同时命中多个风险阈值，例如金额承诺与投诉标签
|
||||
When 系统判断是否需要人工接管
|
||||
Then 系统应把该场景视为必须人工接管，而不是让较弱规则覆盖更高风险边界
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器处理人工接管事项
|
||||
When Firm Owner 浏览命中原因、待处理动作与控制结果
|
||||
Then 系统应让接管条件、风险说明与最终控制状态可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: owner-daily-briefing
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 进入事务所经营总览页，且系统已汇总今日案件分布、客户变化与收入变化
|
||||
When Firm Owner 查看老板每日经营简报
|
||||
Then 系统应快速呈现今日经营态势与关键变化，并突出需要立即关注的经营信号
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看老板每日经营简报
|
||||
When Accountant 进入该经营摘要区域
|
||||
Then 系统应限制其访问事务所级经营总览，并保持该能力仅对 Firm Owner 开放
|
||||
|
||||
Scenario: Error Case
|
||||
Given Firm Owner 查看每日经营简报时，发现某些经营汇总数据未成功同步
|
||||
When Firm Owner 查看每日经营简报
|
||||
Then 系统应提示摘要数据不完整，并避免把残缺信息伪装成完整经营概况
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看每日经营简报时，发现当天新增客户不多，但逾期案件与高风险事项明显上升
|
||||
When Firm Owner 查看经营简报
|
||||
Then 系统应突出经营压力变化，而不是仅让新增数量掩盖真实风险
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器查看经营简报
|
||||
When Firm Owner 浏览摘要模块、变化指标与下钻入口
|
||||
Then 系统应让模块结构、关键变化与优先信息可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: owner-priority-forecast
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 查看事务所经营总览页，且系统已汇总当日完成情况、积压事项与风险走势
|
||||
When Firm Owner 打开老板优先级预判区
|
||||
Then 系统应指出今天收尾和明天开局最需要优先关注的事项
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看老板优先级预判
|
||||
When Accountant 进入该预判区域
|
||||
Then 系统应限制其使用老板级优先级预判能力
|
||||
|
||||
Scenario: Error Case
|
||||
Given Firm Owner 查看优先级预判时，发现完成情况或风险趋势数据缺失，导致预判依据不足
|
||||
When Firm Owner 查看优先级预判
|
||||
Then 系统应提示预判依据不完整，而不是输出看似确定但不可依赖的建议
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Firm Owner 查看优先级预判时，发现当前没有明显逾期，但明天存在多个即将同时到期的关键事项
|
||||
When Firm Owner 查看优先级预判
|
||||
Then 系统应把明日的集中压力提前暴露出来，而不是只强调当前已发生的问题
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Firm Owner 依赖键盘导航或屏幕阅读器查看优先级预判
|
||||
When Firm Owner 浏览建议项、原因说明与处理入口
|
||||
Then 系统应让建议顺序、判断依据与下一步动作可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: quote-decision-response
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 已查看报价确认页中的服务说明与费用要求
|
||||
When Client 选择接受当前合作条件并提交回应
|
||||
Then 系统应记录该正式报价回应，并推动流程进入后续服务阶段
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试代替当前 Client 提交报价回应
|
||||
When Accountant 在报价确认页提交决定
|
||||
Then 系统应限制其代替回应行为，并保持该决策由对应 Client 完成
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 提交报价回应时写入失败或报价已失效
|
||||
When Client 确认当前决定
|
||||
Then 系统应提示回应未成功记录，并避免流程误进入下一阶段
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 暂时无法决定是否继续合作
|
||||
When Client 提交暂缓或待确认回应
|
||||
Then 系统应把该结果记录为可追踪的中间状态，而不是强制收敛为接受或拒绝
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器提交报价回应
|
||||
When Client 浏览决策选项、说明文本与提交结果
|
||||
Then 系统应让选项含义、当前状态与确认反馈可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: quote-package-presentation
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 打开报价确认页，且事务所已生成当前服务内容与交付预期
|
||||
When Client 查看服务说明展示区
|
||||
Then 系统应清楚展示将提供的服务内容、边界与交付结果，并使当前方案范围可以被直接查看
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看当前 Client 的服务说明展示区
|
||||
When Accountant 进入服务说明展示区
|
||||
Then 系统应限制其查看当前 Client 的报价内容
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 查看服务说明展示区时，发现服务范围说明未成功生成或关键信息缺失
|
||||
When Client 查看服务说明展示区
|
||||
Then 系统应提示说明不完整，而不是把不明确的服务边界展示为可确认方案
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 查看服务说明展示时，发现某报价包含多个服务组合与不同交付内容
|
||||
When Client 查看服务说明展示
|
||||
Then 系统应把不同服务项与交付预期区分清楚，避免 Client 误解服务边界
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器浏览服务说明
|
||||
When Client 查看服务内容、边界说明与交付预期
|
||||
Then 系统应让说明层级、关键条目与比较关系可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: referral-relationship-insight
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Firm Owner 打开客户资产与关系页，且系统已建立客户介绍关系图谱
|
||||
When Firm Owner 查看转介绍关系洞察区
|
||||
Then 系统应展示客户由谁介绍、推荐过谁以及关联关系上下文，并清楚呈现关系层级与来源链路
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 尝试查看内部转介绍关系洞察
|
||||
When Client 进入关系图谱相关区域
|
||||
Then 系统应限制其访问内部关系网络细节，并保持该洞察面只服务内部角色
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 查看转介绍关系洞察时，发现邀请记录缺失或关系链计算失败
|
||||
When Accountant 查看转介绍关系洞察
|
||||
Then 系统应明确提示关系数据不完整，而不是把来源空缺呈现为正常无关系状态
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Accountant 查看关系洞察时，发现某客户同时存在多层介绍关系与关联账户
|
||||
When Accountant 查看关系洞察
|
||||
Then 系统应区分主要介绍链与其他关联关系，避免把不同关系语义混成一张模糊网络
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器查看关系洞察
|
||||
When Accountant 浏览来源信息、关联说明与异常提示
|
||||
Then 系统应让关系层级、来源变化与风险信号可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: referral-source-verification
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开一个新客户记录，且系统已关联邀请链接、邀请码与介绍人信息
|
||||
When Accountant 进入介绍来源核验区查看来源与关系上下文
|
||||
Then 系统应清楚展示客户由谁介绍、关系链是否完整，以及当前来源是否可被视为可信
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 尝试访问介绍来源核验区
|
||||
When Client 查看新客户的来源核验内容
|
||||
Then 系统应拒绝暴露内部来源判断与关系核验结果，并保持只有 Accountant 可以执行该核验
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 打开一个新客户记录，但邀请记录缺失、邀请码失配或介绍人信息未成功关联
|
||||
When Accountant 查看介绍来源核验区
|
||||
Then 系统应明确提示来源缺失或核验失败的原因，而不是把该客户误判为来源正常
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Accountant 打开一个存在多重介绍关系或来源信息相互冲突的新客户记录
|
||||
When Accountant 在核验区比对邀请来源、历史关系与客户档案线索
|
||||
Then 系统应突出显示冲突点，并帮助 Accountant 判断该客户需要补充标记还是暂缓建档
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器进入介绍来源核验区
|
||||
When Accountant 浏览介绍人信息、关系说明与冲突提示
|
||||
Then 系统应让来源结构、风险提示和核验结论可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: service-need-capture
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 进入注册与需求填写页，且已准备说明自己要解决的问题
|
||||
When Client 选择服务类型并补充服务背景
|
||||
Then 系统应保存该需求描述，为后续建档与报价提供可判断的依据
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试替当前 Client 修改服务需求
|
||||
When Accountant 提交需求信息
|
||||
Then 系统应限制其代填行为，并保持需求采集以对应 Client 的输入为准
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 未填写关键需求信息或提交内容无法通过校验
|
||||
When Client 提交服务需求
|
||||
Then 系统应明确提示缺失或不合规的部分，并阻止不完整需求进入后续流程
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 同时存在多项服务诉求且时间要求不同
|
||||
When Client 提交服务需求
|
||||
Then 系统应允许保留多项需求与补充背景，而不是把复杂诉求压缩成单一模糊问题
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器填写服务需求
|
||||
When Client 浏览选项、补充说明输入区与校验提示
|
||||
Then 系统应让需求字段、必填说明与错误反馈可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: service-scope-and-quote
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Accountant 打开案件工作台，且已掌握客户需求与历史背景
|
||||
When Accountant 评估需求、调整报价参考并发送合作条件
|
||||
Then 系统应记录正式的服务范围与报价结果，并推动案件进入报价确认链路
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Client 进入案件工作台内部的服务范围与报价工作区
|
||||
When Client 尝试修改内部报价判断或直接发送报价
|
||||
Then 系统应限制其内部定价与发送能力，并保持该工作流由 Accountant 控制
|
||||
|
||||
Scenario: Error Case
|
||||
Given Accountant 发出报价前缺少必要的需求依据或发送动作失败
|
||||
When Accountant 提交服务范围与报价
|
||||
Then 系统应提示当前报价未成功形成或发送，并避免客户看到不可靠的合作条件
|
||||
|
||||
Scenario: Edge Case
|
||||
Given 客户需求超出标准报价范围，需要在系统参考基础上做人工调整
|
||||
When Accountant 确认服务范围与报价
|
||||
Then 系统应允许保留人工判断结果，并让最终报价区别于默认参考值
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Accountant 依赖键盘导航或屏幕阅读器完成服务范围与报价工作流
|
||||
When Accountant 浏览需求摘要、价格调整与发送确认
|
||||
Then 系统应让范围说明、价格变化与提交结果可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: signoff-content-confirmation
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 打开在线签字页，且系统已准备好待签文件与结果摘要
|
||||
When Client 查看签字内容确认区
|
||||
Then 系统应清楚展示需要确认的结果与签字内容，再引导 Client 进入正式签署
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看当前 Client 的签字内容确认区
|
||||
When Accountant 进入签字内容确认区
|
||||
Then 系统应限制其访问当前 Client 的待签内容
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 查看签字内容确认时，发现待签文件缺失、版本错误或结果摘要未成功加载
|
||||
When Client 查看签字内容确认
|
||||
Then 系统应提示签字内容异常，并阻止 Client 在信息不完整时继续签署
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 查看签字内容确认区时，发现当前签字任务包含多个待确认文件
|
||||
When Client 查看签字内容确认区
|
||||
Then 系统应帮助 Client 区分每份文件与其对应的确认范围，而不是把多份内容混成一次模糊确认
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器查看签字内容确认
|
||||
When Client 浏览结果摘要、文件说明与继续签署入口
|
||||
Then 系统应让签字结构、文件关系与确认动作可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: submission-readiness-feedback
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 已完成基础信息与服务需求的填写
|
||||
When Client 提交注册内容并查看提交就绪反馈
|
||||
Then 系统应明确告知当前是否可以继续，以及接下来会发生什么
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试查看 Client 自助提交流程中的提交就绪反馈
|
||||
When Accountant 进入反馈区域
|
||||
Then 系统应限制其访问当前提交结果
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 提交后系统未能完成完整性判断
|
||||
When Client 查看提交就绪反馈
|
||||
Then 系统应提示当前判断未完成或存在异常，而不是输出错误的继续信号
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 已提交大部分信息，但仍有少量关键字段不足
|
||||
When Client 查看提交就绪反馈
|
||||
Then 系统应明确指出仍需补充的部分，而不是简单给出模糊的未通过结论
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器查看提交反馈
|
||||
When Client 浏览当前状态、缺失项与下一步说明
|
||||
Then 系统应让反馈结果、补充要求与继续路径可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
Feature: supplement-request-response
|
||||
|
||||
Scenario: Happy Path
|
||||
Given Client 收到缺件提醒并进入资料提交与进度页
|
||||
When Client 查看补件响应处理区并按提示补交缺失资料
|
||||
Then 系统应明确说明缺什么、为什么缺，以及补交完成后的最新状态
|
||||
|
||||
Scenario: Permission Case
|
||||
Given Accountant 尝试响应当前 Client 的补件提醒
|
||||
When Accountant 进入补件响应处理区
|
||||
Then 系统应限制其访问与补件操作，并保持响应链路只服务对应 Client
|
||||
|
||||
Scenario: Error Case
|
||||
Given Client 打开补件响应处理区时缺件原因未成功加载或再提交失败
|
||||
When Client 尝试完成补件
|
||||
Then 系统应提示补件异常，并避免把未成功的再提交误标为已完成
|
||||
|
||||
Scenario: Edge Case
|
||||
Given Client 同时收到多项补件要求，且不同资料项的补充原因不同
|
||||
When Client 查看补件响应处理区
|
||||
Then 系统应把每项缺件原因与对应补交动作区分清楚，避免 Client 误补或漏补
|
||||
|
||||
Scenario: Accessibility Case
|
||||
Given Client 依赖键盘导航或屏幕阅读器完成补件响应
|
||||
When Client 浏览缺件原因、补交入口与再提交结果
|
||||
Then 系统应让补件结构、原因说明与状态反馈可以被顺序访问并清晰朗读
|
||||
@@ -0,0 +1,26 @@
|
||||
# Analysis Index
|
||||
|
||||
## Brief
|
||||
|
||||
- [Project Brief](./brief.md)
|
||||
|
||||
## Personas
|
||||
|
||||
- [Persona Index](./personas/index.md)
|
||||
|
||||
## Story Maps
|
||||
|
||||
- [Story Map Index](./story-maps/index.md)
|
||||
|
||||
## Pages
|
||||
|
||||
- [Page Index](./pages/index.md)
|
||||
|
||||
## Features
|
||||
|
||||
- [Feature Index](./features/index.md)
|
||||
|
||||
## Relations
|
||||
|
||||
- [Persona Story Page Matrix](./relations/persona-story-page-matrix.md)
|
||||
- [Feature Coverage Matrix](./relations/feature-coverage-matrix.md)
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: accountant-dashboard
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 会计师作战台
|
||||
---
|
||||
|
||||
# 会计师作战台
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/workspace/today`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Accountant
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `会计师 / Activity 4 / Step 1`: 根据优先级安排当天要处理的工作
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
聚合今日待办、过期事项、临期案件和新客提示，帮助会计师快速决定先做什么、后做什么。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 今日优先级看板
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: accountant-intake
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 新客审核台
|
||||
---
|
||||
|
||||
# 新客审核台
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/workspace/intake`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Accountant
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `会计师 / Activity 1 / Step 1`: 查看新进入客户提交的信息
|
||||
- `会计师 / Activity 1 / Step 2`: 核对客户来源和基本情况
|
||||
- `会计师 / Activity 1 / Step 3`: 决定是否正式接纳进入后续服务
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
集中处理新客户资料、介绍来源、AI 初审结果和接纳决策，把“是否正式建档”从零散沟通变成可追踪的审核动作。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 新客资料审阅
|
||||
- 介绍来源核验
|
||||
- 新客接纳决策
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: case-workspace
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 案件工作台
|
||||
---
|
||||
|
||||
# 案件工作台
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/workspace/cases/:caseId`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Accountant
|
||||
- Firm Owner
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `会计师 / Activity 2 / Step 1`: 评估客户当前需求
|
||||
- `会计师 / Activity 2 / Step 2`: 形成价格判断并做必要调整
|
||||
- `会计师 / Activity 2 / Step 3`: 把合作条件清楚传达给客户
|
||||
- `会计师 / Activity 3 / Step 1`: 查看还缺哪些资料
|
||||
- `会计师 / Activity 3 / Step 2`: 判断已提交内容是否完整可用
|
||||
- `会计师 / Activity 3 / Step 3`: 在必要时再次提醒客户补交
|
||||
- `会计师 / Activity 4 / Step 2`: 跟踪每个案件当前卡住的位置
|
||||
- `会计师 / Activity 4 / Step 3`: 在截止日前完成关键推进
|
||||
- `会计师 / Activity 5 / Step 1`: 发起最终确认动作
|
||||
- `会计师 / Activity 5 / Step 2`: 确认客户已完成必要回应
|
||||
- `事务所老板 / Activity 1 / Step 2`: 区分逾期、紧急和正常事项
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
围绕单个案件聚合需求判断、报价、资料状态、提醒、进度、签字和风险信号，成为会计师推进执行与老板下钻干预的共同工作面。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 服务范围与报价工作流
|
||||
- 资料完整性核验
|
||||
- 客户补件提醒
|
||||
- 案件进度与风险跟踪
|
||||
- 收尾确认与签字发起
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: client-completion
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 服务完成页
|
||||
---
|
||||
|
||||
# 服务完成页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/invite/:inviteToken/done`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Client
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `客户 / Activity 5 / Step 2`: 获得服务完成的明确信号
|
||||
- `客户 / Activity 5 / Step 3`: 在未来需要时继续回来合作
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
明确告知客户本次服务已闭环，并保留后续联系、再次合作和查看历史结果的信心锚点。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 服务完成确认
|
||||
- 后续合作入口
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: client-documents
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 资料提交与进度页
|
||||
---
|
||||
|
||||
# 资料提交与进度页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/invite/:inviteToken/documents`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Client
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `客户 / Activity 4 / Step 1`: 按要求逐步提供资料
|
||||
- `客户 / Activity 4 / Step 2`: 查看哪些已经被收到或还不够完整
|
||||
- `客户 / Activity 4 / Step 3`: 在收到提醒后补齐缺失内容
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
为客户提供分步骤资料上传、状态查看和补件响应入口，让客户始终知道现在缺什么、哪些已通过、哪些仍需处理。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 资料清单交付
|
||||
- 资料上传提交
|
||||
- 资料状态可视化
|
||||
- 补件响应处理
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: client-quote-review
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 报价确认页
|
||||
---
|
||||
|
||||
# 报价确认页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/invite/:inviteToken/quote`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Client
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `客户 / Activity 3 / Step 1`: 查看对方给出的服务说明
|
||||
- `客户 / Activity 3 / Step 2`: 理解费用和所需准备内容
|
||||
- `客户 / Activity 3 / Step 3`: 给出是否继续的回应
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
向客户清楚展示服务范围、费用说明和资料准备要求，并接收客户是否继续合作的决定，避免进入正式服务后再出现预期偏差。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 服务说明展示
|
||||
- 费用与准备项说明
|
||||
- 报价回应确认
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: client-record
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 客户档案页
|
||||
---
|
||||
|
||||
# 客户档案页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/workspace/clients/:clientId`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Accountant
|
||||
- Firm Owner
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `会计师 / Activity 5 / Step 3`: 让本次服务留下完整记录
|
||||
- `事务所老板 / Activity 5 / Step 3`: 形成可持续维护的经营判断
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
沉淀客户基础资料、服务历史、介绍关系、AI 画像和归档记录，支持会计师减少重复沟通，也让老板从单个客户视角理解长期资产价值。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 客户历史归档
|
||||
- 转介绍关系洞察
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: client-registration
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 注册与需求填写页
|
||||
---
|
||||
|
||||
# 注册与需求填写页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/invite/:inviteToken/register`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Client
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `客户 / Activity 1 / Step 3`: 理解为什么需要我继续提供信息
|
||||
- `客户 / Activity 2 / Step 1`: 填写自己的基本情况
|
||||
- `客户 / Activity 2 / Step 2`: 说明自己需要解决的事情
|
||||
- `客户 / Activity 2 / Step 3`: 等待对方确认我已经可以继续往下走
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
收集客户基础信息与服务需求，解释信息用途，降低重复填写焦虑，并让客户在提交后明确知道当前是否已经满足继续推进条件。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 信息用途说明
|
||||
- 客户基础信息采集
|
||||
- 服务需求采集
|
||||
- 提交就绪反馈
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: client-signature
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 在线签字页
|
||||
---
|
||||
|
||||
# 在线签字页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/invite/:inviteToken/sign`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Client
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `客户 / Activity 5 / Step 1`: 对最终结果做必要确认
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
承接服务收尾所需的最终确认与签字动作，让客户在明确内容的前提下完成最后一环。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 签字内容确认
|
||||
@@ -0,0 +1,19 @@
|
||||
# Page Index
|
||||
|
||||
| Route | Page Name | Accessible Persona | Responsibility |
|
||||
| --- | --- | --- | --- |
|
||||
| /workspace/today | [会计师作战台](./accountant-dashboard.md) | Accountant | 聚合今日待办、过期事项、临期案件和新客提示，帮助会计师快速决定先做什么、后做什么。 |
|
||||
| /workspace/intake | [新客审核台](./accountant-intake.md) | Accountant | 集中处理新客户资料、介绍来源、AI 初审结果和接纳决策，把“是否正式建档”从零散沟通变成可追踪的审核动作。 |
|
||||
| /workspace/cases/:caseId | [案件工作台](./case-workspace.md) | Accountant | 围绕单个案件聚合需求判断、报价、资料状态、提醒、进度、签字和风险信号，成为会计师推进执行与老板下钻干预的共同工作面。 |
|
||||
| /invite/:inviteToken/done | [服务完成页](./client-completion.md) | Client | 明确告知客户本次服务已闭环，并保留后续联系、再次合作和查看历史结果的信心锚点。 |
|
||||
| /invite/:inviteToken/documents | [资料提交与进度页](./client-documents.md) | Client | 为客户提供分步骤资料上传、状态查看和补件响应入口，让客户始终知道现在缺什么、哪些已通过、哪些仍需处理。 |
|
||||
| /invite/:inviteToken/quote | [报价确认页](./client-quote-review.md) | Client | 向客户清楚展示服务范围、费用说明和资料准备要求，并接收客户是否继续合作的决定，避免进入正式服务后再出现预期偏差。 |
|
||||
| /workspace/clients/:clientId | [客户档案页](./client-record.md) | Accountant | 沉淀客户基础资料、服务历史、介绍关系、AI 画像和归档记录，支持会计师减少重复沟通，也让老板从单个客户视角理解长期资产价值。 |
|
||||
| /invite/:inviteToken/register | [注册与需求填写页](./client-registration.md) | Client | 收集客户基础信息与服务需求，解释信息用途，降低重复填写焦虑，并让客户在提交后明确知道当前是否已经满足继续推进条件。 |
|
||||
| /invite/:inviteToken/sign | [在线签字页](./client-signature.md) | Client | 承接服务收尾所需的最终确认与签字动作，让客户在明确内容的前提下完成最后一环。 |
|
||||
| /invite/:inviteToken | [邀请进入页](./invite-entry.md) | Client | 承接客户收到邀请后的第一触点，展示介绍关系带来的信任上下文，并完成邀请码验证或进入验证前说明，让客户确认自己进入的是可信、明确、低摩擦的服务入口。 |
|
||||
| /owner/automation | [自动化策略页](./owner-automation.md) | Firm Owner | 让老板看到自动跟进是否有效，并按客户等级、场景风险和业务边界调整自动化策略，确保效率提升不会破坏关系质量。 |
|
||||
| /owner/briefing | [事务所经营总览页](./owner-briefing.md) | Firm Owner | 以老板视角聚合今日经营态势、收入变化、案件分布和风险摘要，支持早报查看、当日判断与次日优先级准备。 |
|
||||
| /owner/exceptions | [升级处理页](./owner-exceptions.md) | Firm Owner | 聚合真正需要老板亲自介入的关系风险、投诉风险和流失风险，避免老板被普通事务打扰，同时不错过高影响异常。 |
|
||||
| /owner/portfolio | [客户资产与关系页](./owner-portfolio.md) | Firm Owner | 展示转介绍关系图谱、客户分类和 AI 画像，让老板从客户资产与关系网络的视角识别长期价值与潜在风险。 |
|
||||
| /owner/team | [团队推进页](./owner-team-operations.md) | Firm Owner | 帮助老板从团队维度查看会计师工作负载、推进节奏和卡点分布，并完成客户、案件与跟进责任的分配调整，用于调度资源和发现执行瓶颈。 |
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: invite-entry
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 邀请进入页
|
||||
---
|
||||
|
||||
# 邀请进入页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/invite/:inviteToken`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Client
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `客户 / Activity 1 / Step 1`: 通过邀请进入服务流程
|
||||
- `客户 / Activity 1 / Step 2`: 完成身份确认
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
承接客户收到邀请后的第一触点，展示介绍关系带来的信任上下文，并完成邀请码验证或进入验证前说明，让客户确认自己进入的是可信、明确、低摩擦的服务入口。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 邀请信任入口
|
||||
- 邀请码身份确认
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: owner-automation
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 自动化策略页
|
||||
---
|
||||
|
||||
# 自动化策略页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/owner/automation`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `事务所老板 / Activity 4 / Step 1`: 观察自动提醒和自动跟进的效果
|
||||
- `事务所老板 / Activity 4 / Step 2`: 对敏感客户或敏感场景调整处理方式
|
||||
- `事务所老板 / Activity 4 / Step 3`: 保留对金钱承诺和投诉处理的最终控制
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
让老板看到自动跟进是否有效，并按客户等级、场景风险和业务边界调整自动化策略，确保效率提升不会破坏关系质量。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 自动化效果观察
|
||||
- 敏感场景自动化规则
|
||||
- 人工接管边界
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: owner-briefing
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 事务所经营总览页
|
||||
---
|
||||
|
||||
# 事务所经营总览页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/owner/briefing`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `事务所老板 / Activity 1 / Step 1`: 查看今日工作的总体分布
|
||||
- `事务所老板 / Activity 1 / Step 3`: 了解客户、案件和收入的变化
|
||||
- `事务所老板 / Activity 5 / Step 1`: 回顾今日新增、推进、完成和风险情况
|
||||
- `事务所老板 / Activity 5 / Step 2`: 识别明天最需要优先关注的事项
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
以老板视角聚合今日经营态势、收入变化、案件分布和风险摘要，支持早报查看、当日判断与次日优先级准备。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 老板每日经营简报
|
||||
- 老板优先级预判
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: owner-exceptions
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 升级处理页
|
||||
---
|
||||
|
||||
# 升级处理页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/owner/exceptions`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `事务所老板 / Activity 2 / Step 1`: 查看高价值客户和高风险客户提醒
|
||||
- `事务所老板 / Activity 2 / Step 3`: 接收差评、反复改约或长期沉默的升级信号
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
聚合真正需要老板亲自介入的关系风险、投诉风险和流失风险，避免老板被普通事务打扰，同时不错过高影响异常。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 高价值客户提醒
|
||||
- 升级异常处理
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: owner-portfolio
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 客户资产与关系页
|
||||
---
|
||||
|
||||
# 客户资产与关系页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/owner/portfolio`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `事务所老板 / Activity 2 / Step 2`: 识别来源不清或关系敏感的客户
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
展示转介绍关系图谱、客户分类和 AI 画像，让老板从客户资产与关系网络的视角识别长期价值与潜在风险。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 转介绍关系洞察
|
||||
- 客户资产分层
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
artifact_type: page
|
||||
slug: owner-team-operations
|
||||
round: 3
|
||||
status: draft
|
||||
project: maxcpa
|
||||
title: 团队推进页
|
||||
---
|
||||
|
||||
# 团队推进页
|
||||
|
||||
## Route Information
|
||||
|
||||
- Route: `/owner/team`
|
||||
|
||||
## Accessible Persona
|
||||
|
||||
- Firm Owner
|
||||
|
||||
## Story Steps Covered
|
||||
|
||||
- `事务所老板 / Activity 3 / Step 1`: 查看每位会计师当前的推进情况
|
||||
- `事务所老板 / Activity 3 / Step 2`: 调整会计师的客户与案件分配
|
||||
- `事务所老板 / Activity 3 / Step 3`: 确认哪些事项需要老板或会计师额外跟进
|
||||
|
||||
## Page Responsibility
|
||||
|
||||
帮助老板从团队维度查看会计师工作负载、推进节奏和卡点分布，并完成客户、案件与跟进责任的分配调整，用于调度资源和发现执行瓶颈。
|
||||
|
||||
## Related Features
|
||||
|
||||
- 会计师负载与分配管理
|
||||
@@ -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) | |
|
||||
@@ -0,0 +1,40 @@
|
||||
# Feature Coverage Matrix
|
||||
|
||||
| Feature | Service Persona | Source Page | Covered Story |
|
||||
| --- | --- | --- | --- |
|
||||
| feature:accountant-workload-and-assignment | | | |
|
||||
| feature:automation-effect-observability | | | |
|
||||
| feature:automation-sensitivity-rules | | | |
|
||||
| feature:case-closeout-and-signoff | | | |
|
||||
| feature:case-progress-and-risk-tracking | | | |
|
||||
| feature:client-history-archive | | | |
|
||||
| feature:client-portfolio-segmentation | | | |
|
||||
| feature:client-profile-intake | | | |
|
||||
| feature:client-reminder-orchestration | | | |
|
||||
| feature:client-return-path | | | |
|
||||
| feature:client-service-closure | | | |
|
||||
| feature:daily-priority-board | | | |
|
||||
| feature:document-checklist-delivery | | | |
|
||||
| feature:document-completeness-review | | | |
|
||||
| feature:document-status-visibility | | | |
|
||||
| feature:document-upload-submission | | | |
|
||||
| feature:escalation-exception-handling | | | |
|
||||
| feature:fee-and-preparation-clarity | | | |
|
||||
| feature:high-value-client-alerts | | | |
|
||||
| feature:information-purpose-guidance | | | |
|
||||
| feature:intake-acceptance-decision | | | |
|
||||
| feature:intake-submission-review | | | |
|
||||
| feature:invite-code-verification | | | |
|
||||
| feature:invite-trust-entry | | | |
|
||||
| feature:manual-override-governance | | | |
|
||||
| feature:owner-daily-briefing | | | |
|
||||
| feature:owner-priority-forecast | | | |
|
||||
| feature:quote-decision-response | | | |
|
||||
| feature:quote-package-presentation | | | |
|
||||
| feature:referral-relationship-insight | | | |
|
||||
| feature:referral-source-verification | | | |
|
||||
| feature:service-need-capture | | | |
|
||||
| feature:service-scope-and-quote | | | |
|
||||
| feature:signoff-content-confirmation | | | |
|
||||
| feature:submission-readiness-feedback | | | |
|
||||
| feature:supplement-request-response | | | |
|
||||
@@ -0,0 +1,97 @@
|
||||
# Persona Story Page Matrix
|
||||
|
||||
| Persona | Story Map | Page | Feature |
|
||||
| --- | --- | --- | --- |
|
||||
| persona:accountant | | | |
|
||||
| persona:client | | | |
|
||||
| persona:firm-owner | | | |
|
||||
| | story_map:accountant | | |
|
||||
| | story_map:client | | |
|
||||
| | story_map:firm-owner | | |
|
||||
| | | page:accountant-dashboard | |
|
||||
| | | page:accountant-intake | |
|
||||
| | | page:case-workspace | |
|
||||
| | | page:client-completion | |
|
||||
| | | page:client-documents | |
|
||||
| | | page:client-quote-review | |
|
||||
| | | page:client-record | |
|
||||
| | | page:client-registration | |
|
||||
| | | page:client-signature | |
|
||||
| | | page:invite-entry | |
|
||||
| | | page:owner-automation | |
|
||||
| | | page:owner-briefing | |
|
||||
| | | page:owner-exceptions | |
|
||||
| | | page:owner-portfolio | |
|
||||
| | | page:owner-team-operations | |
|
||||
| | | | feature:accountant-workload-and-assignment |
|
||||
| | | | feature:automation-effect-observability |
|
||||
| | | | feature:automation-sensitivity-rules |
|
||||
| | | | feature:case-closeout-and-signoff |
|
||||
| | | | feature:case-progress-and-risk-tracking |
|
||||
| | | | feature:client-history-archive |
|
||||
| | | | feature:client-portfolio-segmentation |
|
||||
| | | | feature:client-profile-intake |
|
||||
| | | | feature:client-reminder-orchestration |
|
||||
| | | | feature:client-return-path |
|
||||
| | | | feature:client-service-closure |
|
||||
| | | | feature:daily-priority-board |
|
||||
| | | | feature:document-checklist-delivery |
|
||||
| | | | feature:document-completeness-review |
|
||||
| | | | feature:document-status-visibility |
|
||||
| | | | feature:document-upload-submission |
|
||||
| | | | feature:escalation-exception-handling |
|
||||
| | | | feature:fee-and-preparation-clarity |
|
||||
| | | | feature:high-value-client-alerts |
|
||||
| | | | feature:information-purpose-guidance |
|
||||
| | | | feature:intake-acceptance-decision |
|
||||
| | | | feature:intake-submission-review |
|
||||
| | | | feature:invite-code-verification |
|
||||
| | | | feature:invite-trust-entry |
|
||||
| | | | feature:manual-override-governance |
|
||||
| | | | feature:owner-daily-briefing |
|
||||
| | | | feature:owner-priority-forecast |
|
||||
| | | | feature:quote-decision-response |
|
||||
| | | | feature:quote-package-presentation |
|
||||
| | | | feature:referral-relationship-insight |
|
||||
| | | | feature:referral-source-verification |
|
||||
| | | | feature:service-need-capture |
|
||||
| | | | feature:service-scope-and-quote |
|
||||
| | | | feature:signoff-content-confirmation |
|
||||
| | | | feature:submission-readiness-feedback |
|
||||
| | | | feature:supplement-request-response |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
| | | | |
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user