本模板把四块法——事物、关联、状态、数字——应用于上门服务与售后的跟踪。它以一家锅炉维保公司为例填写：示例展示如何描述一个请求的完整脉络，从客户来电到开票，全程不描述任何一个屏幕。
要改用它，请沿着你自己的流转：谁来电、排了什么、谁出勤、返回时记录什么。「状态」块是这一行的核心——采用一个请求在你公司所经过的确切阶段，按真实顺序，用你自己的话。
以你的行话填好后，这段文字可作为交给开发者的简报——或原样提交给 Blueprint Maker，由它推导出一份供你确认的应用方案，再生成一个应用：数据库、各屏幕、仪表盘和演示数据。
可复制的模板
我的活动：锅炉维保与抢修公司， 3 名技师在外，1 人在办公室。 所跟踪的事物： - 服务请求（收到日期、事由、优先级、渠道 电话或邮件） - 客户（姓名、地址、电话、类型 个人或物业管理方） - 设备（品牌、型号、安装日期、上次维保日期） - 上门（排定日期、技师、完成的工作、更换的配件、时长） - 技师（姓名、专长） 关联： - 一个请求来自一位客户。 - 一台设备归属于一位客户。 - 一次上门回应一个请求并涉及一台设备。 - 一次上门由一名技师执行。 一个请求的状态：已收到、已排期、已完成、待开票、已开票、已取消。 每天早晨要看的数字： - 等待排期的请求 - 本周排定的上门 - 已完成待开票的上门 - 本月每名技师的上门数
把这份模板改用于你的组织
- 无需跟踪设备：如果你做维修而不留设备历史（开锁、玻璃……），删除「设备」实体及其关联——请求直接挂到客户上。
- 维保合同：如果你的客户有含计划上门的年度合同，加一个「合同」实体（开始日期、到期、上门次数），关联到客户，并加一个指标「尚待排期的合同上门」。
- 优先级：示例在请求上用了一个优先级字段。如果紧急程度左右你的日程，明确你的级别（24 小时内紧急、标准、可排期）——它们会成为筛选器。
- 报告：「完成的工作」和「更换的配件」两个字段通常足够。如果你的报告更丰富（照片、签名），请注明：结构提供该字段，内容保持自由。
- 「待开票」状态标记还剩什么要开票——合规发票本身在你的开票工具中生成，而非本应用。