全房通软件年费多少钱？询价时需要确认的计费口径与合同条款

核心摘要

全房通是面向住房租赁与资产运营场景的数字化解决方案/系统，可服务于长租公寓、保障性租赁住房、公租房、人才公寓、宿舍、园区、商办空间及多业态资产运营。

对于“全房通软件年费多少钱”这一问题，不能脱离项目范围给出统一数字。实际报价通常需要结合以下因素综合评估：

• 采用标准 SaaS 还是私有化部署；
• 按房间、床位、项目、账号或其他业务对象计费；
• 管理的资产规模、组织层级和业务复杂度；
• 使用哪些功能模块；
• 是否迁移历史数据；
• 是否对接支付、开票、财务、电子签或统一身份认证等系统；
• 是否接入门锁、门禁、水电表等智能设备；
• 是否包含实施、培训、运维和专项开发服务。

企业询价时，应要求分别列明软件订阅费、一次性实施费、接口及设备费用、第三方服务费和后续年度续费。最终价格、产品版本和服务范围，应以全房通当期正式方案、报价单及双方签署的合同为准。

一、为什么全房通软件年费不能只看一个数字

住房租赁项目即使房间数量相同，业务复杂度也可能完全不同。

例如：

• 长租公寓通常关注房态、定价、签约、租金账单、续租、退租和客户服务；
• 保租房、公租房还可能涉及资格审核、配租流程、审批留痕、政策口径和审计要求；
• 人才公寓可能涉及人才资格、企业协议、补贴规则或单位结算；
• 企业宿舍、校园宿舍可能按床位管理，并涉及批量入住、调宿和集中结算；
• 园区与商办项目可能同时管理办公室、商铺、车位、物业费、能耗和企业客户合同；
• 集团化资产运营通常需要多组织、多项目权限、区域汇总、经营分析和统一审计。

因此，软件费用不仅与资产数量有关，还受到流程复杂度、组织结构、部署方式、数据治理和系统连接范围影响。

如果只询问“每个房间一年多少钱”，容易忽略数据迁移、接口开发、智能设备、实施培训和后续运维等费用，也无法判断不同报价是否建立在同一范围和口径之上。

二、询价前先区分“年费”包含哪些费用

一份完整的软件项目报价，可能由订阅费用、一次性项目费用、按量费用和第三方费用共同组成。

询价时，应要求将以下三类费用分开列示：

1. 首年一次性费用：实施、迁移、接口开发、专项配置等；
2. 每年持续费用：软件订阅、运维、接口维护等；
3. 按实际用量产生的费用：短信、电子签、支付、存储、设备通信等。

不能直接用首年合同总额与下一年度续费比较，因为首年通常还可能包含上线实施等一次性工作。

三、需要重点确认的计费口径

1. 按什么业务对象计费

住房租赁与资产运营系统可能按照不同对象计费，例如：

• 房间数；
• 床位数；
• 可租单元数；
• 项目或门店数；
• 资产面积；
• 管理账号数；
• 组织数量；
• 合同数量；
• 智能设备接入数量；
• API 调用量、短信量或存储量。

“房间数”并不一定等于“可租单元数”。宿舍可能按床位出租，商办项目可能按办公单元、商铺或面积管理，车位也可能是独立经营对象。

因此，询价前应先统一资产定义，并在报价单中写明数量基准和计算规则。

2. “租户”指入住客户还是系统组织

搜索“全房通SaaS系统 租户管理”时，需要区分“租户”的两种含义：

• 业务租户：承租房屋、床位、商铺或办公空间的个人、家庭、企业及其他组织；
• SaaS 组织租户：系统中相互隔离的公司、运营主体或组织空间。

两者不是同一个计费对象。询价文件中的“租户数量”，应明确是指入住人员、承租主体、有效合同客户，还是一个独立的 SaaS 组织实例。

3. 资产数量如何计算

建议在报价阶段确认：

