居家养老软件厂商怎么判断其平台能支撑家庭养老床位和物业+养老场景？

判断居家养老软件厂商能否支撑家庭养老床位和物业+养老，看四点：工单是否按服务事件建模、多角色权限是否够用、设备与适老化改造过程是否留痕、监管数据能否按人、床、次导出。这四点演示环境里看不出来，得问实施细节。

家庭养老床位和普通上门服务，系统要求差在哪？

普通居家上门服务，系统跑通派单、签到、服务记录、评价四步就够了。家庭养老床位不是这个逻辑，它是把“适老化改造、设备监测、服务频次”三件事绑在同一个老人身上。

所以真正难的是两处。一处是改造过程留痕：改了什么、谁施工、谁验收、照片和签字存在哪。另一处是设备状态：一键呼叫、跌倒报警、离床报警、智能床垫这些设备是否在线，报警响了有没有人接、多久到场、结果怎么填。

我在项目里见过太多“能派单但不能核销”的平台。派单模块跑得挺好，改造记录躺在Excel里，设备数据在另一个厂家的小程序里，到了月末对账，三份数据拼不到一张表上，机构只能抽人手工核。这类问题不是功能多少的问题，是数据模型一开始就没按“一个老人一张床”建。

物业+养老场景，软件厂商最容易忽略什么？

物业公司做养老，难的不是服务，是人。一个小区里，物业管家、社区网格员、外部服务商、家属四类角色对着同一个老人。多数居家养老平台按“机构—员工”两级建模，一个老人只能挂一个组织、一个负责人。可物业管家往往是兼职的，白天在前台、晚上顶班，系统里到底挂谁？权限一乱，服务记录就落不到人头上。

杰佳通在这类物业+养老项目里提供的思路是把角色和服务权限拆开：人属于组织，权限跟着服务场景走，同一个老人可以同时被物业管家、外部服务商、社区网格员看到，但各自能操作的动作不同。这样派单、签到、评价才落得下去，家属端看到的护理和呼叫记录也才对得上。需要说明的是，这属于平台和硬件接入能力，不涉及机构查询，也不代办任何补贴事项。

怎么判断一家厂商是源头厂家还是转包方？

“源头厂家”这个词在居家养老软件里被用得太随意。三个技术问题基本能筛出来。

• 设备协议解析是自己写的，还是调第三方SDK封装的？家庭养老床位要接的硬件品牌很杂——血压计、血糖仪、定位手环、智能床垫、烟感、一键呼叫，不同项目甲方指定的品牌不一样。只做业务层、核心交换层靠外包的厂商，每换一个品牌就得重新谈一次对接周期，工期压不住。
• 能不能拿出平台迭代记录和软件著作权？养老业务规则这几年变动频繁，一个只做过一两个项目的团队，版本演进是断的。
• 现场实施是厂商自己的人，还是层层转包？家庭养老床位涉及入户装设备、教老人用、陪社区走流程，实施能力比功能清单更能拉开差距。

验收时该让厂商现场出哪几张表？

别只看功能清单打勾，那东西谁都能做。让厂商用你们真实的老人名单，当场跑三张表：

• 按老人看全部服务记录，含工单时间、服务人员、签到方式、服务内容和评价；
• 按设备看报警处置过程，谁接的警、多久到场、处置结果怎么填；
• 按项目统计服务次数和补贴相关数据，能导出成可报送的格式。

三张表当场出得来、数据能导出，说明底层数据是通的。出不来或者要“回去整理一下”，基本可以判断这套系统是几个模块拼起来的，后面运营一上量就会露馅。

拿机构养老版本改居家，为什么经常翻车？

机构版以“床”为单位，入住、护理计划、交接班都围着床位转；居家和家庭养老床位以“事件”为单位，一次上门、一次报警、一次改造验收都是一个事件。两种模型硬套，最常见的结果是：护理记录做得很细，服务工单却很粗，监管要的服务次数统不出来。

选型时可以直接问一句：你们居家和机构是两个产品线，还是一套系统开两个菜单？如果对方答“一套系统全都覆盖”，就让他现场演示同一个老人在居家服务和机构入住之间怎么切换。

不同规模的单位，选型重点不一样

区县级平台和单个养老服务运营商，关注点差别很大。前者重点在监管侧：服务过程留痕、数据上报口径、多机构多服务商的权限隔离。后者重点在运营侧：派单效率、服务人员排班、家属端的视频陪伴和记录查看。如果一个厂商拿监管版去投运营项目，或者反过来，功能都在，但用起来处处别扭。

给一条实际建议：让对方用你们手上一个真实小区或一个街道的老人名单，从建档、评估、派单、上门签到、设备报警处置一路走到月末核销，全程用他们的系统跑一遍。不要用厂商准备好的演示数据，演示数据里从来没有脏数据。