# HOMEVISTA 模块化展示产品方案

## 一、产品变化概述

HOMEVISTA 当前更像一套固定完整的数字售楼处系统，默认把 3D 大楼、虚拟样板间、眺望集、户型图、住户表、周边地图、资料集、预约等内容全部放在同一个项目入口中。

但在实际销售中，客户并不一定购买完整系统。很多客户只会购买其中一个或几个模块，例如：

- 只购买虚拟样板间
- 只购买眺望集
- 只购买 3D 大楼
- 购买 3D 大楼 + 虚拟样板间
- 购买完整线上售楼处

因此，HOMEVISTA 的产品形态需要从“固定完整系统”转变为“模块化数字展示产品”。

```text
过去：
客户进入一个完整系统
所有功能默认都在里面

现在要改成：
客户买什么
系统就展示什么
最终生成一个定制化项目展示链接

进一步要做到：
即使客户购买了完整系统
销售也可以像制作 PPT 一样
按不同人群、不同讲解目的、不同销售阶段
自由组合卖房所需资讯并形成不同演示方案
```

## 二、产品定位

**HOMEVISTA 模块化数字展示套件**

面向房地产项目销售场景，根据客户预算、项目阶段、展示需求和销售讲解习惯，自由组合地产商卖房时需要表达的各类资讯，包括项目形象、建筑外观、户型、室内空间、楼层视野、房源状态、价格面积、周边配套、生活方式、资料文件、预约转化和客户访问数据，为每个项目生成定制化线上展示链接和多套演示方案。

一句话表达：

**客户不再购买一套固定系统，而是按需求组合适合自己项目的数字展示方案；销售也不再只能按固定菜单讲解，而是可以像 PPT 一样自由编排卖房所需资讯的展示顺序。**

## 三、产品总览图

```mermaid
flowchart LR
    A["客户需求"] --> B["选择销售信息资产"]
    B --> C["组合成项目展示方案"]
    C --> D["生成定制展示链接"]
    C --> F["生成销售讲解路径"]
    D --> E["线上看房 / 销售演示 / 预约转化"]
    F --> G["按人群 / 场景 / 熟悉程度选择演示方案"]

    B --> B1["3D 大楼"]
    B --> B2["虚拟样板间"]
    B --> B3["眺望集"]
    B --> B4["户型 / 面积 / 价格"]
    B --> B5["房源状态"]
    B --> B6["区位 / 配套 / 生活方式"]
    B --> B7["资料 / 证照 / 说明"]
    B --> B8["预约 / 咨询 / 数据"]
```

## 四、给产品部、技术部、UI 设计的理解重点

这份方案不是单纯的销售话术，也不是开发排期。它的目的是让产品部、技术部和 UI 设计对同一个产品变化形成一致理解。

需要特别说明：后续推进时，**产品方案、UI 方案、技术实现方案应分开整理**。

| 文档类型 | 主要回答的问题 | 主要负责对象 |
|---|---|---|
| 产品方案 | 为什么要改、服务哪些角色、有哪些场景、哪些资讯可以组合、哪些比较页面有价值 | 产品部 |
| UI 方案 | 页面怎么组织、入口怎么呈现、演示方案怎么选择、比较页怎么布局、移动端怎么体验 | UI 设计 |
| 技术实现方案 | 现有系统能否承接、哪些需要改造、哪些需要重做、数据和配置如何支持 | 技术部 |

本文件主要是产品方案，同时为 UI 和技术说明理解边界。后续可以在此基础上拆出单独的 UI 设计需求和技术评估方案。

### 1. 产品部需要理解什么

产品部要把 HOMEVISTA 从“功能菜单系统”重新定义为“卖房资讯组织系统”。

重点不是问：

```text
系统里有哪些功能按钮？
```

而是问：

```text
地产商卖房时，需要向客户讲清楚哪些信息？
这些信息能否被单独展示？
能否被组合？
能否被比较？
能否根据客户阶段形成不同路径？
```

产品部需要重点定义：

- 哪些内容属于销售信息资产
- 哪些资产可以单独销售
- 哪些资产可以组合销售
- 哪些资产需要进入比较页面
- 不同客户阶段对应哪些展示路径
- 销售人员需要哪些默认讲解路径
- 哪些内容需要作为客户行为数据记录

### 2. 技术部需要理解什么

技术部这里暂时不需要进入具体实现，但需要理解产品结构变化。

过去系统更像：

```text
一个项目 = 一套固定页面 + 固定菜单
```

未来应该理解为：

```text
一个项目 = 一组销售信息资产
展示链接 = 从资产中选择一部分形成的展示组合
讲解路径 = 对展示组合重新排序后的讲解顺序
比较页面 = 将多个资产并列展示，用于辅助客户决策
```

技术部需要提前理解几个对象关系：

| 概念 | 含义 |
|---|---|
| 项目 | 一个楼盘或一个销售项目 |
| 销售信息资产 | 项目中可展示、可组合、可比较的内容，如户型、样板间、眺望、价格、房源状态 |
| 展示组合 | 面向某个客户或某类场景选择出来的一组资产 |
| 讲解路径 | 展示组合里的内容顺序，类似 PPT 的讲解顺序 |
| 比较页面 | 将多个户型、样板间、楼层或房源放在一起比较的页面 |
| 转化入口 | 预约、联系销售、资料下载、咨询等动作 |
| 行为数据 | 客户看了什么、停留在哪、比较了什么、是否预约 |

这不是要求技术部立刻开发后台，而是先让技术部理解：未来 HOMEVISTA 不能只围绕固定菜单组织，而要围绕“资产、组合、路径、比较、转化、数据”来组织。

### 3. UI 设计需要理解什么

UI 设计不应只设计一个大菜单，也不应把所有内容塞进同一个首页。

UI 要重点考虑四类页面：

| 页面类型 | 设计重点 |
|---|---|
| 单资产展示页 | 一个模块也要看起来完整，例如单独的虚拟样板间展示页 |
| 组合展示页 | 多个资产组成一个项目展示方案，入口要清楚 |
| 讲解路径页 | 像 PPT 一样按顺序讲解，适合销售演示 |
| 比较页面 | 横向比较户型、样板间、眺望、房源，帮助客户做选择 |

特别需要注意的是：“完整系统也可以拆成多个讲解路径”这一点必须体现在 UI 里。

这里的“讲解路径 / 演示方案”不是自动播放视频，也不是系统自动轮播页面，而是指：

```text
系统把产品功能和项目内容，
按照不同客群、不同销售场景、不同讲解目的，
预先分类组合成多套演示方案。

销售人员讲解时，
可以选择某一套演示方案，
按顺序带客户看内容，
也可以根据客户反应临时跳转或切换。
```

对 UI 来说，这不是普通菜单设计，而是要设计一套销售演示界面：

