步骤1：先测入口，别先看文档
做BAU测评时，很多人第一步就翻SOP。我建议反过来，先问：一个问题从哪里进来？如果订单异常在客服群、系统告警在邮件、老板投诉在私聊，入口分散，后面文档再厚也救不了。
靠谱的BAU入口不一定高级，但必须统一。可以是工单系统，也可以是一张表。关键是每件事能被记录、分派、追踪，而不是靠谁看到群消息。
BAU测评：我踩过的坑
BAU测评别只看有没有流程文档。我更关心它能不能少漏单、少扯皮、少重复救火。下面按一次检查BAU成熟度的步骤走，顺手把常见误区也拆出来，方便你自查。
步骤2：再测责任人，防止人人负责
第二个坑是责任写得很热闹：运营跟进、技术支持、客服协助。看起来大家都在，真出事没人拍板。BAU测评一定要找唯一owner。
我会直接问一句：这件事超时了，谁会被提醒？如果答不出来，说明责任没落地。协作人可以有多个，负责人只能有一个。
步骤3：测完成标准，不接受处理一下
很多BAU流程最虚的地方，是完成标准写成已处理、已同步、已跟进。这些词没法验收。比如退款异常，完成标准应该是用户退款状态确认、原因记录、必要时补偿方案发出。
做测评时，你可以抽5条历史记录，看别人能不能复盘当时发生了什么。如果只能看到一句已解决，那这套BAU对后续改进几乎没价值。
步骤4：测升级规则，别让一线硬扛
BAU不是让一线把所有锅吞下去。遇到金额大、客户等级高、超时、系统性重复问题，就该升级。没有升级规则，最后会变成会哭的人有糖，不吭声的人加班。
我常用的升级条件很简单：超过承诺时限、影响核心客户、同类问题连续出现、涉及资金或合规。满足任一条，就从BAU处理升级到负责人判断。
步骤5：最后测改进闭环
最后一步是看BAU有没有把重复问题送进改进池。如果一个问题一周出现三次，还只是继续人工处理，这不是稳定，是麻木。
我的BAU测评结论通常分三档：能跑但靠人、能跑且可追踪、能跑还能反哺改进。真正健康的是第三档。它不会消灭所有问题，但会让团队每个月少踩一点同样的坑。
推荐阅读
常见问题
- BAU测评主要看哪些指标？
- 看入口统一率、任务超时率、重复问题占比、责任人明确度、历史记录完整度。别只看有没有制度文件。
- BAU测评多久做一次合适？
- 业务稳定期可以每月轻量检查一次，季度做一次深度复盘。新系统上线、组织调整、投诉激增后，应该马上测一次。
- BAU测评发现问题太多怎么办？
- 别一次全改。先抓影响客户、资金、合规和高频重复的事项。每次只修两三个关键流程，比铺开十几个整改项更靠谱。