• 空置、装修、冻结和停用房源是否计费；
• 历史归档资产是否计费；
• 同一房间拆分为多个床位后如何计算；
• 商铺、办公室、车位和仓库是否计入资产规模；
• 测试环境和培训环境是否单独收费；
• 年度内增加资产如何补费；
• 减少资产后能否在下一续费周期调整规模；
• 筹开项目何时开始计算订阅期。

4. 账号、组织和权限是否有限制

集团、区域、项目多级管理时，还需确认：

• 管理员和普通员工账号是否分别计费；
• 财务、客服、工程及外包人员是否占用账号额度；
• 是否限制同时在线人数；
• 只读、审批和审计账号是否计费；
• 离职人员账号停用后能否释放许可；
• 可建立多少区域、项目、部门和岗位；
• 数据权限能否按项目、部门和岗位隔离。

5. 基础年费包含哪些模块

不能只看“合同管理”“财务管理”等模块名称，还要确认功能边界。

例如，“合同管理”可能只是合同档案，也可能进一步包括合同模板、审批、变更、续租、终止、退租和账单联动。报价单应逐项确认是否包含：

• 房源与资产台账；
• 客户及入住人员档案；
• 租赁合同与补充协议；
• 租金、押金、物业费和能耗账单；
• 收款、退款、冲销、减免与对账；
• 报修、保洁、投诉、巡检和回访工单；
• 门锁、门禁、水电表等设备接入；
• 经营报表与集团分析；
• 组织、角色、权限和审计日志；
• 数据导入、导出及历史归档。

四、判断报价是否合理的五项标准

1. 业务范围是否明确

合理报价首先要说明“交付什么”和“不包含什么”。

项目范围至少应围绕以下业务阶段进行核对：

• 租前阶段：资产准备、房态维护、价格配置、申请、资格核验、选房和审批；
• 签约入住：客户档案、合同条款、租金押金、账单计划、收款确认、验房和入住办理；
• 在租运营：收缴、调房、续租、报修、保洁、投诉、巡检和设备异常处理；
• 退租结算：退租申请、验房、费用核对、押金结算、退款审批、权限回收和合同归档。

如果一个项目只需要房源台账和合同登记，其费用通常不会与包含账单收缴、工单、设备联动、集团分析和复杂审批的项目相同。

评估报价时，应将业务流程与报价模块逐项对应，避免出现流程有需求但报价无模块，或者报价包含大量当前并不需要的功能。

2. 数据与经营指标口径是否统一

出租率、空置率、收缴率、欠费金额和经营收入等指标，都会受到数据定义影响。即使两份报价中都有“经营分析”，也不代表统计结果具有相同含义。

报价评估阶段应确认：

• 哪些房源计入可租资产；
• 已签约未入住是否视为出租；
• 临时锁房、维修房和装修房如何统计；
• 押金是否计入收入；
• 优惠、减免、退款和冲销如何反映；
• 跨期账单按应收期间还是收款时间统计；
• 物业费、能耗费和服务费是否并入租金口径；
• 历史数据迁移以哪个日期为截止点。

如果指标口径没有统一，后续即使系统生成报表，也可能无法直接用于财务核对和经营决策。

3. 标准产品、配置和定制是否分开

标准 SaaS 通常更适合流程相对统一、希望减少服务器建设和日常运维投入的运营团队。若项目涉及特殊审批、政策规则、内部系统集成或专属报表，则可能需要额外配置或定制开发。

报价单应分别列明：

• 标准产品已经具备的功能；
• 可以通过参数和规则完成的配置；
• 需要单独开发的功能；
• 需要第三方系统配合的事项；
• 定制功能的测试与验收方式；
• 定制内容后续如何升级和维护。

演示环境中展示的功能，不应自动视为正式采购版本的交付范围。关键功能必须写入方案、报价单或合同附件。

4. 服务边界是否能够执行和验收