| UI 对象 | 需要解决的问题 |
|---|---|
| 路径选择入口 | 销售进入完整项目后，可以选择“项目认知路径”“深度看房路径”“房源比较路径”等不同讲法 |
| 路径演示页 | 进入某条路径后，页面要像 PPT 一样按顺序展示内容 |
| 路径进度提示 | 销售和客户要知道当前看到第几步、后面还有什么 |
| 上一步 / 下一步 | 销售讲解时可以自然切换，不必回到大菜单 |
| 路径内跳转 | 客户临时关注某个内容时，可以跳到相关资产或比较页 |
| 路径切换 | 同一套完整系统中，可以从“户型讲解”切换到“眺望比较”或“预算筛选” |
| 结束动作 | 每条路径最后都应该有预约、联系销售、查看资料、保存推荐房源等下一步动作 |

UI 的核心目标不是“功能多”，而是：

```text
让客户知道现在看什么
为什么要看这个
它和其他选择有什么差异
下一步应该做什么
```

## 五、核心产品逻辑

### 1. 客户按需求购买

客户不需要一次购买完整系统，可以根据实际需求选择一个或多个模块。

| 客户类型 | 购买内容 | 生成结果 |
|---|---|---|
| 客户 A | 只购买虚拟样板间 | 生成虚拟样板间展示链接 |
| 客户 B | 只购买眺望集 | 生成楼层视野展示链接 |
| 客户 C | 购买 3D 大楼 + 眺望集 | 生成建筑与视野展示链接 |
| 客户 D | 购买完整方案 | 生成完整线上售楼处 |

### 2. 系统按购买内容展示

项目页面只展示客户已购买的模块，不展示未购买模块。

```text
客户只买虚拟样板间：
页面只显示虚拟样板间、户型选择、联系销售、分享入口

客户只买 3D 大楼：
页面只显示建筑外观、楼栋展示、联系销售、分享入口

客户购买完整方案：
页面显示 3D 大楼、虚拟样板间、户型图、住户表、资料集、预约转化等完整内容
```

### 3. 单模块也要成为完整产品

单模块展示不是“少了很多功能的系统”，而是一个完整的小产品。

例如客户只购买虚拟样板间时，页面不应该显示其他无关功能，而应该直接围绕虚拟样板间形成完整体验：

- 项目名称
- 虚拟样板间主视觉
- 户型选择
- 进入看房
- 联系销售
- 分享链接

### 4. 完整系统也可以拆成多个讲解路径

即使客户购买了完整系统，也不代表每一次销售讲解都要从头到尾展示全部功能。

销售人员可以根据客户对象、客户关注点和自己的讲解习惯，把项目中已购买、已制作或已整理的销售信息资产重新组合成不同的演示子方案或讲解路径。

```text
同一个完整系统：
可以给首次来访客户讲“项目整体形象路径”
也可以给意向客户讲“户型与样板间路径”
也可以给高层客户讲“视野与楼层价值路径”
也可以给管理者讲“客户行为与销售数据路径”
```

这个能力的本质是：

**不是固定照搬几个模块名称，而是把地产商卖房时需要表达的信息，按销售逻辑自由组合和重新编排。**

## 六、销售信息资产拆分方案

这里的分类不是固定不变的功能清单，而是为了帮助产品、销售和设计理解：地产商在卖房过程中，通常需要向客户表达哪些资讯。

HOMEVISTA 的产品改造重点，不是把系统硬拆成几个固定按钮，而是把这些资讯变成可以被组合、排序、讲解和分享的“销售信息资产”。

```text
HOMEVISTA 可组合销售信息资产

├─ 建筑展示类
│  ├─ 3D 大楼
│  ├─ 外观静态图
│  └─ 效果图
│
├─ 空间体验类
│  ├─ 虚拟样板间
│  ├─ WALK 看房
│  └─ 公共区域展示
│
├─ 视野价值类
│  ├─ 眺望集
│  ├─ 楼层视野
│  └─ 方位景观
│
├─ 房源信息类
│  ├─ 户型图
│  ├─ 楼层平面图
│  ├─ 面积 / 价格
│  ├─ 房源状态
│  └─ 住户表
│
├─ 对比决策类
│  ├─ 户型对比
│  ├─ 样板间对比
│  ├─ 楼层视野对比
│  ├─ 价格面积对比
│  ├─ 房源状态对比
│  └─ 推荐房源对比
│
├─ 项目价值类
│  ├─ 项目卖点
│  ├─ 区位价值
│  ├─ 周边配套
│  ├─ 交通信息
│  └─ 生活方式说明
│
├─ 销售辅助类
│  ├─ 资料集
│  ├─ 周边地图
│  ├─ 贷款计算器
│  ├─ 预约联系
│  └─ 销售话术说明
│
└─ 数据运营类
   ├─ 客户访问记录
   ├─ 关注户型
   ├─ 停留时间
   └─ 销售跟进线索
```

## 七、重点模块说明

第一阶段建议优先包装三个最容易被客户单独购买、也最容易被销售拿来讲解的展示资产。

| 模块 | 客户购买原因 | 产品表达 |
|---|---|---|
| 3D 大楼 | 看项目外观、体量、楼栋关系 | 在线展示建筑整体形象 |
| 虚拟样板间 | 看室内空间、生活动线、装修氛围 | 在线进入未来的家 |
| 眺望集 | 看不同楼层、方位、景观价值 | 提前理解视野差异 |

### 1. 3D 大楼

适合项目早期展示、招商、销售中心讲解、客户远程了解项目整体形象。

核心价值：

- 展示建筑外观
- 展示楼栋体量
- 展示项目整体气质
- 帮助客户建立第一印象

### 2. 虚拟样板间

适合客户远程看房、样板间不足、异地客户预沟通、销售人员线上讲解。

核心价值：

- 展示户内空间
- 展示生活动线
- 展示装修氛围
- 降低客户到访前的理解成本

### 3. 眺望集

适合强调楼层差异、景观价值、朝向价值、不同房源卖点的项目。

核心价值：

- 展示不同楼层视野
- 展示不同朝向景观
- 帮助客户理解房源价值差异
- 支持销售进行楼层和户型推荐

## 八、比较型页面能力

房地产销售过程中，客户并不是只看单个内容，而是经常在多个选择之间反复比较。

例如：

- A 户型和 B 户型哪个更适合？
- 同样面积下，哪个户型动线更好？
- 不同楼层的眺望差异在哪里？
- 同一个户型，不同装修风格哪个更有吸引力？
- 价格相近的几套房，哪一套综合价值更高？
- 销售为什么推荐这几套，而不是其他房源？

因此，HOMEVISTA 不应该只提供“展示页面”，还应该强化“比较页面”。比较页面的价值是帮助客户做选择，也帮助销售解释推荐理由。

### 1. 户型比较页面

用于比较不同户型的面积、房间数量、动线、收纳、采光、适合人群和价格区间。

| 比较维度 | 说明 |
|---|---|
| 户型结构 | 2LDK、3LDK、4LDK 等 |
| 面积 | 建筑面积、使用感、空间尺度 |
| 房间配置 | 卧室数量、客厅、厨房、卫浴、收纳 |
| 生活动线 | 入户、客餐厅、卧室、阳台之间的关系 |
| 适合人群 | 单身、夫妻、小家庭、三代同住、投资 |
| 价格区间 | 总价、单价、月供参考 |
| 推荐理由 | 为什么销售建议客户优先看这个户型 |

示例演示方式：

