优先级
包含小程序端优化和 PC 端建设两条线,小程序是发起咨询选择历史工单、补齐思路分析里房屋同住人信息、运营统计。
PC 端是新的工作台,尚未开发。以后两端仍使用同一办件、同一咨询记录。
本页用于和业务、开发确认下一阶段做什么。小程序延续 3.2 / 3.3。4.0 尚未开发,跨端继续办理放在最后。只围绕工单场景,不扩展成居民数据平台。
本期先做小程序端优化。PC 端建设靠后。
包含小程序端优化和 PC 端建设两条线,小程序是发起咨询选择历史工单、补齐思路分析里房屋同住人信息、运营统计。
PC 端是新的工作台,尚未开发。以后两端仍使用同一办件、同一咨询记录。
在现有投诉人画像的户情段上写清本户走访与其他同住人走访。同住人括号内写与投诉人的关系(由户主关系字段推测)、明确为租户时才写租户、历史工单和调解记录。房间详情弹框保持现状,不再改。
沿用现有运营统计页。只增加一张办件卡,数字随时间范围与辖区筛选变化,口径为时段内 +1 累计。小程序与 PC 同一后端、同一数字。不统计集体可见。
4.0 尚未开发,先放在最后。方向仍是小程序现场补充后回到 PC 继续整理,两端使用同一办件和同一咨询记录。
以下不进入开发。
如果在房屋信息、关联居民或历史工单里再嵌入总结或详情界面,入口已经比较深,用户教育成本也比较高。这个做法不采用。正文里的姓名、走访、历史工单和调解记录沿用已有弹框。房间详情弹框保持现状。
不设计离职后的自动转移或指定负责人。办件随账号自然不可用。需要交接的,在离职前自行完成复制。
一种做法是保持现状,由创建人手动切回仅自己。另一种是到期后提醒创建人或社区确认是否继续共享,但不自动转成私有,避免正在办理的办件突然失去协作权限。两种做法都还没有业务结论,本阶段不设计期限规则。
居民台账的居民详情已经按电话号码关联工单,并在详情页展示。它和具体办件里的房屋信息、选择历史工单分开:办件里从“+”检索本社区历史工单并加入当前咨询;台账继续只负责按电话号码看这个人的关联工单。历史工单列表如需小程序端呈现,也应作为台账的构成部分放在台账里。
左侧大图取自 4.0《方案 I · index-3》,右下小图取自 3.3 办件详情。两端不各做一套办件。
左:户情正文与走访总数。右:走访记录半屏(线上一致;对人的走访在列表增加「居民」字段)。
投诉人刘高兴,住址为 兆维小区78号楼3单元201室。
投诉人刘高兴,住址为 兆维小区78号楼3单元201室。该房间无其他同住人。本户相关走访记录 0 条。
先看详情再选中。一次最多 5 件,与办件附件分开计数。
沿用现有统计页。只增加一张办件卡,不分端,不统计集体可见。
新增插在这里:现有指标卡下方、趋势图上方
红框只标插入位置。数字为示意,卡片样式沿用页面现有指标卡。