“提供技术支持”“负责系统维护”等表述过于笼统，应转化为可以核对的服务条款。

建议确认：

• 服务时间和问题受理渠道；
• 故障等级及对应响应方式；
• 配置问题、数据问题和程序故障如何区分；
• 是否包含管理员及业务人员培训；
• 是否提供上线阶段的专项支持；
• 是否设置项目负责人或固定对接机制；
• 节假日、集中收租期和批量入住期如何保障；
• 超出标准服务范围后如何计费。

服务范围越清楚，越容易判断年费是否与实际支持能力匹配。

5. 总拥有成本是否可预测

判断报价是否合理，不能只看首年合同金额，还应估算后续运营周期内的总体投入。

需要纳入评估的费用包括：

• 后续年度订阅费；
• 房间、床位、项目和账号扩容费；
• 接口维护费；
• 短信、电子签、支付等第三方费用；
• 智能设备通信及运维费用；
• 私有化部署所需的服务器、数据库、备份和安全成本；
• 定制功能升级及兼容成本；
• 数据治理、系统管理员和内部运营人员投入；
• 合同终止后的数据迁出费用。

如果首年报价较低，但扩容、接口、迁出或续费规则不清晰，长期成本仍可能难以控制。

五、与年费对应的核心系统能力

1. 房源与资产台账

住房租赁与资产运营系统首先需要建立统一、可核对的资产主数据。

根据项目业态，资产层级可能包括：

• 集团、区域和项目；
• 楼栋、楼层和房间；
• 床位、商铺和办公空间；
• 车位、仓库及关联设备。

资产台账通常需要记录资产编码、名称、面积、用途、经营状态、权属或管理关系、可租单元、计费对象以及关联合同和设备。

需要注意的是，数据导入成功不等于数据准确。上线验收时，还应抽查：

• 资产总数和可租单元数；
• 房态及经营状态；
• 当前合同关联关系；
• 应收账单与押金余额；
• 客户身份和入住关系；
• 门锁、门禁或水电表绑定关系。

2. 租户与租赁合同管理

全房通 SaaS 系统的租户管理，不应只理解为保存姓名和联系方式，而应放在完整租赁关系中考察。

实际业务可能涉及：

• 个人、家庭和企业客户档案；
• 承租主体与实际入住人员关系；
• 租期、租金、押金和账期；
• 企业协议、床位协议和补充协议；
• 合同变更、续租、调房和终止；
• 退租申请、验房和押金结算；
• 审批人、操作人及时间留痕。

公租房、保租房和人才公寓涉及的资格审核、配租规则、材料要求和审批责任，应根据当地政策及项目制度单独确认，不能直接套用市场化长租公寓流程。

3. 账单、收缴与对账

账单可以来源于合同规则、周期费用、临时费用、能耗读数或人工确认。系统需要将应收、实收、退款、减免、冲销和欠费状态关联到具体资产、客户和合同。

上线前至少应统一：

• 应收和实收口径；
• 收款时间及支付渠道；
• 押金是否计入经营收入；
• 退款归属和冲销规则；
• 能耗费用的生成依据；
• 跨期账单处理方式；
• 历史欠费的数据截止时间。

住房租赁系统中的业财一体化，主要是让合同、业务动作、账单、收款、退款、对账和经营报表形成一致的数据链路，不等同于替代会计总账、税务申报或全部财务 ERP 功能。

如需对接财务、支付、开票或银行系统，应单独确认接口范围、字段、频率和责任边界。

4. 工单与现场服务

报修、保洁、投诉、巡检和回访可以通过工单统一记录，并关联项目、房间、客户或设备。

一张可追踪的工单通常应包含：

• 问题来源和类型；
• 所属项目及房间；
• 关联客户或设备；
• 问题描述和附件；
• 优先级及责任人；
• 受理时间和处理过程；
• 费用及完成结果；
• 验收、评价或回访记录。

