At a glance
The percentage of Vortex IQ-filed Freshdesk 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 that nobody actions?” A green reading (>75%) means audit insight is converting into shipped fixes. Amber (50-75%) means findings land but the team strains. Red (<50%) means the audit programme is broken at the people-and-process layer, not the detection layer.
| What it counts | resolved_or_closed_findings_90d / (resolved_or_closed_findings_90d + open_findings_90d) × 100, expressed as a percent of Vortex IQ-tagged tickets created in the last 90 days now in Resolved (status 4) or Closed (status 5). |
| Numerator | Tickets with tag:vortex_iq AND (status:4 OR status:5) AND created_at >= now-90d. |
| Denominator | All tickets with tag:vortex_iq AND created_at >= now-90d, regardless of state. |
| Status filter | Resolved (4) and Closed (5) count as resolved; Open (2) and Pending (3) count as unresolved. Pending is treated as unresolved because in Freshdesk that state freezes the SLA clock and on a Vortex IQ ticket usually 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-Product. Aggregated across every Freshdesk Product the connector token can read (Pro/Enterprise plans support multiple Products under one account). Set vortex_iq.product_filter to scope. |
| Resolution counts | Resolved and Closed are both counted as resolved. Freshdesk treats Closed as the immutable, archived state; Resolved is the day-to-day “fixed” state. The rate does not distinguish them. |
| Reopened tickets | If a ticket is resolved 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/tickets?query="tag:'vortex_iq' AND created_at:>{{now-90d}} AND (status:4 OR status:5)" for the numerator, then a second call for total population. The Freshdesk Search API caps at 300 results per query (10 pages × 30) so very large backlogs (rare) trigger a fallback to the bulk Tickets API with client-side filtering. |
| Bot-handled tickets | Included. Freddy AI replies do not change status by default; only a workflow or human moving the ticket to status 4/5 affects the numerator. |
| Time window | 90D rolling. Anchored on the filing date; 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, 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 Admin -> Account -> Helpdesk Settings -> Time zone. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Freshdesk 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 UK fashion SMB on Shopify running Freshdesk Growth ($15/agent/month) with two Products (Retail UK, Wholesale). Snapshot taken on 02 May 26 at 14:30 BST, looking back over the rolling 90 days from 02 Feb 26.| Bucket | Count | Notes |
|---|---|---|
| Vortex IQ tickets filed in window | 62 | Two thirds Retail UK, one third Wholesale |
| Resolved (Retail UK) | 28 | Most closed within 5 days |
| Closed (Retail UK, archived) | 6 | Resolved >7 days ago, auto-closed |
| Resolved (Wholesale) | 3 | B2B-pricing fixes, slower cycle |
| Closed (Wholesale, archived) | 1 | A single B2B SKU correction |
| Still open across both Products | 24 | Open + Pending |
| Resolution rate | (28 + 6 + 3 + 1) / 62 = 38 / 62 = 61.3% | Amber, above 50% but below 75% |
- The rate is mathematically anchored on the filing date, not the closure date. A finding filed 03 Feb 26 and closed today still counts; a finding filed 12 Mar 26 and still open today counts against. As the audit programme matures, sustaining a high rate requires disciplined triage. New customers see green easily; mature programmes work for it.
- 61% is healthy for an SMB on Freshdesk Growth. Freshdesk SMB customers typically have 2-5 agents handling everything (sales, support, audit follow-up). 61% means the team is shipping more findings than they file, which is the correct direction. The benchmark for a 3-agent SMB team is 55-70%.
- The Wholesale Product is dragging the rate. 4 closed out of an estimated 18 filed = 22% resolution. B2B teams typically have less Freshdesk discipline than retail teams (smaller queue, manual workflows, less SLA pressure). Set up a Product-specific Freshdesk view and assign a single owner for findings on that Product. On Growth plan, a workflow trigger that auto-tags the Vortex IQ Wholesale ticket and routes it to the wholesale rep is free and high-leverage.
- 24 open is a leading indicator of capacity strain, not engagement. Pair with
fre_open_tickets. If global Freshdesk 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 (a temp agent) or to enable Freddy AI auto-resolve for low-impact category findings; not to question the audit. - Reconcile with
shopify.refund_rate. If refund rate is steady or falling AND this card sits at 61%, the audit programme is paying for itself. If refund rate is climbing despite findings being closed, the team is closing the wrong findings (cosmetic ones over revenue-impacting ones). The fix is to triage by impact, not by ease. - Freshdesk’s Search API page cap (300) does not affect this card. The cap matters for the Open count. The Resolution Rate card uses the search count endpoint (single integer) so even at 1,000+ findings the rate is computed correctly. SMBs rarely exceed 300 anyway.
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 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 specifically on the audit queue. |
| 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 Freshdesk backlog context. | Both elevated equals CS team overloaded; rate dropping in isolation equals findings deprioritised specifically. |
| Avg Cycle Time | Triage-health peer for the whole queue. | 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 Freshdesk’s own dashboard: Freshdesk 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:Analytics -> Curated Reports -> Ticket Volume withFor multi-Product accounts, prepend atag = vortex_iq, group byStatus, set the date range to last 90 days. Read the percentage ofResolved + Closedagainst the total. That is the same calculation this card runs. Tickets list withtag:vortex_iqplus aStatus: Resolved or Closedfilter, gives the numerator population at a glance. Admin -> Workflows -> Ticket Filters to save the filter for future spot-checks.
Product = <name> filter.
Why our number may legitimately differ from Analytics’ number:
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Analytics 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” | Freshdesk’s Search API updates its index 30-90 seconds behind real-time ticket changes. A finding resolved seconds ago may not be in the numerator yet. Analytics is closer to real time. |
| Resolved-then-Closed transition | Either | Both states count toward the numerator here, so this transition does not move the rate; if you build an Analytics view that filters Resolved-only, you get a different number. |
| Reopened tickets | Ours lower | If a ticket was resolved then reopened in the 90-day window, we count it as unresolved at the moment of measurement. Some Analytics reports count “ever resolved” rather than “currently resolved”. |
| Multi-Product aggregation | Either | We aggregate; per-Product Analytics views are subsets. |
| Search API page cap | Negligible | The card uses the count endpoint, which is unaffected by the 300-result cap that limits the Open count card. |
| Tag inclusion | Ours stricter | We require literal tag:vortex_iq. Legacy tags (vortex, vortexiq_v1) on older tickets drop out of our population but may appear in some Analytics views. |
| Pending status semantics | Ours stricter | We treat Pending as unresolved. Some default Analytics views suppress Pending (the SLA clock is frozen). |
| 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. The denominator grew faster than the team’s closure rate. 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 temp churn. Pair with Open Tickets (all); if global backlog is also up, capacity is the answer.
- Triage-process drift. SLA on Vortex IQ-tagged tickets relaxed, or a Freddy automation turned off. Open Admin -> Workflows -> Automations and confirm the
vortex_iqrules 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 filed faster than they are closed. The audit programme is not paying for itself.
IF tag:vortex_iq:cosmetic AND Freddy confidence > 80% THEN status -> Resolved. This boosts the resolution rate honestly because the underlying issue is genuinely closed (Freddy ran a script-fix workflow, not just a canned reply).
A reopened ticket dropped my rate by 1 point. Can I exclude it?
A resolved ticket that gets reopened is genuinely no longer resolved, so the rate correctly drops. If reopens are common (>5% of resolved tickets), it points to a quality-of-fix problem, fixes are landing but not actually resolving the underlying issue.
My team uses custom statuses. How does the card classify them?
Custom statuses must be mapped to a built-in Freshdesk status (Open, Pending, Resolved, Closed). The card uses the underlying status code, not the custom label. So a custom status Awaiting Engineering mapped to Open is counted as unresolved. Confirm your mapping in Admin -> Workflows -> Ticket Fields -> Status.
My account spans 4 Products on Pro plan. Why does the gauge show a single number?
The card aggregates by default. To break out by Product, build a Stacked Panel in the Vortex IQ Nerve Centre with multiple instances, each scoped via vortex_iq.product_filter. Alternatively, build per-Product Analytics reports in Freshdesk for the same answer.
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.
We are on Freshdesk Free plan. Will this card work?
Yes, with caveats. The Free plan has a lower API rate limit (20 calls/min) and no Search API access on some tiers; the card falls back to the bulk Tickets API for accounts without Search and may show a 60-90 second refresh lag. Resolved/Closed status counting works on every Freshdesk plan including Free.
Why is the rate lower than my Zendesk friend’s?
Freshdesk SMB customers typically run smaller, less-specialised teams. The same audit programme run on Freshdesk vs Zendesk-Suite-Enterprise will see a 5-10 percentage-point gap in resolution rate purely due to team size and process maturity, not any defect in the Freshdesk product. Freshworks-owned tooling is fine; the team is the constraint.