דילוג לתוכן הראשי

When your process definition is wrong

Your process definition is wrong when the SLA you wrote on a stage does not match the time tasks really spend in it. Tasked's process audit measures the median time in every stage from recorded intervals, counts the breaches against the SLA you set, proposes a correction, simulates it over the last 30 days, and applies nothing until you approve. Approval changes the template; the running boards are offered separately, one by one.

5 min read

The finding

The audit reads the recorded intervals of every stage in the organisation. For each stage it reports how many intervals it measured, the median minutes in stage, the SLA hours on that stage, and how many intervals ran longer than those hours. Stages are listed slowest first, so the first finding is the one that matters most.

The finding is stated in plain language on the proposal: the stage took this many minutes median and breached this many times. There is no score to interpret; every number in the sentence is a count or a median over rows you can open.

The proposal

For a stage with an SLA, the proposal is to move those hours to the stage the audit names. For a stage with no SLA at all, the proposal is to measure it before setting one, because a number set without history is the thing this feature exists to catch.

The proposal is stored as a proposal row, like an automation compiled from a sentence: described in plain language, simulated, and inert until a person approves it. Producing the proposal costs nothing and calls no model; it is arithmetic over intervals.

The simulation

Before you decide, the audit runs the proposed rule over the last 30 days and reports what would have happened. It counts breaches under the current rule and breaches under the proposed one, and splits the difference into three numbers: true positives, the breaches both rules catch; false positives, the ones the proposed rule would add; and false negatives, the ones it would stop catching.

That is the sentence the plan for this feature was written around: this many real breaches caught instead of this many false alarms. If the proposed rule catches fewer real problems than it removes false ones, you can see that before it touches anything.

  • Breaches before: under the SLA as it stands.
  • Breaches after: under the proposed placement.
  • True positives, false positives, false negatives: the difference, named.

Approval writes the template, and only the template

When you approve, the corrected SLA hours are written onto the named stage in your workflow templates, and the summary says how many templates were touched. From that moment every new project of that type starts with the corrected hours. Nothing on a running board changes, and the summary says so explicitly.

This is the safe, reversible half. A template edit affects projects that do not exist yet; it cannot make a task that was on time yesterday breached today.

Running boards, one at a time, audited

After approval, the review screen lists the running projects whose live stage still carries the old hours, with the project name, the current and proposed hours, and the number of open tasks on that stage. You choose which to update. Updating one writes that project's stage and one audit event; updating none is a valid answer.

The write to a live stage is narrow: it changes the SLA hours, name, colour or roles, and refuses to change a stage's key or type while tasks are on it, because moving a stage's type out from under a task changes whether an approval is owed.

History is not restated. Every recorded interval keeps the SLA hours that were in force when it opened, so an audit run next month still reports last month under last month's rule.

Why it is not automatic everywhere

The obvious design is one click that fixes the template and every running board. It is wrong, and the decision record for this feature explains why: changing an SLA on a live board re-labels what the product has already said. A task that was inside its 48 hours becomes breached, an escalation that never fired looks like it should have, and a client who was told the project was on track was told something the product now contradicts.

So the fan-out exists, and it is opt-in, per project, with an audit row each. An organisation that wants its running boards kept in step with the template automatically cannot have that as a setting, and that refusal is deliberate.

Questions that keep coming up

Does the process audit change anything on its own?
No. It produces a proposal with a simulation. The template changes only when you approve, and running boards change only when you pick them one by one afterwards.
What does the simulation compare?
Breaches under the current SLA against breaches under the proposed one over the last 30 days, split into true positives, false positives and false negatives.
What happens to a stage with no SLA?
The proposal is to measure it before setting one. The audit reports its median and sample count so the number you set later has a basis.
Will approving the proposal rewrite past breaches?
No. Intervals keep the SLA that applied when they opened, and approval only edits the template. A running board changes only if you choose it.
Can I apply the correction to some projects and not others?
Yes. The review screen lists each running project with its open task count on the affected stage, and you update them individually.

Start without a card

Fourteen days, everything switched on. Open a workspace, tell the AI how you work, invite a client to approve.

A question? Write to us

We answer from the site itself when we can, and a person follows up if needed. No mailing list.