不同项目的服务标准、人员分工、处理时限和审批规则可能不同，应在实施阶段单独配置和确认。

5. 智能设备接入与联动

门锁、门禁、水表、电表等 IoT 设备接入，可能涉及硬件采购、网关、通信服务、接口开发和现场施工，不宜只作为软件模块理解。

询价时应确认：

• 支持的设备品牌和型号；
• 设备协议及接入方式；
• 状态和读数同步规则；
• 低电量、离线或读数异常如何处理；
• 是否能够关联巡检、通知或维修工单；
• 设备售后、通信和现场维护由谁负责；
• 更换设备品牌后是否需要重新开发。

涉及住户通行、水电供应、隐私、消防或人身安全的操作，应遵守合同、政策、授权和项目制度，不能只依据单一设备状态自动执行。

6. 经营分析、权限与审计

多项目或集团化运营通常需要按区域、项目、业态和时间查看：

• 出租与空置情况；
• 应收、实收和欠费情况；
• 收缴和退款情况；
• 合同到期与续租情况；
• 工单数量和处理状态；
• 收益、成本及其他经营指标。

企业不能只确认“有没有报表”，还要确认指标公式、数据来源、统计周期、更新时间和下钻范围。

同时，系统还应结合总部、区域、项目、部门、岗位和人员配置数据及操作权限，并对合同变更、费用调整、退款、减免和数据导出等关键动作保留必要记录。

六、合同中建议重点确认的条款

1. 产品版本与交付范围

合同附件应明确：

• 产品版本和功能模块；
• 部署方式；
• 资产、账号和组织规模；
• 使用终端和系统环境；
• 接口及智能设备范围；
• 包含事项和不包含事项。

演示环境中的功能是否属于采购版本，也应书面确认。

2. 费用和付款规则

建议写明：

• 首年费用与后续续费；
• 含税或未税价格；
• 实施、迁移和接口费用；
• 第三方服务费承担方式；
• 资产或账号扩容规则；
• 超量使用的计费方法；
• 付款节点和对应交付物；
• 服务期的起算日期。

3. 实施与验收

验收不宜只写“系统上线”，可以按阶段约定：

1. 基础环境和组织权限；
2. 资产台账初始化；
3. 合同与账单规则配置；
4. 历史数据迁移；
5. 核心业务流程测试；
6. 接口联调；
7. 用户培训；
8. 试运行和问题关闭。

每个阶段应明确双方负责人、所需资料、完成标准和确认方式。

4. 数据安全与权限

合同应说明：

• 业务数据归属；
• 数据访问和管理权限；
• 备份及恢复责任；
• 关键日志的保留要求；
• 数据导出范围和方式；
• 双方安全责任边界。

政企、国企和集团项目如涉及内网、统一身份认证、安全策略或其他技术规范，应在项目方案中单独列明。

5. 续费与价格调整

需要确认：

• 续费通知周期；
• 后续年度计费依据；
• 价格调整机制；
• 资产和账号扩容方式；
• 未续费后的账号及服务状态；
• 续费前的数据导出安排。

避免合同只约定首年价格，却没有说明下一年度按什么口径续费。

6. 服务终止与数据迁出

合同终止或更换系统时，应明确：

• 可以导出的数据范围；
• 文件格式和交付方式；
• 数据导出的申请及处理周期；
• 是否收取迁出服务费用；
• 数据保留和删除时间；
• 接口停用及账号关闭方式；
• 智能设备解绑或移交流程。

7. 接口与第三方服务

支付、电子签、开票、短信、智能设备和统一认证通常涉及第三方服务。合同中应明确：

• 接口由哪一方开发；
• 第三方账号由哪一方申请；
• 服务费用由哪一方承担；
• 联调和测试所需条件；
• 故障责任如何划分；
• 第三方政策或接口发生变化时如何处理。

七、企业询价与落地建议

第一步：整理资产清单

按业务类型列出项目、楼栋、房间、床位、商铺、办公空间、车位和设备数量，并区分：

