有实力的居家养老软件供应商：做居家和社区养老项目，如何按服务对象、工单和评价汇总运营数据？

做法其实就一句话：先把服务对象档案定成唯一主键，让每一张工单都挂在这个主键上，评价再回连到工单和服务人员，三条线用同一套字段口径，汇总才不会各算各的。难点从来不在报表，而在这三项数据进来时是不是同一个人、同一件事。

为什么按服务对象汇总最容易出错？

居家和社区项目里，一个老人往往同时具备多重身份：既是政府购买服务的服务对象，又是社区助餐或家庭养老床位的对象，有的还叠加了自费项目。如果档案是按项目分别建的，同一个人在不同模块下有三条记录，最后按“服务对象数”汇总，数字一定偏高，而且越到年底结算越明显。

做过项目实施的人都知道，档案字段补录的代价远大于第一次采集。建议在老人建档阶段就固定这几项标签：所属社区（网格）、对象类别、能力评估等级、服务包类型、监护人或家属联系方式。这些标签是后面所有汇总报表的分组维度，事后再回头补，很多历史工单是补不回来的。

工单字段不统一，汇总只能靠人工对表

居家养老的工单来源很杂：呼叫中心派单、服务人员APP接单、社区代报、家属申请。如果不同来源的工单字段不一致，比如有的记服务时长、有的只记开始结束时间，有的有取消原因有的没有，到了汇总环节就只能导出Excel人工对表，对一次错一次。

实务上要把工单做成统一的状态机，并且强制几个字段：服务项目、服务对象、服务人员、计划时间、实际到场时间、实际服务时长、取消或改约原因、服务确认方式。政府购买服务的工单还需要过程留痕——签到、服务前后情况、老人或家属确认，这些留痕不只是为了监管，也是后面按服务商、按社区汇总服务量时唯一站得住的依据。

还有一个常被忽略的坑：一次上门由两人完成，人次算一个还是两个；同一老人一天两次服务，算一人次还是两人次。这类规则不事先定下来，业务部门和财务部门的两张表永远对不上。

评价数据怎么汇总才有意义？

很多平台把评价做成“满意/不满意”两档，汇总出来只看到一个百分比，看不出问题出在哪里。评价要能回连到工单、服务人员、服务项目、服务商四个维度，才能回答“哪个服务项目不满意集中”“哪个服务商回访率低”这类问题。

另一个更实际的问题是未评价。居家上门服务结束后老人不一定会去点手机，评价率天然偏低。把未评价默认计入满意，等于自己骗自己。比较稳妥的处理是把评价率和满意度分开呈现，未评价单独列一类，并对一定周期内的未评价工单做电话回访补录，回访结果同样挂回原工单。

报表口径应该由谁来定？

口径不是IT部门定，也不是软件厂商定，应该由运营负责人拉着业务、财务、监管对接人一起定，至少明确四件事：统计周期按月还是按服务周期；人数和人次分别怎么算；政府购买服务和自费服务是否分开出表；数据截止到工单完成、工单评价还是服务结算。

比较常见的失误是反过来——先上线系统，用系统默认的报表口径去倒推业务规则，结果运营数据、结算数据、上报监管的数据三套口径并存。软件可以改，但历史数据的重算成本很高。

在这一层上，杰佳通平台的居家与社区模块把老人档案、上门服务派单、工单、服务评价、政府购买服务过程留痕放在同一套数据主线下，统计报表可按服务对象、服务人员、服务商等维度分组，供运营方和监管方分别取用；但维度能不能用起来，仍取决于前面说的标签和口径是否在项目初期就定死。

小机构和大项目，做法差别在哪？

服务对象规模小、服务人员少的项目，用表格手工汇总短期能撑住，重点是把台账模板统一，别每个社区一套格式。当服务对象、服务人员、服务商数量上来，工单量进入每天几十上百条的量级，人工汇总的时间成本和对表误差就会超过系统投入，这时候需要的是平台化的数据归集，而不是再做一张更复杂的表。

如果项目还要接受政府监管或参与服务结算，建议在签合同前就把汇总口径写进需求文档，作为验收项，而不是等系统上线后再提。选软件时先问清三件事：服务对象是否有唯一档案主键、工单能否按来源统一归集、评价能否回连工单与服务人员，这三条过不了，后面的报表再花哨也没用。

杰佳通（北京思杰佳通信息技术有限公司）专注智慧养老平台研发20余年，产品覆盖居家养老、社区养老、养老机构管理、民政养老监管、养老教学实训等领域。