At a glance
The percentage of VortexIQ findings created in the last 90 days that have been resolved (Asana task marked complete). It is the team’s batting average against the audit programme. Below 50% the team is falling behind; above 75% the team is matching or beating intake. This is the single number that compresses Findings Open, Abandoned, and Time-to-Fix into one merchant-readable score.
| The formula | resolved_in_window ÷ created_in_window, where resolved_in_window counts Asana tasks with vortexiq_finding_id and completed = true and completed_at within the 90-day window, and created_in_window counts tasks with vortexiq_finding_id and created_at within the same window. |
| API endpoints | GET /tasks paged with opt_fields=created_at,completed,completed_at,custom_fields. We bucket by vortexiq_finding_id to avoid double-counting if a finding was re-created. |
| Window | Rolling 90 days, refreshed hourly. Real-time refreshes happen on every webhook event for the live count, but the rate calculation is hourly to smooth out single-task volatility. |
| What “resolved” means | Asana completed = true. We do not separately count “Won’t Do” closures (Asana represents these as completed tasks regardless of section), so a finding closed as “Won’t Do” counts as resolved. This is intentional: from the audit programme’s perspective, both decisions (fix it, decide not to fix it) are resolutions. |
| Project / workspace scope | All vortex_iq_outbound projects across all connected Asana workspaces. |
| Archived projects | Excluded from both numerator and denominator. |
| Time zone | UTC for both created_at and completed_at. The 90-day window aligns to UTC. |
| Alert trigger | < 50% raises a critical alert. The 50% threshold reflects the empirical break-even point: below 50% the open queue compounds week-over-week; above 50% it stabilises. |
| Sentiment thresholds | Gauge: green ≥ 75%, amber 50-74%, red < 50%. |
| Multi-workspace aggregation | Yes, computed on the summed numerator and denominator across all connected workspaces. Per-workspace stack panel available. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Asana 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 specialty-coffee DTC brand on Shopify, marketing-led, 12-person team. Asana is the team’s primary planning tool. Snapshot taken on 02 May 26 at 10:30 BST.| Last 90 days (02 Feb 26 - 02 May 26) | Count |
|---|---|
Findings created (Asana tasks with vortexiq_finding_id, created_at in window) | 84 |
Findings resolved (above set, AND completed = true, completed_at in window) | 53 |
| Findings still open from window | 26 |
| Findings re-opened during window | 5 (counted once in numerator, on first close) |
- 63% sits in the amber band (50-74%). Above the alarm threshold but below the green-zone target. The team is closing more than it is opening, but slowly enough that the open queue shrinks by only one task per week net. Acceptable, not great.
- The open queue will not collapse to zero. At 63% resolution rate, expect roughly 30-40 open findings as a steady-state, anything beyond that is the team falling behind, anything below it is the audit programme finding less than usual.
- Pair this card with Avg Time-to-Fix. A 63% rate with a 7-day mean time-to-fix is healthy; a 63% rate with a 28-day mean time-to-fix means the team is closing easy items and stalling on hard ones.
- Compare against Findings Open trend. If open count is rising for three weeks while resolution rate sits at 63%, the audit programme is producing more findings than the team can absorb, a calibration issue with the audit, not a team problem.
- The team should aim for 75% sustained. Below 50% is alarm territory; above 75% means the team is keeping up with intake. Most healthy mid-market merchants live at 65-80% on a marketing-led PM tool like Asana. Engineering-led tools like Linear typically run higher (80-90%) because engineering teams have stricter completion definitions.
Sibling cards merchants should reference together
| Card | Why pair it with Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | Resolution rate’s denominator-half. Open count grows when this rate falls. | Falling rate + climbing open count = capacity bottleneck; falling rate + flat open count = audit programme is finding less. |
| Abandoned Findings (>14d) | Tasks that count as denominators but never become numerators. | High abandoned + low rate = execution discipline gap; low abandoned + low rate = the team is engaged but underwater. |
| Avg Time-to-Fix (days) | Time-to-fix is the cycle time inside this rate. | High rate + low time-to-fix = excellent; high rate + high time-to-fix = the team is closing items eventually but slowly. |
| Tickets Resolved (7d) | Short-window throughput of all tasks (not just findings). | If overall throughput is high but findings rate is low, audit work is being deprioritised. |
| Sprint Velocity (avg) | Velocity is the team’s capacity ceiling. | A flat rate with rising velocity = the audit work isn’t reaching sprints. |
| Throughput Trend | Tells you whether the team’s pace is accelerating or decelerating. | A rate dipping while throughput climbs = a deliberate prioritisation away from audit work. |
| Sprint Progress | Whether findings are getting committed to the current sprint. | Low sprint progress + low rate = findings are queued but never pulled in. |
Reconciling against the vendor’s own dashboard
Where to look in Asana’s own UI:app.asana.com then for eachAsana does not natively expose a single resolution-rate number; the closest is the Tasks completed vs Tasks created twin chart in Reporting. The arithmetic is the same as ours. Why our number may legitimately differ from Asana’s Reporting twin chart:vortex_iq_outboundproject open Reporting (formerly Dashboards) and add a Tasks completed chart filtered byCustom Fields → vortexiq_finding_id → is set, with the time range set to Last 90 days. The Asana Goals module also surfaces a similar completion-rate gauge for projects with goals defined; the math is comparable.
| Reason | Direction | Why |
|---|---|---|
| Window definition | Either | Asana’s Reporting “Last 90 days” rolls daily at midnight in your account-profile timezone; our window rolls hourly in UTC. For a number that updates hourly the difference is small, but if you check at 23:00 local one day and 00:30 local the next, Asana’s denominator may shift by a calendar day. |
| Re-created findings | Ours lower | If a finding was closed, re-opened, and closed again within 90 days, Asana’s chart counts both completion events; we count once per vortexiq_finding_id. The duplicate-suppression makes our rate slightly lower if your team has a habit of re-opening. |
| Won’t Do treatment | Same | Both Asana’s Tasks completed chart and our card count completed = true regardless of whether the resolution was “Done” or “Won’t Do”. |
| Archived projects | Ours lower | Asana Reporting can include archived projects; we exclude them. Confirm filter parity. |
| Sub-task creation | Ours lower | Asana’s chart counts sub-tasks separately if the chart query includes sub-tasks; we count parent tasks only because that is where the vortexiq_finding_id lives. |
| Cross-workspace aggregation | Ours wider | Asana Reporting scopes to one workspace; we sum across all connected workspaces. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
datadog.dd_health_score | Independent. Datadog Health is server-side production health; Asana resolution rate is internal team operations. They reflect different layers of the same merchant. | A high Datadog Health Score with a low Asana resolution rate means production is fine but the team is falling behind on the work that prevents future regressions. The cause-and-effect lag is typically 2-6 weeks. |
newrelic.nr_apdex | Same shape as Datadog comparison. | Same lag. |
Known limitations / merchant FAQs
My Asana Reporting chart shows 71% completed but you say 63%. What’s wrong? Eight points of gap is normal. The usual reasons in order: (1) Re-opened tasks: Asana counts each completion event, we count once per finding-id. If your team frequently re-opens, our number is the more conservative one. (2) Cross-workspace aggregation: we sum across multiple workspaces; check whether Asana’s chart was filtered to one workspace. (3) Window-rolling timezone (UTC vs profile-timezone). Open the per-workspace stack panel and the gap usually closes to within 2-3 points. Does “Won’t Do” count as resolved? Yes. From the audit programme’s perspective, both decisions are resolutions: the team chose to close the loop. If you want to track them separately, see the upcoming Won’t Do Rate card on the backlog. We treat them as identical here because over-counting “Won’t Do” closures (e.g. only counting “Done” status) discourages teams from cleanly closing low-value findings, which is the worst outcome. Our rate sits at 45%. Should I be concerned? Yes. Below 50% is the alarm threshold for a reason: the open queue compounds week-over-week and abandonment rate climbs in the following weeks. The standard playbook is the four-card investigation: open this card, Findings Open, Abandoned Findings, and Tickets by Assignee side-by-side. Within 5 minutes you’ll know if it’s a single-assignee bottleneck (most common), a sprint-planning bottleneck, or a calibration issue with the audit programme. We use multiple Asana workspaces. Which workspace’s rate matters most? The one with the lowest rate is the leading indicator. Open the per-workspace stack panel from the connector drawer to see them broken out. Marketing-led workspaces typically run lower than engineering-led ones; if your marketing-ops workspace sits at 50% while your site-reliability workspace sits at 90%, that’s normal and not actionable on its own. Task velocity dropped this week, rate is still high. What’s happening? This is the “team closed everything easy and left the hard stuff” pattern. Open Avg Time-to-Fix, if mean cycle time climbed alongside the velocity drop, the team has finished the quick-wins and is now starting on the heavier findings. This is a healthy phase that lasts 1-3 weeks; rate will dip during it then recover. Worry only if the dip lasts longer. Today’s rate looks volatile. Why? At low resolution volumes the rate is sensitive: 5 resolutions out of 8 is 62.5% and one extra close moves it to 75%. The 90-day window makes daily volatility small but visible. The 7-day moving rate (shown on the trend line beneath the headline) is less noisy. Multi-team reporting: how do I see resolution rate by team within one workspace? Asana’steam_gid is exposed in the API. The per-team stack panel is on the roadmap; until then, the workaround is to use one Asana project per team, tag each project as a separate vortex_iq_outbound route in connector setup, and the per-project stack will reflect per-team breakdown.
Is Asana the right tool for tracking this metric?
For ecommerce ops teams that span marketing, catalogue, CX, and engineering-light work, yes. Asana’s custom-fields + portfolios combination is uniquely suited to this use case. Engineering-only teams will find Linear’s velocity-and-cycle-time machinery more native. Visual-first teams will find Monday’s board view easier to scan. ClickUp’s strength here is per-task time-tracking which we don’t currently consume; Trello’s strength is its lightness which makes it under-equipped for this metric. Basecamp’s project-room model lacks completion-event granularity, so its rate calculation is the noisiest of the six.
Resolution rate climbed but I don’t think the team did anything different. What changed?
Three usual causes. (1) Audit programme produced fewer findings this period (denominator shrank, rate climbed). Check Findings Open trend. (2) A bulk closure of stale findings (e.g. the team did an “abandoned review” and closed 20 as Won’t Do). Check Asana’s audit log under Admin Console. (3) Project archiving: if a project was archived this week, all its open findings dropped out of the denominator while the resolved count stayed; this can lift rate by 5-10 points overnight.