```text
客户需求 → 户型 A → 户型 B → 户型差异 → 推荐户型 → 进入样板间
```

### 2. 虚拟样板间比较页面

用于比较不同户型、不同装修风格、不同家具方案下的空间体验。

| 比较维度 | 说明 |
|---|---|
| 空间尺度 | 客厅、卧室、厨房、卫浴的体感 |
| 生活动线 | 从玄关到客厅、卧室、阳台的使用顺序 |
| 装修风格 | 不同风格对客户想象的影响 |
| 家具布置 | 有家具 / 无家具 / 不同家具方案 |
| 采光感受 | 窗、阳台、朝向带来的空间感 |
| 适合人群 | 自住、家庭、投资出租、改善型客户 |

示例演示方式：

```text
户型图 → 样板间 A → 样板间 B → 空间差异 → 推荐生活场景
```

### 3. 眺望与楼层比较页面

用于比较不同楼层、不同朝向、不同房源的视野价值。

| 比较维度 | 说明 |
|---|---|
| 楼层 | 低层、中层、高层的视野差异 |
| 朝向 | 南向、东向、西向、角部房源等 |
| 景观 | 城市景观、绿地、水景、道路、邻栋关系 |
| 遮挡 | 是否被建筑物、树木、设施遮挡 |
| 价格差异 | 视野差异对应的价格差异 |
| 推荐理由 | 为什么某一楼层或朝向更适合客户 |

示例演示方式：

```text
楼栋位置 → 楼层选择 → 眺望 A → 眺望 B → 价格差异 → 推荐房源
```

### 4. 房源综合比较页面

用于销售推荐具体房源时，把多个房源放在一起比较。

| 比较维度 | 房源 A | 房源 B | 房源 C |
|---|---|---|---|
| 户型 | 3LDK | 3LDK | 4LDK |
| 面积 | 74㎡ | 76㎡ | 84㎡ |
| 楼层 | 5F | 7F | 9F |
| 价格 | 参考价格 | 参考价格 | 参考价格 |
| 眺望 | 中等 | 较好 | 最好 |
| 状态 | 可售 | 商谈中 | 可售 |
| 适合客户 | 预算优先 | 综合均衡 | 景观优先 |

这一页面可以成为销售推荐房源时最有价值的页面。

它不是让客户自己在大量信息里找答案，而是帮助销售把推荐逻辑讲清楚：

```text
为什么推荐这几套？
它们之间差在哪里？
哪一套更适合当前客户？
客户下一步应该看哪一个样板间或预约哪一套？
```

### 5. 比较页面的产品价值

| 对象 | 价值 |
|---|---|
| 客户 | 更容易理解差异，减少选择困难 |
| 销售 | 更容易解释推荐理由，提高说服力 |
| 开发商 | 能把户型、楼层、景观和价格价值讲清楚 |
| HOMEVISTA | 从“展示系统”升级为“辅助决策系统” |

### 6. 比较页面的通用结构

比较页面不应只是把多个内容放在一起。它要帮助客户看懂“差异”和“推荐理由”。

建议每个比较页面都包含以下结构：

| 页面区域 | 内容 | 目的 |
|---|---|---|
| 比较标题 | 例如“3 个推荐户型比较” | 让客户知道当前页面在比较什么 |
| 客户需求提示 | 例如“适合预算优先 / 景观优先 / 家庭居住” | 让比较有明确依据 |
| 对比对象 | 户型 A、户型 B、户型 C 或房源 A、房源 B、房源 C | 明确参与比较的对象 |
| 核心指标 | 面积、价格、楼层、朝向、景观、状态等 | 用事实信息支撑比较 |
| 视觉内容 | 户型图、样板间截图、眺望图、楼栋位置 | 帮客户形成直观判断 |
| 差异说明 | 每个对象的优势和限制 | 避免客户只看到信息，看不懂差异 |
| 推荐结论 | 推荐哪一个，为什么 | 帮销售完成说明和推进 |
| 下一步动作 | 查看样板间、预约、联系销售、下载资料 | 把比较引向转化 |

### 7. 给 UI 设计的比较页面要点

比较页面的 UI 重点是“清楚”和“可判断”，不是单纯做得热闹。

UI 设计应注意：

- 比较对象不要过多，默认 2 到 3 个最合适。
- 核心指标要表格化，避免客户来回找信息。
- 每个对象要有视觉主图，例如户型图、样板间图、眺望图。
- 差异说明要短，突出“为什么不同”。
- 推荐结论要醒目，但不要遮挡客户自主比较。
- 页面底部应保留下一步动作，例如“查看样板间”“预约看房”“联系销售”。

示意结构：

```text
页面标题：推荐房源比较

客户需求：
预算 5,000 万日元以内 / 3LDK / 重视采光和眺望

对比卡片：
房源 A        房源 B        房源 C
户型图        户型图        户型图
面积          面积          面积
价格          价格          价格
楼层          楼层          楼层
眺望          眺望          眺望
状态          状态          状态

差异说明：
A 适合预算优先
B 综合均衡
C 景观更好但价格更高

推荐结论：
优先推荐 B，其次推荐 A

下一步：
查看 B 户型样板间 / 预约看房 / 联系销售
```

### 8. 给产品部的比较页面定义事项

产品部在定义比较页面时，需要先回答以下问题：

- 这个页面比较的是户型、样板间、楼层视野，还是具体房源？
- 最多允许比较几个对象？
- 哪些指标是必须展示的？
- 哪些指标可以由项目自行配置？
- 推荐理由由谁填写，是销售填写、项目默认，还是系统根据规则生成？
- 比较页面是否可以保存成讲解路径的一页？
- 比较页面是否记录客户点击和停留数据？

### 9. 给技术部的比较页面理解边界

技术部暂时不需要理解成复杂算法。第一阶段可以把比较页面理解为：

```text
从同一项目中选择 2 到 3 个对象
把它们的关键字段并列展示
允许销售添加推荐说明
允许客户从比较页跳转到具体展示页或预约页
```

也就是说，比较页面第一阶段不一定要自动推荐，它可以先支持人工选择和人工说明。后续再考虑根据客户行为数据、预算、户型偏好等做自动推荐。

## 九、产品组合方式

建议将展示资产包装成四类产品方案，便于销售报价和客户理解。这里的组合可以根据具体项目调整，不必完全固定。

| 产品方案 | 适合客户 | 包含内容 | 销售表达 |
|---|---|---|---|
| 单模块展示 | 只买一个能力的客户 | 虚拟样板间 / 眺望集 / 3D 大楼任选其一 | 先用一个模块解决当前展示需求 |
| 视觉展示组合 | 重视项目形象的客户 | 3D 大楼 + 效果图 + 虚拟样板间 + 眺望集 | 让客户在线理解项目外观、空间和视野 |
| 项目展示组合 | 一个楼盘正式对外展示 | 3D 大楼 + 户型图 + 样板间 + 资料集 + 周边地图 | 形成一个完整项目展示链接 |
| 数字售楼处 | 需要销售转化的客户 | 项目展示组合 + 住户表 + 比较页面 + 预约 + 数据追踪 | 从展示进入销售推荐、比较决策和客户转化 |