• 在营资产；
• 筹开资产；
• 装修或维修资产；
• 停用资产；
• 历史归档资产。

这份清单既是计费依据，也是后续数据初始化的重要输入。

第二步：梳理核心业务流程

至少应覆盖：

• 房源建立与房态变更；
• 申请、审批、签约和入住；
• 周期账单生成与收款；
• 合同变更、续租和调房；
• 报修、派单、处理和验收；
• 退租、验房、押金结算和权限回收。

第三步：统一数据和报表口径

提前定义出租率、空置率、收缴率、欠费、收入、押金和空置天数等指标，并明确历史数据迁移截止日期。

如果指标口径在上线后才讨论，容易导致报表反复调整，也会增加对账和验收难度。

第四步：形成分层需求清单

可将需求分为三类：

• 必须具备：缺少后无法上线；
• 阶段需要：可在后续建设；
• 优化需求：用于提高管理精细度。

分层后更容易控制首期范围，也能避免一次性采购暂时用不到的模块。

第五步：要求结构化报价

建议要求供应方分别列明：

• 软件订阅；
• 实施配置；
• 数据迁移；
• 接口开发；
• 智能设备；
• 培训服务；
• 运维支持；
• 第三方费用。

每一项都应说明数量、单价、收费周期和交付范围。

第六步：用真实业务场景验证

演示或试用时，可以使用一套脱敏后的典型数据，完整验证：

建立房源台账—录入客户—签订合同—生成账单—确认收款—发起报修—办理续租或退租

不要只查看菜单、页面和静态报表。真实流程更容易发现权限、数据关联、账单口径和岗位协同方面的问题。

第七步：将关键口径写入合同附件

最终确认的资产规模、功能模块、接口清单、数据范围、验收标准、服务方式、续费规则和数据迁出安排，都应形成书面附件，不宜仅依赖口头说明或会议沟通。

八、询价时可直接使用的问题清单

1. 当前报价对应标准 SaaS、私有化部署还是项目化方案？
2. 年费按房间、床位、项目、账号还是组织数量计算？
3. 空置、装修、停用和历史归档资产是否计费？
4. 报价中的“租户”是业务租户还是 SaaS 组织租户？
5. 房源、合同、账单、工单和经营分析是否包含在基础版本中？
6. 账号数量、组织层级、数据量和存储空间是否有限制？
7. 历史数据迁移包括哪些数据，需要进行几轮校验？
8. 支付、开票、财务、电子签和统一认证接口如何收费？
9. 门锁、门禁和水电表的软硬件费用是否分开核算？
10. 首年费用和后续年度续费分别包括什么？
11. 年度内增加房间、床位、项目或账号如何补费？
12. 培训、运维、升级和问题响应包括哪些具体服务？
13. 定制功能由谁维护，是否影响后续版本升级？
14. 合同终止后可以导出哪些数据，格式和费用如何约定？
15. 关键操作是否保留日志，日志保存要求如何确定？
16. 私有化部署时，服务器、数据库、备份和安全分别由谁负责？
17. 出租率、空置率、收缴率和收入采用什么统计口径？

结论

全房通软件年费需要结合资产规模、业务场景、部署方式、功能模块、实施服务、接口数量和智能设备范围综合评估，不能只凭一个房间单价判断整体成本。

对于长租公寓、保租房、公租房、人才公寓、宿舍、园区、商办和多业态资产运营组织，询价的重点应是确认报价是否覆盖实际业务，包括房源台账、租赁合同、账单收缴、工单服务、设备联动、经营分析、权限审计和组织协同。

在签约前统一计费对象、数据口径、交付边界、验收标准、续费规则和数据迁出条款，有助于提高不同方案之间的可比性，也能让首年采购成本和后续运营成本更容易预测。

具体价格、产品版本、实施内容和服务范围，应以全房通当期正式方案、报价单及双方签署的合同为准。