At a glance
Of every audit finding that landed in the Wrike Space in the last 90 days, the percentage that has reached Completed status. The headline number for “is Wrike actually serving as a delivery surface for our audit work, or are findings sitting in approval-gate purgatory?” On Wrike specifically, this card matters because the open count is structurally inflated by approval-gate dwell time, the rate is the cleanest signal that real throughput is keeping pace with intake, independent of how many gates the workflow contains.
| The formula | (findings completed in last 90D) / (findings created in last 90D - findings cancelled in last 90D) × 100. Closures use the timestamp the task entered the Completed status group. Cancellations are excluded from BOTH terms (so a team that bulk-cancels false positives cannot game the rate upward, and the rate stays representative of actionable findings only). |
| Why a 90-day window | Smooths out enterprise approval-cycle variance. Wrike workflows often include 1-3 week approval steps; a 30-day window swings wildly because the closure cohort and creation cohort barely overlap. 90 days captures both intake and the corresponding closure tails fairly. |
| Numerator (completed) | Count of tasks tagged vortexiq:finding that reached the Completed status group in the trailing 90 days. Re-opens (Completed → Active → Completed) count once for each forward closure. |
| Denominator (created minus cancelled) | Count of tasks tagged vortexiq:finding created in the trailing 90 days, minus those that ended up in Cancelled. Tasks created before the 90-day window are excluded from BOTH terms (so the ratio stays clean). |
| Cancelled task handling | Cancelled tasks are excluded entirely. Wrike’s Cancelled group is treated as “won’t fix” rather than “fixed”, which is the right call for audit findings, a cancelled finding usually means the issue was a false positive or the team explicitly decided not to act. |
| Approval-gate handling | Tasks in Pending Approval and other custom non-terminal states count as still-open in the denominator until they reach Completed. This means the rate naturally lags the true team throughput by the average approval-gate dwell time (typically 5-9 days on enterprise Wrike workspaces). |
| Edge case, zero creations | If no findings were created in the 90-day window the card displays --, not 100% or 0%. This usually means the auto-dispatcher is misconfigured for the Space. |
| Threshold rationale | Good ≥75%, warn 50-75%, critical <50%. Empirically Wrike enterprise teams close 65-80% of findings within 90 days, slightly lower than Jira because of approval-gate dwell. The 50% critical line means the workflow itself is the bottleneck (not intake), and the team should audit which gates can be removed or batched. |
| Time window | 90D (rolling) |
| Alert trigger | <50% |
| Sentiment key | vortexiq_finding_resolution_rate, gauge-typed (good ≥75, warn ≥50) |
| Roles | owner, operations |
Calculation
Calculated automatically from your Wrike (API) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US enterprise B2B brand on Adobe Commerce, ~120 person team. Marketing ops + ecommerce engineering on Wrike with the audit-feed dispatcher live for 7 months. Snapshot taken on 02 May 26. Trailing 90 days: 03 Feb 26 → 02 May 26 (89 days).| Path the closed task took | Count | Median days created -> completed |
|---|---|---|
| New -> Triaged -> In progress -> Done | 31 | 9 |
| New -> Triaged -> In progress -> Pending approval -> Done | 17 | 18 |
| New -> Triaged -> Pending stakeholder -> In progress -> Done | 4 | 24 |
severity:medium and severity:low findings (only critical and high require stakeholder review). The intake stayed the same; the closure rhythm sped up. This is the most common Wrike-specific lever: tier the approval gates by severity rather than applying them to every task.
The dangerous reading: rate at 38% with 30+ open findings, more than half stuck in Pending states. That is the “approval logjam” pattern, the team has done the work, the organisation cannot absorb decisions fast enough, and intake is outpacing throughput because the gate itself is the bottleneck. Vortex IQ pages owner + operations and recommends an org-level intervention: delegate approval authority, batch approvals weekly, or remove the gate for non-revenue-impacting severities.
Sibling cards merchants should reference together
| Card | Why pair it with Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | The numerator’s complement. Open is the queue at this instant; resolution rate is the long-window flow. | Open above 25 with rate below 60% means approval-gate dwell is structural; redesign the workflow or accept the cost. |
| Abandoned Findings (>14d no movement) | Abandoned is the leading indicator of a falling rate. | On Wrike, most abandoned tasks are stuck in Pending states; the abandonment count is therefore mostly a measure of approver responsiveness, not team capacity. |
| Avg Time-to-Fix (days) | Cycle time on the resolved subset. The “how fast” peer to “how many”. | Rate at 75% with avg time-to-fix at 22 days means the team gets there but slowly (typical enterprise Wrike). Rate at 75% with time-to-fix at 8 days means the gates are working efficiently. |
| Throughput Trend (30d) | Weekly closure rhythm; multiplied by 12-13 weeks should approximate this card’s numerator. | Numerator divided by weekly throughput equals weeks tracked, sanity-check the arithmetic. |
| Datadog Operational Health Score | If Datadog health is dropping while Resolution Rate is dropping, the team is detecting more issues AND fixing fewer of them. | Worst-case combination, escalate. |
| Jira Finding Resolution Rate | Cross-tracker peer for teams that mix Wrike (marketing / ops) and Jira (engineering). | Jira rate typically 5-12 points higher because Jira lacks formal approval gating. The gap quantifies the cost of Wrike’s gate discipline. |
| Asana Finding Resolution Rate | Lightweight-PM peer. Asana and Wrike sometimes coexist in larger orgs. | Asana rates often run 3-8 points higher than Wrike for the same reason as Jira, fewer formal gates. |
Reconciling against the vendor’s own dashboard
Where to look in Wrike’s own dashboard:Wrike workspace → open the configured Space → Reports → New Report → tasks → filter byFor Business+ plans, save the report and pin it to the Space’s overview tab; the chart updates daily and reconciles within polling lag. Why our number may legitimately differ from a manual count in Wrike:Source field equals vortexiqANDCreated date is in the last 90 days→ group byStatus group. The percentage of Completed tasks against the total (excluding Cancelled) matches this card.
| Reason | Direction | Why |
|---|---|---|
| Cancelled task handling | Ours higher (cleaner) | Wrike’s standard Completion Rate report counts cancelled tasks in the denominator. Vortex IQ excludes them from both terms. The result, this card reads 5-15% higher than the raw Wrike report on Spaces that cancel many false positives. |
| Re-opened tasks | Ours higher | Each forward Completed transition counts; a task closed twice contributes twice to the numerator. Wrike’s report only counts the latest state. |
| Approval-gate dwell | Same in both | Tasks in Pending states are NOT counted as Completed in either Wrike’s view or this card. The dwell time hurts the rate symmetrically. |
| 90-day window edge | Boundary drift | Tasks created on day 91 are excluded; day 89 included. The window slides daily. |
| Custom workflow mapping | Possible mismatch | If a custom status is intended as “done” but mapped to the Custom group instead of Completed, Vortex IQ counts those completions as still-open. Manual reconciliation in Wrike via the same filter shows the same answer; the gap is between intent and configuration. Map via Space settings → Workflows. |
| Polling cadence | Ours stale up to 60s | Sub-minute closures lag in the rate on Free / Professional plans. |
| Time zone | Boundary days off | Window computed in UTC; merchants in PST may see day-1 / day-91 boundaries shift. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
jira.jir_vortexiq_finding_resolution_rate | Definitional twin on Jira. Same window, same formula. Where both are connected, the two rates measure overlapping but not identical populations (Jira typically engineering, Wrike typically marketing / ops). | Jira rate typically 5-12 points higher for enterprise teams because Jira lacks Wrike’s approval gating. The gap is the price of Wrike’s gate discipline; whether that price is worth paying depends on whether the gates catch real issues. |
asana.asa_vortexiq_finding_resolution_rate | Lightweight-PM peer. | Asana rates run 3-8 points above Wrike on similar populations. |
monday.mon_vortexiq_finding_resolution_rate | Direct work-management competitor. | Monday and Wrike often produce similar rates when both are configured with formal gates; lighter Monday setups outperform Wrike. |
Known limitations / merchant FAQs
Why is my Wrike rate lower than my peer brand’s Jira rate when both run the same audit feed? Wrike’s enterprise approval workflows include Pending stakeholder, Pending approval, and other custom gates that Jira does not enforce by default. Findings that close in 5-7 days on Jira often take 14-22 days on Wrike because of the gate dwell. The gap is the price of Wrike’s discipline; whether that price is worth paying depends on whether the gates catch real issues (legal, brand, compliance) or are vestigial. My team uses Wrike’s approval workflow on every audit task. The rate is stuck around 65%. Should I worry? Probably not, but consider tiering the gates. If the gates exist for legitimate reasons (legal review on high-severity, brand approval on low-severity), 65% is the right rate for your workflow. If the gates exist because “we always do it this way”, remove them for at least one severity tier and watch the rate climb. The Storefront Operations exemplar in the worked example moved from 64% to 71% by simply making the stakeholder gate optional for medium / low severity. Why is my rate stuck at exactly 100%? Three possibilities: (1) very few findings in the window (e.g. 5 created, 5 completed); the rate looks great but the absolute volume is too thin to be meaningful, look at intake separately. (2) Auto-dispatch is misconfigured and findings are not reaching Wrike; the denominator is artificially small. (3) The team is closing tasks immediately after creation as a workflow shortcut; check the average time-to-fix sibling, if it is below 1 day on every finding, the closures are not real fixes. Why is my rate exactly 0%? Either no closures in 90 days (the team has not engaged with Wrike for VortexIQ work) or the team uses a custom status they think is “Done” but Wrike treats asCustom group instead of Completed. Check the Space’s workflow definition: only the Completed system group counts as a resolution.
Does cancelling a task hurt my rate?
No, neither helps nor hurts. Cancelled tasks are excluded from both terms, so the rate stays unaffected. This is intentional: a team that bulk-cancels false positives should not see the rate move just because they tidied up. The trade-off is that excessive cancellation can make a small denominator look smaller; if you are cancelling more than 25% of created findings, the audit rules need tuning, not the workflow.
Does a re-opened task hurt my rate?
No. Re-opening (Completed → Active) does not subtract from the numerator; only forward closures count. Re-opening adds to the open count (which surfaces on the Findings Open card) but does not penalise this card. The reasoning, regressions are a separate phenomenon from closure discipline, and double-counting punishes the team unfairly when they correctly catch a regression.
The rate dropped from 71% to 58% over a month with no obvious cause. What happened?
Three usual causes. (1) An approval-gate that previously processed weekly batches stopped (an approver left, holiday cover lapsed, the meeting was cancelled). Check who owns Pending stakeholder and Pending approval and audit recent activity in those states. (2) A new audit rule went live that produces high intake of findings the team has not yet decided how to action; intake outpaces the workflow’s absorption capacity for 30-60 days while the team builds the right routing. (3) Window-edge effects, a closure on day 91 left the window. Look at week-over-week trend, not day-over-day.
Should I optimise this number directly?
No. Resolution rate is a downstream indicator, not a target. Optimising it directly leads to bad behaviour, closing tasks without real fixes, or refusing intake to keep the ratio healthy. Optimise throughput (more closures), abandonment (fewer ignored tasks), and gate dwell time (faster approvals). The rate follows.
Why 90 days, not quarterly?
A rolling 90-day window updates daily; a quarterly window resets every 90 days and creates artificial cliffs. Rolling is fairer for spotting trends and avoids end-of-quarter scramble gaming. Practically, 90 days is roughly equivalent to a quarter for benchmarking purposes.
My team uses Wrike for both marketing ops AND engineering. Should the rate be the same on each?
Usually no. Engineering-tagged findings close faster (median 7-12 days on a healthy workspace) than marketing-ops findings (median 14-25 days, more stakeholder review). The composite rate captures the blend; if you want per-area resolution, run Wrike’s Reports feature filtered by Custom field "OwnerGroup" to break it down. The composite is the right one for the dashboard; the breakdown is the right one for diagnosis.
The rate looks healthy but the team complains audit-fixes never ship. What is going on?
Most likely cause on Wrike: the rate counts closures, not the time they took. Rate at 75% with median time-to-fix at 24 days is technically healthy but feels slow on a daily basis. Pair the rate with the Avg Time-to-Fix sibling. If the team’s perception is “fixes are too slow”, the lever is gate dwell time, not the rate itself.