## 十、页面表现逻辑

```mermaid
flowchart TD
    A["打开项目链接"] --> B{"客户购买了几个模块？"}

    B -->|"只购买一个模块"| C["单模块展示页"]
    B -->|"购买多个模块"| D["项目组合展示页"]
    B -->|"购买完整方案"| E["数字售楼处首页"]

    C --> C1["直接进入虚拟样板间 / 眺望集 / 3D 大楼"]
    D --> D1["展示已购买模块入口"]
    E --> E1["展示完整销售路径"]
```

### 1. 单模块展示页

适用于客户只购买一个模块的情况。

示例：客户只购买虚拟样板间

```text
页面内容：
项目名称
虚拟样板间主视觉
户型选择
进入看房
联系销售
分享链接
```

不应出现：

- 3D 大楼
- 住户表
- 周边地图
- 贷款计算器
- 其他未购买模块

### 2. 多模块组合展示页

适用于客户购买多个展示模块的情况。

示例：客户购买 3D 大楼 + 眺望集 + 虚拟样板间

```text
首页内容：
项目主视觉
3D 大楼入口
眺望集入口
虚拟样板间入口
联系销售 / 预约看房
分享按钮
```

### 3. 完整数字售楼处

适用于客户需要完整销售转化体系的情况。

页面可根据销售需要包含：

- 项目主视觉
- 3D 大楼
- 虚拟样板间
- 眺望集
- 户型图
- 住户表
- 面积 / 价格 / 房源状态
- 项目卖点
- 资料集
- 周边地图
- 预约看房
- 客户行为数据

## 十一、销售演示方案组合逻辑

HOMEVISTA 模块化后，不只是“客户买什么就显示什么”，还应该支持销售人员根据不同讲解对象，把项目里的销售信息资产重新组合成不同讲解路径。

可以把它理解成：

```text
销售信息资产 = PPT 页面素材
讲解路径 = PPT 演示顺序
销售人员 = 根据客户对象选择不同讲法
```

这里说的“演示方案”不是自动播放，而是在系统里把功能和内容按客群、销售阶段和讲解目的提前分类。

最合理的结构不是按功能优先，也不是只按销售阶段优先，而是三层：

```text
第一层：客户是谁
第二层：客户现在处在哪个决策阶段
第三层：这次要组合哪些资讯来讲
```

也就是说，销售人员进入系统后，不是先面对一个全部功能菜单，也不是只选择“户型演示 / 样板间演示 / 楼层演示”这类功能分类，而是先判断当前客户属于哪类客群，再选择客户当前所处阶段，系统再推荐相应演示方案。

### 1. 演示方案的三层结构

| 层级 | 作用 | 示例 |
|---|---|---|
| 第一层：客群类型 | 决定讲解角度 | 首次置业、预算敏感、改善型、家庭居住、投资、高净值、远程客户、犹豫比较客户 |
| 第二层：决策阶段 | 决定讲解深度 | 初次了解、兴趣判断、深度看房、房源比较、预约转化 |
| 第三层：资讯组合 | 决定具体页面内容 | 3D 大楼、户型图、虚拟样板间、眺望集、价格、住户表、资料、预约 |

推荐入口逻辑：

```text
选择客户类型
→ 选择当前销售阶段
→ 系统推荐演示方案
→ 销售可调整资讯顺序
→ 开始讲解
```

### 2. 按客群类型组织演示方案

| 客群类型 | 客户特点 | 演示重点 | 推荐资讯组合 |
|---|---|---|---|
| 首次置业客户 | 第一次买房，缺少判断标准 | 项目基础信息、户型适配、预算可行性 | 项目总览 → 户型范围 → 价格预算 → 样板间 |
| 预算敏感客户 | 对总价、首付、月供敏感 | 可负担房源、价格差异、贷款测算 | 价格区间 → 可售房源 → 贷款计算 → 推荐房源 |
| 改善型客户 | 已有居住经验，重视品质和空间 | 户型升级、空间尺度、景观、生活品质 | 户型比较 → 样板间 → 眺望集 → 公共区域 |
| 家庭居住客户 | 关注孩子、老人、通勤、配套 | 房间数量、动线、收纳、学校、生活配套 | 户型图 → 样板间 → 区位配套 → 生活方式 |
| 投资型客户 | 关注保值、出租、转售、区位 | 区位价值、价格、流动性、房源性价比 | 区位 → 价格对比 → 房源比较 → 资料集 |
| 高净值客户 | 关注稀缺性、景观、品质、身份感 | 景观、楼层、私密性、装修品质、项目形象 | 3D 大楼 → 高层眺望 → 样板间 → 推荐房源 |
| 远程客户 | 无法到场，需要快速建立信任 | 项目整体、空间体验、资料完整性 | 项目总览 → 3D 大楼 → 虚拟样板间 → 资料集 |
| 犹豫比较客户 | 已看过多个选择，需要决策依据 | 户型、楼层、价格、景观横向比较 | 户型比较 → 房源比较 → 眺望比较 → 推荐理由 |
| 管理 / 合作方 | 不是买房客户，关注销售表现 | 客户行为、关注内容、转化情况 | 访问数据 → 热门户型 → 预约记录 → 销售复盘 |

### 3. 客群与阶段组合示例

同一个客群在不同阶段，也需要不同讲法。

| 客群类型 | 初次了解 | 深度看房 | 房源比较 | 预约转化 |
|---|---|---|---|---|
| 改善型客户 | 项目品质、区位、整体形象 | 户型升级、样板间、公共区域 | 楼层、景观、价格差异 | 推荐房源、预约看房 |
| 预算敏感客户 | 项目基础信息、价格区间 | 可选户型、面积段、月供测算 | 可售房源、总价比较 | 贷款计算、联系销售 |
| 家庭居住客户 | 区位、学校、生活配套 | 户型动线、收纳、样板间 | 房间数量、楼层、通勤便利 | 资料集、预约到访 |
| 高净值客户 | 项目形象、稀缺性 | 高层眺望、装修品质、私密性 | 景观、楼层、核心房源 | 专属预约、销售跟进 |

这个结构对 UI 很重要：销售演示入口不应只是一排功能按钮，而应允许销售先按“客户类型 + 销售阶段”选择演示方案。

### 4. 为什么需要演示方案组合

房地产销售讲解不是固定顺序。不同客户关注点不同，销售人员的讲法也不同。

| 客户对象 | 关注重点 | 推荐讲解路径 |
|---|---|---|
| 首次了解项目的客户 | 项目整体形象、建筑气质、基本信息 | 3D 大楼 → 效果图 → 周边地图 → 预约 |
| 已经有购买意向的客户 | 户型、面积、室内空间、生活动线 | 户型图 → 虚拟样板间 → 眺望集 → 联系销售 |
| 关注景观和楼层价值的客户 | 楼层差异、朝向、视野、景观价值 | 3D 大楼 → 眺望集 → 住户表 → 户型图 |
| 远程客户 | 快速理解项目，不方便到访 | 3D 大楼 → 虚拟样板间 → 资料集 → 预约视频沟通 |
| 投资或管理层客户 | 销售效率、客户访问数据、转化情况 | 项目展示 → 住户表 → 客户行为数据 → 销售跟进 |
| 对价格敏感的客户 | 面积、总价、月供、可选房源 | 户型筛选 → 价格面积 → 贷款计算 → 预约 |
| 重视生活环境的客户 | 区位、配套、通勤、生活方式 | 周边地图 → 配套说明 → 公共区域 → 样板间 |

