At a glance
Of every Vortex IQ finding written to LiveAgent in the last 90 days, what percentage has been resolved. The single number that answers “is the team actually fixing the problems Vortex IQ surfaces, or is the audit just generating tickets nobody closes?”. Above 75% is healthy; below 50% means the audit pipeline is creating more work than the team can absorb.
| The formula | resolved_in_90d ÷ created_in_90d × 100, where resolved_in_90d counts tickets that moved to status = Resolved between (NOW - 90 days) and NOW (regardless of when they were created), and created_in_90d counts tickets created in the same window with tag = vortexiq-finding. |
| Why this shape, not “closed / open ratio” | A “closed vs open” snapshot ratio is heavily distorted by what is currently in the queue. Rate-over-rolling-window normalises against creation cadence, so a brand creating 50 findings/month and resolving 45 reads identically to one creating 5 and resolving 4.5. Both are healthy operations. |
| Resolution definition | status = Resolved only. We do not count Spam, Postponed, or Trashed as resolved. This is stricter than LiveAgent’s own UI, which conflates the four under “non-Open”. |
| Numerator/denominator alignment | Both windows are 90 days from NOW. A finding created 95 days ago and resolved yesterday counts in resolved_in_90d but NOT in created_in_90d. The rate can briefly exceed 100% during cleanup pushes; the card display clamps to 100%. |
| SLA-agnostic | The rate does not penalise SLA breaches. A ticket resolved 30 days late still counts as resolved. The SLA-distinct view lives in Blocked Tickets and Avg Time-to-Fix (days). |
| Departments scope | All connected departments. Multi-brand merchants who isolate by department will see findings aggregated. |
| Why 75% / 50% | Calibrated against ~12 months of merchant data: brands that maintain >75% resolution rate consistently improve revenue and SLA quarter-on-quarter. Brands below 50% accumulate technical debt that compounds. 50-75% is the working amber band where most merchants live. |
| Time window | 90D, rolling. |
| Alert trigger | <50%. |
| Sentiment | Gauge with good=75, warn=50. |
| Roles | owner, operations |
Calculation
Calculated automatically from your LiveAgent 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 35-person UK B2B parts distributor on Adobe Commerce uses LiveAgent (Large plan, 8 agents, 4 departments). Snapshot taken on 28 Apr 26 at 11:30 GMT. Window is 28 Jan 26 to 28 Apr 26. In the last 90 days:| Activity | Count | Where it sits today |
|---|---|---|
| Findings created | 71 | 49 resolved, 16 still open, 4 postponed without resolution, 2 spam-marked |
| Findings resolved (created in window) | 49 | Closed within the same 90 days |
| Findings resolved (created earlier, closed in window) | 6 | Old work cleared during a Q1 SLA-cleanup push |
| Activity | Count |
|---|---|
| Findings created | 44 |
| Findings resolved | 13 |
| Findings still open | 26 |
| Findings postponed | 5 |
Resolved. If you use custom resolution statuses, configure them in Settings → Connectors → LiveAgent → Treat as resolved.
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. | Rate 75% + Open 35 = inflow exceeds capacity; rate is healthy but absolute backlog grows. |
| VortexIQ Findings Resolved | Numerator (raw count). | 75% of 4 vs 75% of 80 are very different operations. Rate without volume = misleading. |
| Abandoned Findings (>14d no movement) | The “given up” subset. | High abandoned + low rate = abandoned is killing rate. Push abandoned first. |
| Avg Time-to-Fix (days) | Speed of closure. | Rate 80% + Time-to-Fix 18d = team closes most things, but slowly. Rate 60% + Time-to-Fix 4d = team closes fast but ducks the hard ones. |
| Blocked Tickets | SLA breach overlay. | Rate 80% + Blocked 8 = team resolves quickly when not blocked; SLA process is the issue. |
| Throughput Trend | Outflow over time. | Confirms whether resolution rate is improving, plateauing, or regressing. |
| Sprint Velocity | Engineering capacity. | Rate <50% with velocity stable = engineering is busy on non-finding work; prioritisation issue. |
| Adobe Commerce / Shopify / BC Total Revenue | Dollarised peer. | Brands maintaining >75% rate grow revenue 2-4pp faster quarter-on-quarter than peers below 50%. |
| Crisp Open Tickets | Total inbox volume (LiveAgent native). | Rate 80% + Open Tickets 250 = team is great at audit follow-up but customer queue drowning. Same team, different problem. |
Reconciling against the vendor’s own dashboard
Where to look in LiveAgent’s own dashboard: LiveAgent’s Reports → Performance module has a “Resolved by tag” report that approximates this metric. Set tag =vortexiq-finding, period = “Last 90 days”. The denominator (created in window) requires a separate query:
Tickets → Filters: Tag = vortexiq-finding, Date created (last 90 days), Status = All → count
Divide. Programmatically: GET /api/v3/tickets?_filters[tags]=vortexiq-finding&_filters[date_created][from]=<NOW-90>&_filters[status]=R for resolved-in-window, then again with [status]=All for created-in-window.
Why our number may legitimately differ from a manual LiveAgent count:
| Reason | Direction | Why |
|---|---|---|
| Resolution definition | Ours stricter | LiveAgent UI groups Resolved, Spam, Postponed, Trashed under “non-Open”. We count only Resolved. A merchant who marks low-quality findings as Spam will see LiveAgent reporting higher closure than us. |
| Custom statuses | Ours lower (default) | LiveAgent enterprise plans support custom resolution statuses (e.g., “Won’t Fix”, “Resolved by upstream”). We default to canonical Resolved only; configure custom-status mapping in our connector settings. |
| Window boundary | Negligible | Both compute on a rolling 90-day window. Sub-minute precision. |
| Numerator/denominator drift | Either, briefly | Findings created 95 days ago and resolved today count in numerator but not denominator. Rate can read >100%; clamps to 100%. |
| Time zone | Negligible | UTC vs workspace timezone shifts boundary by at most 12 hours; over 90 days the rate moves by <1pp. |
| Soft-deleted tickets | Either | Trashed tickets are excluded entirely. Restoring brings them into both numerator and denominator. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
crisp.cri_vortexiq_finding_resolution_rate / livechat.liv_vortexiq_finding_resolution_rate / tidio.tid_vortexiq_finding_resolution_rate | Definitional twins. | Multi-tool merchants should expect similar rates; very different rates indicate routing-rule asymmetry. |
zendesk.zen_vortexiq_finding_resolution_rate / freshdesk.fd_vortexiq_finding_resolution_rate | Helpdesk peers. | LiveAgent’s rate runs close to Zendesk/Freshdesk because the SLA shapes are similar. |
adobe_commerce.total_revenue / shopify.total_revenue | Statistical correlation. >75% rate over 4 quarters has shown 2-4pp faster revenue growth than peers. | Audit findings name real merchant problems; closing them removes friction. |
datadog.dd_health_score | Operations-health peer. | Different layer (live infra vs team follow-through), but brands strong on both are usually the same brands. |
Known limitations / merchant FAQs
My rate is 90% but my Open count is 35. Is that good or bad? Depends on inflow. 35 open while resolving 9/10 = creating more than 9 a week. The rate is healthy; the Open Findings absolute count is the lever to pull. Either lower inflow (turn off low-priority audit modules) or add capacity. Track both, rate alone is not enough. My rate dropped from 80% to 60% in a single week. What happened? Three usual causes. (1) A new audit module was enabled and bulk-created findings; the denominator jumped, the rate dipped temporarily; this self-corrects within 30-60 days. (2) Engineering capacity was diverted to a feature launch; throughput halved. (3) A specific finding type the team cannot resolve (e.g., third-party platform issue) is accumulating and pulling rate down. Throughput Trend shows which. How is “Resolved” different from LiveAgent’s other terminal statuses? LiveAgent has four:Resolved (work done), Spam (false positive), Postponed (deferred), Trashed (housekeeping). We count only Resolved. Bulk-marking findings as Spam to clear the queue does NOT improve this rate, which is intentional. If a finding is genuinely “won’t fix”, resolve it with a “won’t-fix” comment; that counts.
Can I exclude specific finding types from this rate?
Yes, in two ways. (1) Module level: turn off the audit module that creates them (Vortex IQ → Settings → Audit → toggle off). (2) Tag level: rename the segment from vortexiq-finding to vortexiq-deferred; they leave the count entirely.
LiveAgent supports custom resolution statuses on enterprise plans. Can I count those as resolved?
Yes. Vortex IQ → Settings → Connectors → LiveAgent → Treat as resolved. Add your custom status names (e.g., “Won’t Fix”, “Upstream Issue”). They get folded into the numerator. Default is canonical Resolved only.
Why is the rate sometimes >100% and clamped to 100%?
During cleanup pushes, when the team resolves a batch of findings created >90 days ago (outside the denominator window), the numerator includes them but the denominator does not. Rate temporarily reads >100%. We clamp display to 100% but it is a useful informal signal that a cleanup is happening.
Should the rate be 100% all the time?
No. A consistent 100% suggests findings are being closed mechanically (someone hits Resolve without fixing) rather than thoughtfully. The healthy band is 70-85%; 15-30% of findings are legitimately deferred (won’t fix, depends on platform vendor, deferred to next quarter). Below 50% is the problem zone; above 95% is a hygiene signal worth investigating.
My team uses Time Rules to auto-resolve old findings. Will that game the rate?
Yes, if the rule fires without an agent ever engaging. The rate would read healthy while the merchant problems remain. Two safeguards: (1) we exclude resolutions that have zero agent messages (we detect this via List Messages); (2) pair with Avg Time-to-Fix, bot/automation resolutions show abnormally low time-to-fix (seconds, not days), which is a tell.
Can I see this rate per agent or per department?
Not on the card itself. LiveAgent’s Reports → Performance shows per-agent and per-department resolved counts; cross-reference with Tickets by Assignee to spot the dragger. Per-department views as a card-level filter are on the roadmap.
The card refreshes every 60 seconds. Do small changes show up immediately?
Yes, but the 90-day denominator means a single resolution moves the rate by less than 1 percentage point on most merchant accounts. Bulk closures (5+ in one session) are visible within 60 seconds; one-off closures register but do not visibly move the gauge.
My LiveAgent has multiple departments. Can findings be cross-counted?
No. Each ticket is owned by exactly one department. Findings are routed to the department configured in Vortex IQ → Settings → Connectors → LiveAgent → Default findings department. The card aggregates across all connected departments; a ticket counted twice would only happen if it were duplicated manually.
Is there a “rolling 30 days” view of this rate?
Not on this card. The 90-day window was chosen because shorter windows are too noisy on smaller merchants (a brand creating 5 findings/month would have a 30-day rate that swings between 0% and 200% based on a single closure). For high-volume merchants (>10/week), the 30-day variant is on the roadmap.
Does LiveAgent’s SLA escalation count as activity for the resolution-rate calculation?
SLA escalations only update the ticket’s priority and trigger notifications; they do not move the ticket to Resolved. So no, escalations do not affect this rate. They DO affect Avg Time-to-Fix, which considers the full lifecycle from creation to resolution.
My team uses LiveAgent’s chatbot for tier-1 deflection. Does that affect this rate?
No. The chatbot operates on the Chat queue, not the Ticket queue. Findings are tickets and are not bot-deflected. If you want to enable AI-assisted resolution suggestions for findings (drafted reply text), use LiveAgent’s Suggestions feature on the Knowledge Base; the agent still has to click Resolve, so the rate is honest.