服务台 SLA 管的是「多久必须首次响应、多久必须解决」，不是墙上的口号。Odoo 19 相关模型：helpdesk.sla、helpdesk.sla.status、helpdesk.ticket。配置不当的典型现象是：周末也算超时、等待客户仍在计时、一线被误判违约。本文按政策配置、工作日历、阶段暂停、主管告警与报表口径说明落地方法。
政策怎么拆
在服务台配置 SLA 政策：按优先级、客户等级、团队设定不同时限。例如：VIP 首次响应 1 小时/解决 8 小时；普通 4 小时/24 小时。政策挂到团队；工单创建时生成对应 helpdesk.sla.status。不要只配一个「全局 24 小时」——无法区分紧急故障与咨询单。
工作日历与暂停
使用公司工作日历，周末与节假日是否计入要在政策中明确并培训。「等待客户」「等待第三方」等阶段应暂停计时，否则违约率失真。阶段变更权限要收紧，防止为了躲 SLA 随意拖到暂停阶段——可抽查阶段停留时长。
告警与看板
即将超时、已超时推送给主管；看板用颜色区分。列表收藏过滤器：今日逾期、我的即将超时、团队违约。报表看违约率与响应时长分布，而不是只看关单量（关单量会刺激乱关）。
与一线二线分工配合
SLA 到期升级可自动改团队或创建 mail.activity。升级规则写进自动化，不靠微信拉人。关单前检查是否满足解决定义（根因、知识库链接、客户确认）。
验收标准
- 超时工单出红灯；主管能按团队列出违约。
- 进入等待客户后计时暂停（按配置）。
- 抽查 10 张票：阶段、SLA 状态、沟通记录一致。
SLA 报表怎么读才不伤一线
主管周报同时看：首次响应达标率、解决达标率、平均响应时长、因「等待客户」暂停的工单占比。
暂停占比异常升高时抽查是否在躲表。对 helpdesk.ticket 抽 10 张核对
helpdesk.sla.status 与沟通时间线。培训材料写清「什么叫一次有效首次响应」
（自动回执不算）。节假日日历每年更新，避免春节被算成大规模违约。
SLA 政策变更走变更单，并回溯说明是否重算进行中工单；默认不对历史重算，以免报表跳动。
SLA 与工作日历的年度维护
每年导入节假日到公司日历，并通知服务台主管回顾 helpdesk.sla 政策是否仍匹配业务承诺。
新客户等级上线时同步映射 SLA；不要只改 CRM 标签却忘了服务台。看板阶段与暂停规则做权限控制，
抽查「暂停时长 > 解决时长」的异常票。自动化：超时前 30 分钟给负责人活动；超时后升级团队主管。
关单理由码与知识库链接设为必填（按团队），减少「已解决但客户不知道」。
报表导出违约清单时带客户等级与产品，便于产品侧看到重复缺陷，而不是只考核一线个人。
SLA 政策变更通知客户成功经理，避免外部承诺与系统不一致。
预生产勾选表需覆盖文章编号 312 全部验收点后再约生产窗口。
将文章编号 312 的配置变更记入发版说明，便于回滚对照。
将文章编号 312 的配置变更记入发版说明，便于回滚对照。
将文章编号 312 的配置变更记入发版说明，便于回滚对照。
将文章编号 312 的配置变更记入发版说明，便于回滚对照。
客户承诺与系统一致
对外 SLA 文案与 helpdesk.sla 政策同表维护；变更同步客户成功与一线。
节假日日历年度导入后做一次「模拟工单」验证是否暂停计时。主管看板默认打开「即将超时」。
关单必填解决定义检查项。违约清单按产品聚合，推动缺陷闭环，而不是只考核个人响应速度。
中国Odoo网｜对照 Odoo 19 企业版服务台 SLA：helpdesk.sla 按时限与日历配置，等待阶段暂停计时。