### 5. 完整系统可以拆成多个演示子方案，并支持叠加组合

当客户购买完整 HOMEVISTA 系统后，可以按不同用途拆成多套演示子方案。这里列出的“项目形象版、楼层视野版、生活方式版”等不是固定套餐，只是示例。

实际使用时，这些演示子方案可以单独使用，也可以叠加组合。

例如：

```text
项目形象版 + 楼层视野版：
适合给关注项目整体形象和景观价值的客户讲解。

户型看房版 + 价格推荐版：
适合给已经有预算和户型偏好的客户做推荐。

生活方式版 + 样板间体验：
适合给家庭居住或改善型客户建立居住想象。

项目形象版 + 管理汇报版：
适合给开发商管理层或合作方汇报展示成果。
```

```mermaid
flowchart LR
    A["完整 HOMEVISTA 系统"] --> B["项目形象版（示例）"]
    A --> C["户型看房版（示例）"]
    A --> D["楼层视野版（示例）"]
    A --> E["销售跟进版（示例）"]
    A --> F["管理汇报版（示例）"]
    A --> G["生活方式版（示例）"]
    A --> H["价格推荐版（示例）"]

    B --> B1["3D 大楼 / 效果图 / 周边地图"]
    C --> C1["户型图 / 虚拟样板间 / 资料集"]
    D --> D1["眺望集 / 楼层 / 住户表"]
    E --> E1["客户关注点 / 预约 / 联系销售"]
    F --> F1["访问数据 / 销售线索 / 转化情况"]
    G --> G1["区位 / 配套 / 公共区域 / 生活方式"]
    H --> H1["预算 / 面积 / 价格 / 月供 / 推荐房源"]

    B -.可叠加.-> D
    C -.可叠加.-> H
    G -.可叠加.-> C
    B -.可叠加.-> F
```

产品和 UI 在设计时，不应把这些方案理解成互斥选项。更合理的方式是：

```text
演示子方案 = 可复用的讲解片段
完整演示方案 = 一个或多个演示子方案组合后的结果
```

### 6. 销售可以按熟悉程度编排

销售人员不一定每次都按照系统菜单讲解，可以根据自己熟悉的讲法形成固定讲解顺序。

```text
销售 A 的讲法：
先讲建筑外观
再讲样板间
最后讲户型和预约

销售 B 的讲法：
先问客户预算和家庭结构
再进入户型图
再进入样板间和眺望集

销售 C 的讲法：
先用眺望集制造价值差异
再进入住户表推荐具体房源
最后进入样板间加强购买想象
```

因此，HOMEVISTA 应支持把项目资讯保存成不同“讲解组合”。

### 7. 推荐预设讲解路径

第一阶段可以先定义几套默认讲解路径，方便销售直接使用。

| 讲解路径 | 适用场景 | 模块顺序 |
|---|---|---|
| 项目初识路径 | 第一次介绍项目 | 项目主视觉 → 3D 大楼 → 效果图 → 周边地图 → 联系销售 |
| 看房体验路径 | 客户想看空间 | 户型图 → 虚拟样板间 → 公共区域 → 资料集 |
| 楼层价值路径 | 客户关注景观和楼层 | 3D 大楼 → 眺望集 → 住户表 → 户型图 |
| 销售推荐路径 | 销售要推荐具体房源 | 客户需求 → 住户表 → 户型图 → 样板间 → 预约 |
| 管理汇报路径 | 给开发商或管理层汇报 | 项目展示 → 模块使用情况 → 客户访问数据 → 销售跟进 |
| 生活方式路径 | 客户关注居住环境 | 区位 → 周边配套 → 公共区域 → 样板间 → 预约 |
| 预算筛选路径 | 客户先看预算可行性 | 预算范围 → 面积价格 → 贷款计算 → 可选房源 → 联系销售 |

### 8. 产品表达

这项能力可以对内命名为：

**销售讲解路径编排**

对外可以表达为：

**像制作 PPT 一样，自由组合卖房所需资讯，为不同客户生成不同看房路径。**

## 十二、销售表达方式

不建议这样说：

```text
我们有一套完整 HOMEVISTA 系统，里面有很多功能。
```

建议这样说：

```text
HOMEVISTA 可以根据项目销售阶段和客户预算，组合成不同的数字展示方案。
客户可以只购买一个模块，也可以逐步扩展成完整线上售楼处。
```

更完整的表达：

```text
HOMEVISTA 是一套模块化数字展示产品。
客户可以根据项目需求选择 3D 大楼、虚拟样板间、眺望集、户型图、住户表、价格面积、周边配套、预约转化等资讯资产。
系统最终会为每个项目生成一个定制化线上展示链接，用于客户远程看房、销售人员讲解和后续预约转化。
```

## 十三、产品改造后的价值

| 价值对象 | 改造价值 |
|---|---|
| 客户 | 可以按预算和阶段购买，不必一次购买完整系统，也能通过比较页面更快做选择 |
| 销售团队 | 更容易报价、演示和解释产品，也可以按客户对象自由编排讲解路径和推荐逻辑 |
| 产品团队 | 可以按信息资产逐步优化，不必所有功能一起推进 |
| 交付团队 | 可以按信息资产组织交付范围和资源 |
| HOMEVISTA 品牌 | 从单一演示系统升级为可组合的数字展示产品 |

## 十四、阶段划分

这里的阶段不应依据开发顺序划分。开发阶段对内部排期有用，但对产品方案和销售表达意义有限。

HOMEVISTA 的阶段应该依据**地产商卖房过程中的客户决策路径**来划分。也就是说，客户在买房过程中会经历哪些理解和决策步骤，HOMEVISTA 就在每个步骤中组合不同资讯，帮助销售讲清楚项目价值。

```text
不是按开发阶段分：
先做 A 功能
再做 B 功能
最后做 C 功能

而是按卖房阶段分：
客户先认识项目
再判断是否适合自己
再深入看房
再比较具体房源
最后预约、成交或继续跟进
```

### 1. 按客户决策路径划分阶段

| 阶段 | 客户状态 | 销售目标 | HOMEVISTA 应组合的资讯 |
|---|---|---|---|
| 第一阶段：项目认知 | 客户刚知道这个项目 | 让客户快速形成第一印象 | 项目主视觉、3D 大楼、效果图、项目卖点、区位概览 |
| 第二阶段：兴趣判断 | 客户开始判断是否值得继续看 | 让客户知道项目是否符合自己的基本需求 | 户型范围、面积段、价格区间、区位、交通、生活配套 |
| 第三阶段：深度看房 | 客户开始认真看空间和居住体验 | 让客户理解房子本身和未来生活感 | 虚拟样板间、户型图、公共区域、装修风格、生活方式说明 |
| 第四阶段：房源比较 | 客户在比较楼层、户型、价格、景观和空间体验 | 帮客户选出更适合的具体房源 | 户型比较、样板间比较、住户表、楼层平面、眺望集、价格面积、房源状态、朝向景观 |
| 第五阶段：预约转化 | 客户已有明确兴趣 | 推动客户预约、咨询、到访或索取资料 | 预约入口、资料集、销售联系方式、贷款计算、推荐房源 |
| 第六阶段：跟进复盘 | 客户看过内容但未立即成交 | 帮销售判断客户关注点并继续跟进 | 访问记录、关注户型、停留内容、预约记录、销售备注 |

