工单管理：从 WhatsApp 消息到追踪每一个请求的系统

本系列第一部分列出了工程承包和维保企业利润流失的七个环节，并指出其中最大的是一个单一事项：请求来了、活干了，却从未被登记。它还指出，实际可行的顺序是先堵住最大的漏洞。本部分讲的正是这个漏洞。

问题不在于 WhatsApp 不好，而在于把一个聊天渠道当成了运营系统。聊天可以传递信息，但它不保存任何状态，不生成任何参考编号，期限过了不会提醒任何人，也产生不了任何报告。工单就是替代方案：在请求到达的那一刻创建的一条记录，并一路伴随它直到开出发票。

首先：只有一个受理渠道

大多数试图理顺流程的尝试之所以失败，原因很简单：系统是加在 WhatsApp 旁边，而不是取代它，结果你有了两个“事实来源”，而班组会选择更省事的那个。所以第一步是管理决策，而不是技术决策：所有请求都从同一个入口进来。

这并不意味着禁止客户发消息，而是意味着接到消息的人有责任在任何技术员出发之前把它转成工单。实践中，能把这件事坚持下来的公司会同时做三件事：

• 确定一个客户真正知道的受理入口：一个号码、一个门户或一个收件箱。
• 明确一条内部规则：没有请求编号不出工，没有请求编号不发放备件。
• 立即把请求编号告诉客户，让他们开始按编号来询问，而不是每次都从头解释问题。

请求编号：其他一切都依附于它的字段

编号不是走形式，它是成本归集的依据。当备件按请求编号发放，技术员的工时记在同一个编号下，差旅和分包费用也计入这个编号时，你得到的就是核算出来的成本，而不是估算。当这些编号汇总到某个合同或项目上时，你知道的就是这份合同的利润率，而不仅仅是公司整体的利润率。

实际用途在于：当一份维保合同到期续签时，凭实力谈判与凭感觉谈判的区别，就在于你能否说出这个客户在这一年里具体用了多少次上门服务、消耗了多少金额的备件。没有参考编号，这场谈话就只是一种印象。

状态与负责人：这个请求此刻在谁手上

让客户不满的往往不是延误本身，而是不知道自己的请求进展到哪一步了。一条简短的状态链就足够：已登记、已指派、处理中、等待备件、等待客户、已完成、已关闭。在运营上最重要的两个是“等待备件”和“等待客户”，因为它们会暂停对你不利的计时，把球踢到正确的一方，并体现在你的绩效评估里，而不是消失在一个笼统的延误数字中。

而且每个请求都有一位指名道姓的负责人。归整个团队所有的请求，等于不归任何人所有。负责人不一定是干活的人，而是客户询问进展时负责回答的那个人。

响应时间：书面承诺，而非口头许诺

维保合同通常会规定响应时间和解决时间，有时还附带罚则。如果这个计时不能自动衡量，你就会从客户的投诉而不是自己的系统中得知已经违约。基本要求是：计时从请求登记时开始，而不是从某人碰巧注意到它时开始。

把两个数字分开：响应时间，从登记到技术员抵达；关闭时间，从登记到工作完成。前者衡量调度纪律；后者衡量备件是否到位以及派去的工种是否正确。把它们合并成一个数字会掩盖延误的真正原因。设定优先级时，要把它与故障对客户运营的影响挂钩，而不是取决于客户在电话里的语气。

现场要记录什么：备注、照片、签名

这部分的代价是几个月后才付，而不是今天。在执行的当下，现场要记录三样东西：

• 执行备注：故障是什么原因造成的，实际做了什么。这正是第一部分所说的会随着员工离职而流失的知识。把它记录在设备名下，它就会留在公司。
• 前后对比照片：当客户对上门前的设备状况提出异议时，这是你的证据；发生损坏时，这也是你面对保险公司或业主的证据。
• 客户或其代表的签名：确认工作已经完成并移交。没有签名，付款申请就会变成一场争论。

一个决定能否推广使用的现场经验：需要强信号的应用不会有人用。在地下室、机房或在建楼宇里的技术员，需要能在离线状态下拍照、填写并收集签名，等信号恢复后再自动同步所有内容。这是推广使用的必要条件，而不是锦上添花。

变更：先记录，再施工

第一部分中的第三个漏洞，是没有变更单就做了额外的工作。工单正是捕捉它的天然位置：当客户要求原始范围之外的内容时，就在请求内部或以关联请求的方式新开一行，并当场签字确认。现场两分钟的签名，与一个月后再设法补签，两者的差别就是收回的钱和核销掉的钱之间的差别。

从工单到发票和付款申请

回报正是在这里显现。付款申请或发票不是月底凭记忆拼凑出来的，而是由已关闭的工单汇编而成，每张工单都带有自己的凭证：日期、描述、工时、备件、照片和签名。提交工作从一项调研项目变成了一项组装工作，而且因为每一行背后都有文件支撑，对它提出异议也变得更难。

在合规方面，沙特阿拉伯的电子发票制度要求你开具与真实交易挂钩、并与天课、税务和海关总局（ZATCA）平台对接的电子发票。当你的发票行项目来源于已关闭且有据可查的工单时，合规就成为你运营方式的副产品，而不是月底的额外工作。

Origami 的观点

当我们为工程承包或维保客户上线工单系统时，最常见的错误是一开始就用一张带有二十个必填字段的庞大表单。结果可想而知：班组为了关掉界面而随便填入垃圾数据，最后你得到的数据比没有还糟。

实践中行之有效的做法是：只从六个必填字段起步——客户、现场、描述、优先级、负责人、状态——再加上关闭时的一张照片和一个签名。坚持运行整整一个月，直到形成习惯，然后一次只增加一个字段，而且只有在真正的决策依赖它时才增加。我们遵循的规则是：任何不会改变决策、不能解决争议、也不会出现在发票上的字段，都是在白白拖慢技术员的字段。

我们在第一个月关注的指标，不是系统生成了多少报告，而是进入系统的请求与实际到达主管手中的请求之比。如果请求仍然从后门进来，那问题出在管理上，任何系统都无法解决。

下期预告

既然每个请求都有了编号、负责人和计时，下一个问题就是：谁去、什么时候去、按什么顺序去。第三部分将讨论外勤团队排班和上门派工：匹配工种、按地理位置安排上门顺序、派工前核查备件是否到位，以及以符合《个人数据保护法》（PDPL）的方式跟踪考勤和位置。

资料来源

• 天课、税务和海关总局（ZATCA） —— 沙特阿拉伯的电子发票要求及对接阶段。
• 沙特数据和人工智能管理局（SDAIA） —— 《个人数据保护法》（PDPL）及其实施条例。
• 人力资源和社会发展部 —— 《劳动法》以及有关工作时间及其记录的规定。
• 沙特“2030愿景” —— 提升建筑、运营和维保效率的国家举措。