When does a task become at risk?

When 80 percent of the stage's SLA hours have elapsed since the task entered the stage. It is breached once the full hours have passed.

Who receives the reminder on a breached approval?

Whoever the approval is waiting on: the client's portal door for a client approval, the task's assignees for an internal one.

How often can a reminder be sent?

At most once every 12 hours per approval, whether the job or a person sends it. The job also sends at most 50 per organisation per run.

Does changing an SLA rewrite past breaches?

No. Each recorded interval keeps the SLA hours that were in force when it started, so history is reported under the rule that applied at the time.

An SLA that means something

An SLA in Tasked is a number of hours on a stage. When a task enters the stage a clock starts: the task is fine until 80 percent of the hours have passed, at risk from there until the deadline, and breached after it. For client approvals a job runs every 15 minutes and nudges whoever the approval is waiting on, with 12 hours between nudges, and every nudge is written to the audit log.

Published September 15, 20265 min read

Hours per stage, set in the template

Every stage in a workflow template can carry SLA hours. The commercial pack ships with 48 on Brief, 72 on Script, 48 on Script approval, 120 on Pre-production, 48 on Shoot, 120 on Edit, 48 on Rough cut review, 72 on Final cut approval and 24 on Delivery. These are starting values, and the plan describes them as such: a 48-hour approval SLA is a template number, not a fact about your clients.

A new project copies the template, so its stages carry the hours the template had on that day. Changing the template changes future projects; changing a running board is a separate, per-project step, which is what keeps a live SLA change from silently re-labelling work already in flight.

Three states, computed and never stored

The state of a task against its stage SLA is derived from three moments: when it entered the stage, when the SLA deadline falls, and now. Nothing is written to the task when it crosses a line, so there is no background sweep that can fall behind and show a task as fine an hour after it breached.

Ok: less than 80 percent of the window has elapsed.
At risk: 80 percent or more has elapsed and the deadline has not passed.
Breached: the deadline has passed.
A stage with no SLA hours is always ok.

What a breach on an approval does

For approvals, the product does something rather than only colouring a card. A scheduled job runs every 15 minutes, examines pending approvals per organisation, and for each one past its window sends the same audited reminder a producer would send by hand.

The reminder goes to whoever the approval is waiting on. For a client-facing approval that is the client's portal door: the code, link, phone or email they were invited through. For an internal approval it is the task's assignees. A reminder is never sent twice within 12 hours for the same approval, and the job sends at most 50 reminders per organisation per run, so a studio coming back from a two-week shutdown is not buried on the first morning.

Each reminder stamps the approval with the time it was sent and writes an audit event. The producer can also send the reminder by hand from the approval, under the same 12-hour rule, and that is audited too.

The clock starts at the request

An approval's SLA clock starts when the approval is requested, not at the due date a producer may have typed. The due date is a promise to the client; the SLA is a measurement of the client. A 48-hour SLA breached on day three is a fact regardless of what the calendar said, and the reminder fires on that fact.

The intervals that feed analytics remember the SLA hours in force when the task entered the stage, so a later correction does not turn an on-time task into a breached one in the history.

What the SLA feeds

The SLA is not only a reminder. Three other parts of the product read it. The process audit counts, per stage, how many recorded intervals ran longer than the SLA hours, and that breach count is the number a proposed correction is simulated against. The risk score adds 10 points to a project with an approval pending for more than three days. The portfolio and client views total the minutes spent waiting on clients from approval stages.

So a wrong SLA is not a cosmetic problem. It produces false breaches in the audit, false urgency in reminders and a wrong picture of which clients are slow.

Choosing hours that mean something

Set the hours you actually expect, then measure for a month. The bottleneck view gives the median time in each stage, and the process audit compares it to what you set. Where the median is far above the SLA, the audit proposes a correction; where a stage has no SLA yet, the proposal is to measure it before setting one.

An SLA that is breached on half the tasks is not an SLA, it is a wish. An SLA that nobody ever reaches 80 percent of is not doing any work either. The one in between is the one that means something.

Questions that keep coming up

When does a task become at risk?: When 80 percent of the stage's SLA hours have elapsed since the task entered the stage. It is breached once the full hours have passed.
Who receives the reminder on a breached approval?: Whoever the approval is waiting on: the client's portal door for a client approval, the task's assignees for an internal one.
How often can a reminder be sent?: At most once every 12 hours per approval, whether the job or a person sends it. The job also sends at most 50 per organisation per run.
Does changing an SLA rewrite past breaches?: No. Each recorded interval keeps the SLA hours that were in force when it started, so history is reported under the rule that applied at the time.