这个阶段划分的重点不是要求团队按阶段开发，而是帮助产品和销售理解：

**不同卖房阶段，需要组合不同资讯；HOMEVISTA 应该支持这些资讯被自由组织成不同展示路径。**

### 2. 阶段与信息组合关系

```mermaid
flowchart TD
    A["第一阶段：项目认知"] --> B["第二阶段：兴趣判断"]
    B --> C["第三阶段：深度看房"]
    C --> D["第四阶段：房源比较"]
    D --> E["第五阶段：预约转化"]
    E --> F["第六阶段：跟进复盘"]

    A --> A1["项目主视觉 / 3D 大楼 / 效果图 / 项目卖点"]
    B --> B1["户型范围 / 面积段 / 价格区间 / 区位配套"]
    C --> C1["虚拟样板间 / 户型图 / 公共区域 / 装修风格"]
    D --> D1["户型比较 / 样板间比较 / 眺望对比 / 房源状态"]
    E --> E1["预约入口 / 资料集 / 联系销售 / 贷款计算"]
    F --> F1["访问记录 / 关注户型 / 停留内容 / 销售备注"]
```

### 3. 每个阶段可以形成独立讲解路径

HOMEVISTA 不需要让销售每次都从完整系统首页开始讲。销售可以根据客户所在阶段，直接选择对应讲解路径。

| 讲解路径 | 适合客户 | 讲解顺序 |
|---|---|---|
| 项目认知路径 | 第一次了解项目的客户 | 项目主视觉 → 3D 大楼 → 效果图 → 区位概览 → 项目卖点 |
| 兴趣判断路径 | 想快速判断是否适合自己的客户 | 面积段 → 价格区间 → 户型范围 → 交通配套 → 生活方式 |
| 深度看房路径 | 已经愿意认真看房的客户 | 户型图 → 虚拟样板间 → 公共区域 → 装修风格 → 眺望集 |
| 房源比较路径 | 正在比较具体房源的客户 | 户型比较 → 样板间比较 → 楼层视野比较 → 价格面积 → 推荐房源 |
| 预约转化路径 | 已有意向、需要推进下一步的客户 | 推荐房源 → 资料集 → 贷款计算 → 预约入口 → 联系销售 |
| 跟进复盘路径 | 销售或管理者复盘客户行为 | 访问记录 → 关注户型 → 停留内容 → 预约记录 → 跟进建议 |

### 4. 阶段划分对产品的意义

这个阶段划分的意义不在于规定开发顺序，而在于定义 HOMEVISTA 的产品逻辑：

- HOMEVISTA 不是固定菜单，而是卖房资讯的组合系统。
- 不同客户阶段，对应不同资讯组合。
- 同一套项目资料，可以生成多条看房路径。
- 比较页面应成为深度看房和房源推荐阶段的重要能力。
- 销售可以像 PPT 演示一样，根据客户状态切换讲解路径。
- 客户也可以通过不同入口进入适合自己的展示内容。

因此，阶段划分应该服务于**销售过程和客户决策**，而不是服务于开发排期。

## 十五、部门协作说明

为了让产品部、技术部和 UI 设计可以基于同一份方案继续推进，需要把各部门关注点分开。

### 1. 产品部输出重点

产品部需要把概念进一步整理成产品规则。

建议输出：

| 输出物 | 内容 |
|---|---|
| 销售信息资产清单 | 明确哪些内容可以作为资产被展示、组合、比较 |
| 资产分类规则 | 建筑展示、空间体验、房源信息、对比决策、项目价值、销售辅助、数据运营 |
| 组合规则 | 哪些资产可以组合，哪些组合适合什么客户阶段 |
| 比较页面规则 | 户型比较、样板间比较、眺望比较、房源比较分别比较什么 |
| 演示方案规则 | 按客群类型、客户决策阶段和资讯组合定义默认演示方案 |
| 销售话术说明 | 每类路径适合销售怎么讲 |
| 数据记录范围 | 哪些浏览、点击、比较、预约行为需要记录 |

产品部最重要的判断是：

```text
这个内容是否能帮助客户理解项目？
这个内容是否能帮助客户比较选择？
这个内容是否能帮助销售推进下一步？
```

### 2. 技术部理解重点

技术部不需要把这个方案理解成“增加很多页面”，而应理解成产品结构变化。

核心变化是：

```text
固定页面系统
变成
资产 + 组合 + 路径 + 比较 + 转化 + 数据
```

技术部需要重点关注：

| 方向 | 说明 |
|---|---|
| 资产化 | 项目内容需要可以被单独识别和调用 |
| 组合化 | 不同资产可以组成不同项目展示方案 |
| 路径化 | 同一组资产可以按不同客群和销售场景形成不同讲解顺序 |
| 比较化 | 多个资产可以并列展示，形成比较页面 |
| 权限化 | 客户购买什么、项目开放什么，就展示什么 |
| 数据化 | 客户浏览、比较、跳转、预约等行为可以记录 |

第一阶段技术理解可以保持简单：

```text
先支持人工选择资产
人工组成展示组合
人工保存讲解路径
人工配置比较页面
不急于做自动推荐和复杂算法
```

### 3. UI 设计输出重点

UI 设计要把“自由组合”做得清楚，而不是让页面变成很多按钮堆叠。

建议优先设计以下页面类型：

| 页面类型 | UI 要解决的问题 |
|---|---|
| 项目入口页 | 客户进入后知道这是哪个项目、可以看什么 |
| 单资产展示页 | 单独购买一个资产时也像完整产品 |
| 组合展示页 | 多个资产入口清楚，不像杂乱菜单 |
| 演示方案选择页 | 销售可以先选择客户类型和销售阶段，再进入对应讲解路径 |
| 户型比较页 | 客户能看懂不同户型差异 |
| 样板间比较页 | 客户能比较空间感、装修、生活场景 |
| 眺望比较页 | 客户能理解楼层、朝向、景观差异 |
| 房源综合比较页 | 销售能解释为什么推荐某几套房 |
| 预约转化页 | 客户看完后知道下一步怎么联系或预约 |

UI 的关键原则：

- 不把所有内容一次性堆出来。
- 每个页面只解决一个主要问题。
- 比较页面要突出差异，而不是只摆数据。
- 讲解路径要有明显进度和上下步关系。
- 销售入口和客户入口可以不同。
- 移动端要考虑客户通过分享链接直接打开。
- 完整系统的 UI 不能只有“全部功能菜单”，还要有“选择客户类型 / 销售阶段 / 演示方案”的入口。
- 路径演示状态下，UI 应弱化杂乱功能入口，强化当前讲解顺序。
- 路径结束时要给销售一个自然转化动作，而不是让客户停在最后一页。

