Does the client get the reminder, or does the studio?

The client, when their door can approve and carries an email or a phone. The reminder is an email and an SMS pointing at the portal. Only when no client door can be reached does the reminder go to the task's assignees in the app.

Does the reminder contain the code or the link again?

No. The credential is never re-sent. The message links to the portal's front door and the client enters the way they entered before.

How often can a client be reminded?

At most once every 12 hours per approval, and the email is deduplicated per door per day. A manual reminder inside the window is refused rather than sent twice.

What counts as breached?

72 hours since the approval opened by default, or a typed due date that has passed, whichever comes first. At risk begins 12 hours before either.

Does a breach change the approval's status?

No. The approval stays pending until the client decides. A breach sends the reminder and writes an audit row; it does not invent a new state.

The approval SLA, and what happens when it passes

An approval SLA in Tasked is a clock that starts when the approval opens. The default target is 72 hours with a warning 12 hours before, and a job checks every pending approval every 15 minutes. When the target passes, the client whose door can approve gets a reminder by email and SMS pointing back at the portal, at most once every 12 hours per approval; when no client door can be reached, the task's assignees get an in-app reminder instead. Every reminder is written to the audit log.

Published September 15, 20265 min read

Two clocks, and which one wins

Most approvals never get a date typed on them. A producer sends a cut and nobody writes a deadline, so the thing that goes wrong is not a missed date; it is an approval that has been open for four days without anyone noticing. That is why the approval SLA is measured from the moment the approval opened, against a target. The default target is 72 hours and the default warning window is 12 hours before it.

When somebody did type a due date, that date wins. An approval is breached when the target has elapsed or the due date has passed, whichever comes first, and at risk when either is inside the warning window. A separate reminders job runs every five minutes and reminds approvals whose due date has arrived or is within the next 60 minutes, so a typed deadline is honoured to the hour.

Stages have their own clock. A stage can carry an SLA in hours; a task entering it starts the clock, the state is ok until 80 percent of the window has passed, at risk from there to the deadline, and breached after. The state is computed from the timestamps every time it is read, so there is no counter that can fall behind.

What the check does every 15 minutes

A scheduled job examines the pending approvals of every organization, oldest first, up to 500 per organization per run, and classifies each as ok, at risk or breached. For every breach whose reminder cooldown has passed, it sends the same nudge a producer would send by hand, and it names the longest-waiting approvals in its own report so an operator can see which ones.

The nudge is capped at 50 approvals per organization per run. A studio coming back from a two-week shutdown must not have its whole backlog reminded in one pass; the next run picks up the rest.

The job does not invent an escalation state and does not email the owner. What it does is real and recorded: a reminder stamp on the approval, an audit row saying the reminder was sent by the system, and a message to the person who can act.

Who is reminded

A reminder is only worth sending to whoever the approval is waiting on. For a client-facing approval that is the client, and the client has no account, no seat and no in-app bell; what they have is a portal door. So the job looks for live doors that can decide this approval: doors with the approve permission, not revoked, not expired, scoped to this project or to the whole client, and carrying an email or a phone number.

Each such door gets the reminder on the channels it has: an email that names the approval, says how many days it has waited and links to the portal's front door, and an SMS with the studio's name and the portal link. No credential is re-sent; the client goes back in the way they came in. The email is sent once per door per day, and the approval itself is reminded at most once every 12 hours.

When there is no reachable client door - an internal sign-off, or a client whose only door is a hand-delivered code with no email and no phone - the reminder falls back to the task's assignees on the in-app bell, which is the studio's own list. That is the one case where the studio has to nudge the client itself, and the bell says so.

The manual nudge, and the record it leaves

A producer can remind an approval by hand from the approval itself. It is the same path the job takes: the reminder stamp is written, an audit row records who pressed it, and the message goes to the same doors. The difference in the log is the actor: a person for the manual nudge, the system for the scheduled one.

The 12-hour cooldown applies to both. A second manual reminder inside the window is refused with a message saying the approval was already reminded recently, rather than sending the client a duplicate. A reminder on an approval that is no longer pending is refused too.

The stamp is written before the message is sent, so a mail provider outage never rolls a reminder back; the record says a reminder was attempted, and the next run can try again after the cooldown.

Reading the SLA in analytics

The SLA clock feeds the analytics that a studio reads about itself. The bottlenecks view reports the median time a task spends in each stage, which is where a slow client review stage shows up as a number rather than a feeling. The weekly owner report carries the same picture, and the risk score for a project lists its reasons, so a project waiting on a client three days past target explains itself.

The count of what is waiting on a client is taken from approvals that were actually put in front of a client with a decision link, so an internal sign-off never inflates the client-waiting number.

Setting the target

The 72-hour target and the 12-hour warning are the defaults the check runs with. Stage SLAs are set per stage on the workflow, in hours, and a workflow proposed by the AI onboarding carries a per-stage SLA table that is applied only after the studio reviews and approves it; a stage the table does not name keeps no clock, because a clock nobody chose is worse than no clock.

A typed due date on an individual approval is the most specific instruction and beats everything else. When a client has promised an answer by Thursday, type Thursday.

Default: 72 hours from opening, warning at 12 hours before.
Checked every 15 minutes; due dates reminded every 5 minutes with a 60-minute lead.
One reminder per approval per 12 hours; one email per door per day.

Questions that keep coming up

Does the client get the reminder, or does the studio?: The client, when their door can approve and carries an email or a phone. The reminder is an email and an SMS pointing at the portal. Only when no client door can be reached does the reminder go to the task's assignees in the app.
Does the reminder contain the code or the link again?: No. The credential is never re-sent. The message links to the portal's front door and the client enters the way they entered before.
How often can a client be reminded?: At most once every 12 hours per approval, and the email is deduplicated per door per day. A manual reminder inside the window is refused rather than sent twice.
What counts as breached?: 72 hours since the approval opened by default, or a typed due date that has passed, whichever comes first. At risk begins 12 hours before either.
Does a breach change the approval's status?: No. The approval stays pending until the client decides. A breach sends the reminder and writes an audit row; it does not invent a new state.