Skip to main content
Metrics type: Key MetricsCategory: Project Management

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.

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. The card reads 67%, sitting in the amber band. Three observations:
  1. 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.
  2. 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.
  3. Pair with zen_open_tickets for 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.
  4. 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.
  5. 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.
  6. 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

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 with Tag = vortex_iq filter, group by Ticket status, and constrain Created at to the last 90 days. Read the percentage of Solved + Closed against the total. That is the same calculation this card runs. Search bar with tags:vortex_iq created>{{ago_90_days}} status:solved returns 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.
For multi-brand accounts, repeat the query inside each brand subdomain or filter by brand_id in Explore. Why our number may legitimately differ from Explore’s number: Cross-connector reconciliation:

Known limitations / merchant FAQs

The rate dropped 15 points this week. What changed? Three usual causes, in order of likelihood:
  1. 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.
  2. 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.
  3. 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_iq automations are still active.
A finding closed today but it was filed 95 days ago. Does it count? No. The window is anchored on the filing date, not the closure date. A ticket filed outside the 90-day window does not appear in the denominator at all, even if it just closed. This avoids “closed an old ticket today” gaming the metric. What is a healthy rate?
  • 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.
Should I optimise for a higher rate? Not necessarily. A rate above 90% sustained for a quarter often means the audit thresholds are too generous (finding only obvious issues). Lower the audit threshold to surface more borderline issues; the rate will dip but the merchant outcome (lower refund rate, lower customer-service load) will improve. Why does the rate sometimes climb without anyone closing tickets? Older findings drop out of the 90-day window over time. A finding filed 91 days ago that was open yesterday is silently removed from the denominator today. This is correct behaviour but can confuse merchants who expect the gauge to be motion-tied. Do not chase 1-2 point movements; look at the trend over a 14-day window. Solved vs Closed, do they both count? Yes. Zendesk auto-transitions Solved tickets to Closed after 28 days, and both states are immutable from the agent UI. This card treats them identically. If you want a Solved-only view (excluding archived Closed), build a custom Explore query. A reopened ticket dropped my rate by 1 point. Can I exclude it? A solved ticket that gets reopened is genuinely no longer resolved, so the rate correctly drops. If reopens are common (>5% of solved tickets), it points to a quality-of-fix problem, fixes are landing but not actually resolving the underlying issue. Triage why reopens are happening before excluding them. My team uses Sunshine custom statuses. How does the card classify them? Custom statuses must be mapped to a built-in Zendesk status group (Open, Pending, Solved, Closed). The card uses the underlying group, not the custom label. So a custom status 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.

Tracked live in Vortex IQ Nerve Centre

Finding Resolution Rate (90d) is one of hundreds of KPI pulses Vortex IQ tracks across Zendesk and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.