At a glance
The percentage of Vortex IQ-filed Zendesk tickets that the merchant team has actually closed in the last 90 days. Designed to answer the merchant question: “is the audit programme working, or am I paying for findings nobody actions?” A green reading (>75%) means audit insight is converting into shipped fixes. Amber (50-75%) means findings are landing but the team is straining. Red (<50%) means the audit programme is broken at the people-and-process layer, not the detection layer.
| What it counts | solved_or_closed_findings_90d ÷ (solved_or_closed_findings_90d + open_findings_90d) × 100, expressed as a percent of Vortex IQ-tagged tickets created in the last 90 days that are now in a Solved or Closed state. |
| Numerator | Tickets with tags:vortex_iq AND status:solved OR status:closed AND created_at >= now-90d. |
| Denominator | All tickets with tags:vortex_iq AND created_at >= now-90d, regardless of state. |
| Status filter | Solved and Closed count as resolved; New, Open, Pending, On-hold count as unresolved. Pending is treated as unresolved because on a Vortex IQ ticket it almost always means “waiting on a developer”, not “waiting on a customer”. |
| Issue type filter | All Vortex IQ-tagged tickets included. The category sub-tags (vortex_iq:catalogue, vortex_iq:checkout, vortex_iq:performance, vortex_iq:seo) do not filter the rate; they exist for breakdown views. |
| Project / board scope | Cross-brand. Aggregated across every Zendesk brand the connector token can read. Set vortex_iq.brand_filter in the connector config to scope to a single brand. |
| Resolution counts | Solved and Closed are both counted as resolved. Zendesk treats Closed as the immutable, archived state (no further updates allowed); Solved is the day-to-day “fixed” state. The rate does not distinguish them. |
| Reopened tickets | If a ticket is solved then reopened within 90 days, it counts as unresolved at the moment of measurement. The rate is recalculated each refresh. |
| API endpoint | GET /api/v2/search/count.json?query=tags:vortex_iq created>{{now-90d}} status<solved for the open count, then a second call for solved+closed. Search count endpoint is fast (single integer response) so the gauge refreshes every 60 seconds without rate-limit pressure. |
| Time window | 90D rolling. Changes to recent tickets back-pressure the rate; an old finding closed today does NOT count if it was filed more than 90 days ago. |
| Alert trigger | <50%. At 50% you are leaving as many findings open as you close, which is the point at which the backlog grows faster than the team clears it. |
| Sentiment thresholds | Good >= 75%, warn 50-75%, critical <50%. |
| Time zone | Account timezone in Zendesk Admin Centre -> Account -> Localisation; rolling 90-day window uses that boundary. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Zendesk 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 mid-market home and kitchen brand on Adobe Commerce running Zendesk Suite Professional with three brands (US, Canada, Wholesale). Snapshot taken on 02 May 26 at 09:55 PT, looking back over the rolling 90 days from 02 Feb 26.| Bucket | Count | Notes |
|---|---|---|
| Vortex IQ tickets filed in window | 84 | Roughly one a day across three brands |
| Solved (US retail) | 39 | Triaged within 7-day SLA |
| Closed (US retail, archived) | 7 | Solved >28 days ago and auto-closed |
| Solved (Canada retail) | 8 | French-localisation findings batched |
| Closed (Wholesale) | 2 | B2B-pricing fixes shipped in last sprint |
| Still open across all brands | 28 | New, Open, Pending, On-hold |
| Resolution rate | (39 + 7 + 8 + 2) / 84 = 56 / 84 = 66.7% | Amber, above 50% but below 75% |
- The rate is mathematically anchored on the filing date, not the closure date. A finding filed on 03 Feb 26 and closed today still counts; a finding filed 12 Mar 26 and still open today counts against. So the rate becomes harder to keep green as the audit programme gets older and findings accumulate. New customers see green easily; mature programmes need disciplined triage.
- 66.7% is the industry benchmark for project-management-style backlogs. Below 50% means findings are filed faster than they ship; above 75% means the team has slack. The sweet spot for an audit programme is 60-80%, where Vortex IQ is filing enough findings to keep the team busy but not so many it drowns them. If the rate stays above 90% for a full quarter, consider lowering the audit threshold (more findings filed) because the team has capacity.
- Pair with
zen_open_ticketsfor context. If the global Zendesk backlog is also above the team’s normal mark, this rate dropping is symptomatic of CS overload, not of audit-programme failure. The action is to add capacity, not to question the audit. Conversely, if global tickets are flat but Vortex IQ rate is dropping, the team is deprioritising findings in favour of live customer work, which is a different (and harder) conversation. - The Wholesale brand is dragging the rate. 2 closed out of 12 filed = 17% resolution. B2B teams typically have less Zendesk discipline than retail teams (smaller queue, manual workflows, less SLA pressure). Set up a brand-specific Zendesk view (Admin Centre -> Views -> “Vortex IQ findings, Wholesale”) and assign a single owner for findings on that brand.
- The Canada brand is a positive signal. 8 solved out of an estimated 14 filed = 57%, despite localisation work usually taking longer. The team batched French-translation findings into a single sprint, which is the correct pattern: Vortex IQ findings cluster by category, batching them by category compresses the cycle time.
- Reconcile with
shopify.refund_rate(or Adobe equivalent). If refund rate is steady or falling AND this card is at 67%, the audit programme is paying for itself; the dropped findings are probably the lower-impact ones. If refund rate is climbing despite findings being closed, the team is closing the wrong findings (cosmetic ones over revenue-impacting ones).
Sibling cards merchants should reference together
| Card | Why pair it with Finding Resolution Rate | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | The unresolved-count denominator-side counterpart. | Open count high + resolution rate low equals findings filed but never closed, the worst possible state. |
| Abandoned Findings (>14d no movement) | The “silent-leak” subset. Abandoned findings are guaranteed denominators with no numerator contribution. | Abandoned rising while this rate falls equals the team is losing ground on the audit queue specifically. |
| Avg Time-to-Fix (days) | Cycle-time peer. The rate tells you whether findings close; this tells you how fast once they do. | Rate green + time-to-fix slow equals team eventually ships but late; rate red + time-to-fix fast equals team ships some quickly and abandons the rest. |
| Open Tickets (all) | Total Zendesk backlog context. | Both elevated equals CS team overloaded across the board; rate dropping in isolation equals findings deprioritised specifically. |
| Avg Cycle Time | Triage-health peer for the whole queue, not just findings. | Cycle time creeping up while this rate falls equals systemic triage breakdown. Inspect Top Assignees Overloaded. |
| Refund Rate (Shopify / BigCommerce / Adobe) | The downstream truth metric an audit programme should protect. | Refund rate flat or falling + rate at 60%+ equals the programme is paying for itself; refund rate climbing despite high resolution rate equals team is closing low-impact findings. |
| Customer Service Sentiment (Shopify) | The retention-side outcome of running this programme well. | Rate climbing + sentiment climbing equals the audit story works for the CXO; the “Vortex IQ pays for itself” narrative. |
| Datadog Operational Health Score | Sibling-platform health score for technical findings. | Datadog health green + this rate green equals the team is keeping pace with both reliability and audit work. Healthy engineering culture indicator. |
Reconciling against the vendor’s own dashboard
Where to look in Zendesk’s own dashboard: Zendesk does NOT provide a single “tag-scoped resolution rate” gauge, so this card is computed by Vortex IQ from the Search API. To verify it manually:Admin Centre -> Reporting -> Explore -> Tickets dataset. Build a query withFor multi-brand accounts, repeat the query inside each brand subdomain or filter byTag = vortex_iqfilter, group byTicket status, and constrainCreated atto the last 90 days. Read the percentage ofSolved + Closedagainst the total. That is the same calculation this card runs. Search bar withtags:vortex_iq created>{{ago_90_days}} status:solvedreturns the numerator population; remove the status filter for the denominator population. Views -> Vortex IQ findings, Solved (90d) if you have set up a saved view, gives the count for the numerator at a glance.
brand_id in Explore.
Why our number may legitimately differ from Explore’s number:
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Explore honours the dataset’s configured timezone; the card uses the account-level timezone for the rolling 90-day window. For a 90-day window the gap is usually <1%. |
| Search API index lag | Ours lower for “just now” | The Zendesk Search API updates its index 30-90 seconds behind real-time ticket changes. A finding solved seconds ago may not be in the numerator yet. Explore is closer to real time. |
| Closed-after-solved transition | Either | Zendesk auto-transitions Solved tickets to Closed after 28 days. Both states count toward the numerator here, so this transition does not move the rate; if you build an Explore view that filters Solved-only, you get a different number. |
| Reopened tickets | Ours lower | If a ticket was solved then reopened in the 90-day window, we count it as unresolved. Some Explore reports count “ever solved” rather than “currently solved”. |
| Multi-brand aggregation | Either | We aggregate; per-brand Explore views are subsets. |
| Search count-endpoint cap | Negligible | The count endpoint returns the integer regardless of result set size, so there is no Search-API page cap effect on this card (unlike the open-count card). |
| Tag inclusion | Ours stricter | We require literal tags:vortex_iq. If you have legacy tags (vortex, vortexiq_v1) on older tickets, those drop out of our population but may appear in some Explore views. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
shopify.refund_rate / bigcommerce.refund_rate / adobe_commerce.refund_rate | Inverse correlation. Higher resolution rate should reduce refund rate over a 4-8 week trailing window. | Resolution rate up + refund rate up equals team is closing low-impact findings; resolution rate down + refund rate down equals findings were duplicates or stale. |
shopify.customer_service_sentiment | Positive correlation, 2-4 week lag. | Sustained 70%+ resolution rate predicts CSAT lift of 2-4 points within a quarter. The retention-side payoff. |
datadog.dd_health_score | Independent peer; correlates only when the audit is dominantly technical. | Both green equals balanced engineering culture; technical findings closing fast and reliability holding. |
Known limitations / merchant FAQs
The rate dropped 15 points this week. What changed? Three usual causes, in order of likelihood:- Audit volume up. Vortex IQ filed more findings than usual (a fresh catalogue audit, a payment-funnel audit, a SEO sweep). The denominator grew faster than the team’s closure rate. Check the findings filed in the last 7 days trend in the VortexIQ Findings Open card. Often resolves itself within 2-3 weeks as the team clears the new findings.
- Capacity loss. A senior agent on holiday, a key engineer focused on a feature deploy, or a temp churn. Pair with Open Tickets (all); if the global backlog is also up, capacity is the answer. Add temp capacity, do not panic about audit health.
- Triage-process drift. SLA on Vortex IQ-tagged tickets relaxed, or a workflow rule turned off. Open Admin Centre -> Workflows -> Triggers and confirm the
vortex_iqautomations are still active.
- 75%+ : healthy. Audit programme is working; team has slack.
- 60-75% : normal for a maturing programme. Acceptable.
- 50-60% : warn. Team is straining; investigate triage process.
- <50% : critical. Findings are being filed faster than they are closed. The audit programme is not paying for itself.
Awaiting Engineering mapped to Open is counted as unresolved. Confirm your mapping in Admin Centre -> Workflows -> Ticket Statuses.
My account spans three brands. Why does the gauge show a single number?
The card aggregates by default. To break out by brand, build a Stacked Panel in the Vortex IQ Nerve Centre with three instances, each scoped to a single brand via vortex_iq.brand_filter in the connector config. Alternatively, build three Explore queries in Zendesk for the same answer.
Does this card include findings filed via Talk (phone) or Chat?
Vortex IQ files findings only via API, so all Vortex IQ-tagged tickets enter via the API channel. The card does not filter by channel; it filters by tag. Talk and Chat tickets without the vortex_iq tag are excluded from both the numerator and denominator (they are not findings).
Reopen-rate is rising AND this card is dropping. What is the play?
Both falling together is the strongest signal that the team is closing tickets prematurely under SLA pressure rather than actually shipping fixes. Sit with the engineering lead and tighten the definition-of-done on Vortex IQ tickets; require a code-deploy reference or a screenshot in the closing comment.
Why is the alert threshold 50% and not 70%?
50% is the breakeven point at which the team is closing one finding for every one filed. Below 50% the backlog grows mathematically; above 50% it shrinks. A 70% threshold would over-page in the first quarter of any new audit programme, when finding volume legitimately exceeds team capacity by design. You can tune the threshold per organisation in Vortex IQ -> Settings -> Alerts.