概览
每一个服务台都在违约发生之后才报告违约。标准看板显示的是一个已经成为历史的百分比——一块记分牌,而记分牌是没法据以行动的。等到一张工单出现在违约计数里时,那笔服务补偿已经欠下了,剩下的唯一选项就是道歉。
一位服务经理真正需要的,是那份「如果什么都不变就会违约」的工单清单,按剩余时间排序。几乎没有工具回答这个,因为那意味着要预测一张工单还要花多久,而不是度量它已经花了多久。
那份预测不需要多聪明。大多数违约在几个小时前就从少数几个事实里看得出来:这张工单在等一个还没回复的第三方、它被转派过两次、它是某个明天休假的人手上唯一一张这类工单,或者它在一个时钟照走的周末里无人问津。
第二样没人去核的东西,是那个时钟本身。暂停规则、工作日历和时区处理,正是 SLA 度量悄悄出错的地方,而一条配置错误的暂停规则意味着你报告的数字和你合同上的数字并不一致——而这只会在一位客户对一笔服务补偿提出异议时才被发现。
这个智能体把两者都报出来:什么即将违约、还剩多少时间、原因是什么,以及度量本身在哪里与合同不符。它不转派任何东西,也不答复任何东西。
价值
违约被预防,而不是被报告
而那是唯一对客户有帮助的版本。
保住那些服务补偿
一次被预防的违约,就是一笔从未流出的钱。
站得住脚的度量
因为那些时钟规则被对照合同核过了。
功能说明
预测,而不是计数
一个违约百分比是历史。一份「接下来什么会违约」的清单,才是人能据以行动的东西。
给原因,而不只是给风险
在等第三方、被转派过两次、负责人明天休假。每一种都需要不同的干预。
把时钟对照合同核对
暂停规则、日历和时区。一条配置错误的暂停规则,意味着你的数字和客户的数字对不上。
给风险敞口定价
涉及的服务补偿金额,于是优先级反映的是后果,而不是工单年龄。
找出没人负责的工单
被反复转派,或者压在一个不在岗的人手上。那是经典的违约,而且完全可以避免。
不碰任何工单
它从不转派、改优先级或答复。重排某个人的队列,是他主管的决定。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 弄清哪些未关闭的工单即将违约,以及为什么。
- 目前由谁完成
- 一位服务经理扫一遍队列,而通常是在事后。
- 多久一次
- 每天。预防一次违约的窗口只有几个小时。
- 通常的人工投入
- 每一张工单都要把已用时间、等待状态、负责人在岗情况和时钟规则放在一起看。
为什么偏偏是客户支持。每一个服务台报告的违约百分比都已经是历史。而且没有人去核那个时钟本身——一条合同并不支持的暂停规则,意味着你的数字和客户的数字对不上。
无人值守运行
由你或某个事件启动,然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
SLA 违约预测代理 没有任何发送、支出或承诺的途径。正是这个限制,让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录,每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-sonnet-5,并自动回退
- 3工具search_knowledge, extract_structured_data
- 4权限自动执行 READ 级操作;更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"asAt": "2026-09-02T09:00:00Z",
"tickets": [],
"warningWindowHours": 4
}输出
{
"escalate": true,
"disclaimer": "A forecast from your own records and contract terms. No ticket has been changed or answered, no credit issued or promised, nobody contacted, and no statement is made that a contractual breach has occurred.",
"willBreach": [
{
"basis": "Elapsed against target, with the pause rule corrected to the contract.",
"reason": "Waiting on a third-party supplier who has not replied for 3 days. The clock is not paused for third-party waits under this contract, though the tool shows it as paused.",
"customer": "Harbour Logistics",
"reference": "INC-8841",
"creditExposure": 4200,
"hoursRemaining": 2.5
}
],
"clockFindings": [
{
"issue": "Pause on third-party wait",
"contract": "Clause 7.4 pauses only for waits on the customer, not on your suppliers.",
"configured": "Clock pauses whenever state is 'Waiting — third party'.",
"ticketsAffected": 19
}
],
"couldNotAssess": [
"Three tickets have no target recorded."
],
"alreadyBreached": [
"INC-8790 breached 6 days ago. Clause 11.2 makes a credit automatic and no credit appears on the account."
],
"escalationReason": "A pause rule is applied that the contract does not support, affecting 19 tickets, and one ticket breaches within 2.5 hours.",
"unclaimedCredits": [
"One breach from last month appears to owe a credit that was never applied."
],
"contractTermsFound": true,
"totalCreditExposure": 18400
}使用条件
集成
无需集成。
开始之前
- 未关闭的工单,含目标时限、已用时间、状态与负责人
- 你的 SLA 条款,含暂停规则与工作日历
- 服务补偿条款,如果存在的话
- 需要 全量访问 套餐或更高
使用场景
每日服务复核
今天和明天什么会违约,以及为什么。
客户复盘会之前
在会前就拿到敞口和成因。
一次合同变更之后
工具到底有没有把新条款真正实现出来。
假期与顶岗规划
哪些承诺取决于谁在岗。
价格
常见问题
它会转派或升级工单吗?
不会。重排某个人的队列是一项带着它看不见的语境的管理决定。它产出清单和原因。
它怎么预测一次违约?
依据记录里已经有的事实——已用时间对目标、等待状态、转派次数、负责人在岗情况,以及那些时钟规则。它写明每一条的依据,绝不把一个猜测当成一次度量来呈现。
如果我们的 SLA 配置本身就是错的呢?
那正是发现之一,而且往往是最有价值的那一条。当被配置的时钟与所提供的合同条款不符时,它会报告这处差异,而不是去相信那个工具。
评价
客户运行过该智能体后,评价功能将开放。
需要这个智能体换一种做法?
告诉我们要改什么,我们的团队会为您的业务规划一个定制版本。
定制此智能体