### 4. 三方对齐口径

产品部、技术部和 UI 设计应围绕同一个核心口径推进：

```text
HOMEVISTA 不是固定菜单系统。

它是地产销售资讯的组织系统。

项目内容可以被资产化，
资产可以被组合，
组合可以形成讲解路径，
多个资产可以进入比较页面，
最终服务于客户理解、销售推荐和预约转化。
```

## 十六、产品需求补充：角色、场景、页面与第一版范围

为了让产品部可以继续拆需求、UI 可以开始画页面、技术部可以评估范围，还需要把产品概念进一步落到角色、场景、页面和第一版改造范围上。

这一章不是技术方案，而是把“谁用、什么时候用、看什么页面、完成什么动作”说清楚。

### 1. 典型用户角色

HOMEVISTA 模块化后，不同角色使用系统的目的不同，看到的内容和操作方式也不同。

| 角色 | 使用目的 | 关注重点 |
|---|---|---|
| 购房客户 | 远程了解项目、比较房源、预约看房 | 项目是否适合自己、户型差异、价格、视野、样板间、下一步预约 |
| 销售人员 | 给客户讲解项目、推荐房源、推进转化 | 快速选择讲解路径、比较房源、解释推荐理由、引导预约 |
| 销售经理 | 管理销售过程、复盘客户关注点 | 哪些内容被看、客户关注哪些户型、哪些路径有效 |
| 开发商管理层 | 判断项目展示和销售转化效果 | 项目展示完整度、客户访问数据、销售线索、转化趋势 |
| HOMEVISTA 交付人员 | 根据客户购买内容准备展示资产 | 资产清单、交付范围、哪些内容需要上线 |
| HOMEVISTA 配置人员 | 将项目内容组合成展示链接和讲解路径 | 资产启用、路径配置、比较页面配置、权限范围 |

### 2. 典型使用场景

产品和 UI 不能只围绕功能画页面，要围绕真实销售场景来设计。

| 场景 | 使用者 | 目标 | 需要的页面或能力 |
|---|---|---|---|
| 第一次介绍项目 | 销售人员、购房客户 | 快速建立项目第一印象 | 项目入口页、项目认知路径、3D 大楼、区位配套 |
| 客户只想看虚拟样板间 | 购房客户 | 直接进入室内体验 | 单资产展示页、户型选择、样板间入口 |
| 客户比较 2-3 个户型 | 销售人员、购房客户 | 看懂户型差异并形成偏好 | 户型比较页、样板间跳转、推荐理由 |
| 客户在几套房之间犹豫 | 销售人员 | 解释为什么推荐某几套房 | 房源综合比较页、价格面积、眺望、房源状态 |
| 客户关注景观和楼层 | 销售人员、购房客户 | 看懂楼层和视野价值差异 | 眺望比较页、楼层平面、价格差异 |
| 客户预算敏感 | 销售人员 | 帮客户筛选可负担房源 | 预算筛选路径、价格面积、贷款计算、推荐房源 |
| 客户看完后需要推进 | 销售人员、购房客户 | 预约、咨询、索取资料 | 预约转化页、资料集、联系销售 |
| 销售经理复盘 | 销售经理 | 看客户关注什么，指导跟进 | 客户行为记录页、关注户型、停留内容、预约记录 |

### 3. 角色与流程关系图

```mermaid
flowchart TD
    A["购房客户"] --> B["打开项目展示链接"]
    B --> C{"客户当前需求"}

    C --> C1["先了解项目"]
    C --> C2["看户型和样板间"]
    C --> C3["比较房源"]
    C --> C4["预约或咨询"]

    C1 --> D1["项目认知路径"]
    C2 --> D2["深度看房路径"]
    C3 --> D3["房源比较路径"]
    C4 --> D4["预约转化页"]

    E["销售人员"] --> F["选择客户类型"]
    F --> F1["选择销售阶段"]
    F1 --> F2["系统推荐演示方案"]
    F2 --> D1
    F2 --> D2
    F2 --> D3
    F2 --> D4

    G["销售经理 / 开发商管理层"] --> H["查看客户行为与转化结果"]
    D1 --> H
    D2 --> H
    D3 --> H
    D4 --> H
```

### 4. 页面清单

以下页面清单用于产品拆需求和 UI 设计，不代表第一版必须全部完成。

| 页面 | 主要使用者 | 页面目的 |
|---|---|---|
| 项目入口页 | 购房客户、销售人员 | 进入项目后知道可以看什么 |
| 演示方案选择页 | 销售人员 | 先选择客户类型和销售阶段，再进入适合当前客户的讲解路径 |
| 路径演示页 | 销售人员、购房客户 | 像 PPT 一样按顺序讲解 |
| 单资产展示页 | 购房客户 | 单独购买一个资产时也能形成完整体验 |
| 组合展示页 | 购房客户、销售人员 | 展示已购买或已启用的多个资产 |
| 户型比较页 | 购房客户、销售人员 | 比较 2-3 个户型差异 |
| 样板间比较页 | 购房客户、销售人员 | 比较空间体验、装修风格、生活场景 |
| 眺望比较页 | 购房客户、销售人员 | 比较楼层、朝向、视野、景观价值 |
| 房源综合比较页 | 销售人员、购房客户 | 对比具体房源并说明推荐理由 |
| 预约转化页 | 购房客户 | 预约看房、联系销售、下载资料 |
| 客户行为记录页 | 销售人员、销售经理 | 查看客户看过什么、关注什么 |
| 项目资产配置页 | HOMEVISTA 配置人员 | 配置项目启用哪些资产 |
| 演示方案配置页 | HOMEVISTA 配置人员、销售人员 | 按客群类型、销售阶段和资讯组合保存不同演示方案 |
| 比较页面配置页 | HOMEVISTA 配置人员、销售人员 | 选择比较对象和推荐说明 |

### 5. 第一版评估与改造范围

这里的“第一版”不能简单理解为从零开发，也不能预设一定只是在现有系统上小改。

根据当前 demo 情况，HOMEVISTA 已经具备较完整的前台展示、后台管理和客户行为分析基础。但现有系统是否能支撑“模块化、路径化、比较化”的新产品目标，还需要先做评估。

因此，第一版更准确应定义为：

**基于现有完整系统，评估并验证模块化、路径化、比较化的产品改造方式；如果现有结构无法承接，则需要局部重做或重新规划。**

也就是说，第一版不是简单补齐基础功能，也不是直接推翻现有系统，而是先判断现有系统能否被重新组织成更符合销售使用习惯的产品形态。

### 6. 改造或重做的判断方式

实施方式应根据评估结果决定，不应在产品方案阶段提前写死。

