A workspace’s SLA timers can now be set from the console

Setting up SLAs is one of the five things a workspace has to finish before it goes live, and it is the fiddliest: six service stages, each needing an owner, a response-or-resolution choice, three timers and an impact level. Until now only that workspace’s own administrator could do it. The console could see that a workspace had not finished — it just could not help.

A workspace’s page in the console now has an SLA section beneath its Configuration cards. It lists all six stages — Request, BRD, Bidding, Delivery, Billing and CSAT — whether or not they have been set up, so the ones still outstanding are the obvious thing on the screen. Each stage takes the role that owns it, whether the timer measures a first response or a full resolution, its target, warning and breach in working days, how much impact a breach carries, and whether escalation is flagged. A stage that is already set up shows what it holds and can be changed or removed; removing one leaves the rest alone and the stage can be set up again later.

The rules are the same ones the workspace’s own SLA screen enforces — the timers have to be whole numbers of days and run in order, target then warning then breach — because both screens now check against a single shared definition. Nothing can be saved here that the workspace’s own screen would have refused.

Once all six stages are set up, the workspace’s own go-live checklist counts its SLA as done without anyone having to tell it. Only the Sustentus team sees this section, and every change is recorded — who made it, which workspace, which stage, and what that stage now says.