| 评估结果 | 处理方式 | 说明 |
|---|---|---|
| 现有系统可以承接 | 以改造为主 | 复用现有前台、后台、分析系统，增加路径、比较和展示组合能力 |
| 展示层限制较大 | 前台展示层局部重做 | 后台和数据尽量复用，重点重做项目入口、路径演示、比较页面等前台体验 |
| 后台配置方式不支持 | 后台配置能力需要调整 | 如果现有后台无法支持资产启用、组合、路径配置，需要补充或重做相关配置能力 |
| 数据结构无法支持 | 数据结构需重新规划 | 如果现有内容不是资产化组织，无法支持路径和比较，需要重新规划资产关系 |
| 分析系统无法承接 | 分析埋点与报表需调整 | 如果现有分析只记录页面访问，无法记录路径、比较、转化，需要扩展分析维度 |

判断重点：

```text
目标是确定的：
模块化、路径化、比较化、销售资讯资产化。

实施方式不预设：
可以改造，可以局部重做，也可能需要重构部分前后台结构。
```

第一版建议重点评估并验证以下能力：

| 范围 | 说明 |
|---|---|
| 现有资产重新组织 | 将 demo 中已有的 3D 大楼、虚拟样板间、眺望集、户型、住户表、资料、预约等内容重新定义为销售信息资产 |
| 模块化展示入口 | 支持按客户购买内容或展示目的，只显示相关资产，不再默认进入完整大菜单 |
| 演示方案选择 | 在完整系统基础上增加“客户类型 + 销售阶段 + 推荐讲解路径”的演示方案入口 |
| 路径演示体验 | 路径内支持上一步、下一步、当前进度和路径结束动作 |
| 比较页面增强 | 在户型、虚拟样板间、眺望、房源之间增加更多比较页面 |
| 房源综合比较 | 支持 2-3 个房源并列展示，并允许销售说明推荐理由 |
| 预约转化衔接 | 路径或比较页最后可以进入预约、联系销售或资料下载 |
| 行为分析承接 | 现有分析系统应能识别客户看过哪条路径、比较过哪些对象、停留在哪些内容 |

第一版不是不做后台和分析，也不是一定不重做后台和分析，而是先判断现有后台和分析系统能否承接新的产品结构。

第一版应优先评估现有后台和分析能力，重点判断：

- 现有内容是否能被重新组织为销售信息资产。
- 现有后台是否能支持项目展示内容启用、隐藏和组合。
- 现有分析系统是否能记录路径浏览、比较行为和转化动作。
- UI 是否能把完整系统拆成不同客群和阶段下的演示方案。
- 销售是否真的愿意按客群和阶段选择演示方案，而不是回到原来的固定菜单。

第一版不建议一开始就追求：

- 所有比较页面都自动生成。
- 所有演示方案都完全自由编辑。
- 自动根据客户行为生成推荐房源。
- 所有资产类型一次性完成路径化和比较化。
 
但如果评估发现现有前台、后台或分析系统无法承接核心目标，则应允许局部重做或重新规划。

第一版的目标是验证：

```text
现有完整系统能否被重新组织成多套面向客群的演示方案？
客户能否按演示方案看懂项目？
销售能否按客群和阶段讲清楚项目？
比较页能否帮助客户做选择？
演示方案和比较行为能否被现有分析系统记录？
演示方案最后能否自然进入预约或联系销售？
```

### 7. 页面输入与输出

页面不是静态展示，每个页面都应有输入、展示内容和下一步动作。

| 页面 | 输入 | 输出 / 下一步 |
|---|---|---|
| 项目入口页 | 项目名称、主视觉、启用资产 | 进入演示方案选择、进入默认展示、联系销售 |
| 演示方案选择页 | 客户类型、销售阶段、已配置演示方案 | 进入某一条讲解路径 |
| 路径演示页 | 路径内资产顺序 | 上一步、下一步、跳转资产、进入比较页、预约 |
| 单资产展示页 | 单个展示资产 | 查看详情、分享、联系销售、进入关联资产 |
| 户型比较页 | 户型 A/B/C、面积、价格、户型图、推荐理由 | 选择户型、进入样板间、预约 |
| 样板间比较页 | 样板间 A/B、风格、户型、空间说明 | 查看样板间、选择偏好、联系销售 |
| 眺望比较页 | 楼层、朝向、眺望图、价格差异 | 选择楼层、查看房源、进入房源比较 |
| 房源综合比较页 | 房源 A/B/C、户型、面积、价格、状态、眺望 | 推荐房源、预约、联系销售 |
| 预约转化页 | 推荐房源、客户意向、联系方式入口 | 提交预约、联系销售、下载资料 |
| 客户行为记录页 | 客户浏览、点击、比较、预约行为 | 销售跟进建议、客户偏好判断 |

### 8. 第一版评估与改造流程图

```mermaid
flowchart TD
    A["现有完整 HOMEVISTA 系统"] --> B["评估现有前台 / 后台 / 分析系统"]
    B --> C{"能否支撑模块化 / 路径化 / 比较化？"}

    C -->|"可以承接"| D["以现有系统改造为主"]
    C -->|"展示层限制大"| E["前台展示层局部重做"]
    C -->|"后台或数据不支持"| F["后台配置 / 数据结构重新规划"]

    D --> G["梳理销售信息资产"]
    E --> G
    F --> G

    G --> H["资产重新组合"]
    H --> I["客群 / 阶段 / 演示方案选择"]
    H --> J["比较页面"]
    I --> K["预约转化"]
    J --> K

    K --> L["分析系统记录路径 / 比较 / 转化行为"]
```

### 9. 验收标准

第一版做到以下程度，就可以认为产品逻辑被初步验证：

| 验收项 | 标准 |
|---|---|
| 现有资产梳理 | demo 中已有内容可以被归类为销售信息资产 |
| 单资产体验 | 只启用一个资产时，页面仍然完整，不出现无关菜单 |
| 演示方案入口 | 销售可以按客户类型和销售阶段选择至少 2 条不同演示方案 |
| 路径演示 | 讲解路径支持上一步、下一步和当前进度提示 |
| 路径内容 | 每条路径至少包含 3 个展示节点 |
| 比较页面 | 可以同时比较 2-3 个对象 |
| 比较跳转 | 客户可以从比较页进入具体户型、样板间或预约页 |
| 转化动作 | 路径结束或比较结束后，有明确联系销售或预约动作 |
| 未购买内容隐藏 | 未启用或未购买的资产不出现在客户展示入口中 |
| 分析记录 | 至少能记录客户进入了哪条路径、查看了哪些比较页面、是否进入预约 |
| UI 清晰度 | 客户能知道当前在看什么、为什么比较、下一步做什么 |

## 十七、最终目标

HOMEVISTA 的产品变化不是简单隐藏几个功能，而是从固定系统变成可组合、可演示、可比较、可按销售场景重新编排的产品。它组合的不只是几个视觉模块，而是地产商卖房过程中需要使用的各类资讯。

最终应形成这样的产品认知：

```text
HOMEVISTA 不是一个必须整体购买的大系统。

它是一套面向房地产销售场景的模块化数字展示套件。

客户可以从一个模块开始购买，
也可以随着项目销售阶段推进，
逐步扩展成完整线上售楼处。

销售可以像制作 PPT 一样，
把项目资讯重新组合成不同讲解路径，
用于不同客户、不同场景和不同销售话术。
```