At a glance
The percentage of Vortex IQ-filed LiveChat 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?” LiveChat (the LiveChat Inc product) is the longest-established standalone live-chat platform; it pairs the chat product with a separate Tickets product for asynchronous follow-up. Vortex IQ files findings into the Tickets product, not the chat stream, so this card reads against the Tickets API regardless of how heavy the merchant’s chat use is.
| What it counts | solved_findings_90d / (solved_findings_90d + open_findings_90d) × 100, expressed as a percent of Vortex IQ-tagged tickets created in the last 90 days now in Solved status. |
| Numerator | Tickets with tags includes "vortex_iq" AND status:solved AND created_at >= now-90d. |
| Denominator | All tickets with tags includes "vortex_iq" AND created_at >= now-90d, regardless of state. |
| Status filter | LiveChat’s Tickets product has three statuses: Open, Pending, Solved. Solved counts as resolved; Open and Pending count as unresolved. Pending in LiveChat means “waiting for the customer reply”; on a Vortex IQ ticket it usually means waiting on a developer, so still unresolved. |
| 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 | Single LiveChat license. Multi-license accounts (rare; usually used for separate brands) connect each license as a separate Vortex IQ instance. |
| ChatBot-handled tickets | If the merchant uses LiveChat’s bundled ChatBot product to convert chats to tickets, those tickets count if they carry the vortex_iq tag (rare; Vortex IQ files via API directly to Tickets). |
| Reopened tickets | If a ticket is solved then reopened, it counts as unresolved at the moment of measurement. |
| API endpoint | LiveChat Reports API: POST /v3.5/reports/tickets/list with body {"query":{"tags":["vortex_iq"],"created_at_from":"<now-90d>","created_at_to":"<now>","status":"solved"}}. Page size 100 with cursor pagination; Reports API is rate-limited at 180 req/min on Team plan, higher on Business/Enterprise. |
| 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 Settings -> General -> Timezone. |
| Roles | owner, operations |
Calculation
Calculated automatically from your LiveChat 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 home and garden brand on BigCommerce running LiveChat Business with the bundled ChatBot enabled and 4 agents covering UK office hours. Snapshot taken on 02 May 26 at 15:40 BST, looking back over the rolling 90 days from 02 Feb 26.| Bucket | Count | Notes |
|---|---|---|
| Vortex IQ tickets filed in window | 53 | Files via API to a “vortex_iq” group |
| Solved by agent | 32 | Standard triage |
| Solved by ChatBot escalation flow | 1 | Rare; bot only solves shipping queries |
| Solved by Workflow auto-resolve | 4 | Bulk-resolved at quarter-end after fix-deploy |
| Pending (waiting on dev) | 6 | Engineering sprint backlog |
| Open | 10 | Active findings |
| Resolution rate | (32 + 1 + 4) / 53 = 37 / 53 = 69.8% | Amber, healthy mid-range |
- 70% is healthy for a 4-agent UK SMB on LiveChat. The Tickets product is the asynchronous side-channel; agents who live in the chat stream sometimes neglect Tickets. 70% indicates the team has discipline around the Vortex IQ tag specifically. Mature programmes on LiveChat hit 75-80%; new programmes start in the low 60s.
- The 4 Workflow auto-resolves at quarter-end is a real pattern. LiveChat lets you trigger workflow rules from the Tickets product. A “bulk-solve everything tagged
vortex_iq:performanceafter the perf-fix deploy” workflow is legitimate; it closes findings that the deploy actually fixed. The honesty test: did the deploy fix the underlying issue? If yes, the closures are real; if no, the rate is inflated. - 6 Pending tickets is the leading indicator of capacity strain. LiveChat Pending freezes the SLA clock the same way Freshdesk does, so Pending findings age quietly. Pair with Abandoned Findings to confirm no findings have been Pending for >14 days.
- Pair with
bigcommerce.refund_rate. If refund rate is steady or falling AND this card sits at 70%, the audit programme is paying for itself. If refund rate is climbing despite findings being closed, the team is closing the wrong findings. - LiveChat’s chat-first culture means agents are time-poor for ticket triage. Live chats during UK trading hours can hit 80-150/day per agent; Vortex IQ tickets get worked when chat volume drops (lunch lulls, evenings). This is why the Workflow auto-resolve pattern matters so much: it lets the team batch-process by category. Set up a Workflow per
vortex_iq:sub-tag so agents do not have to triage one-by-one. - Reconcile with
liv_open_tickets. If global LiveChat Tickets backlog is also above the team’s normal mark, this rate dropping is symptomatic of overall ticket-channel neglect (the team is in chats), not of audit-programme failure. The fix is to dedicate one agent’s morning to Tickets, not to question the audit.
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. Pending findings on LiveChat age the same way Freshdesk Pending does. | 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 LiveChat Tickets backlog context. | Both elevated equals Tickets channel under-attended (team in chats); 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. |
| Refund Rate (Shopify / BigCommerce / Adobe) | The downstream truth metric an audit programme should protect. | Refund rate flat or falling + rate at 65%+ 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 founder. |
| 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. |
Reconciling against the vendor’s own dashboard
Where to look in LiveChat’s own dashboard: LiveChat does NOT provide a single “tag-scoped resolution rate” gauge, so this card is computed by Vortex IQ from the Reports API. To verify it manually:Reports -> Tickets filtered toWhy our number may legitimately differ from Reports’ number:tags:vortex_iqand date range last 90 days. Read the percentage ofSolvedagainstTotal. That is the same calculation this card runs. Tickets list withtag:vortex_iqplus astatus:Solvedfilter, gives the numerator population at a glance. [Saved filter -> “Vortex IQ findings, solved (90d)”] if you have set one up, gives the count without re-typing the filter.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Reports honours the account’s configured timezone; the card uses the same timezone but rounds the rolling 90-day window to UTC midnight for cross-connector arithmetic. Sub-1% gap. |
| API replication lag | Ours lower for “just now” | LiveChat’s Reports API replicates the database 5-30 seconds behind real-time ticket changes. A finding solved seconds ago may not be in the numerator yet. |
| Reopened tickets | Ours lower | If a ticket was solved then reopened in the 90-day window, we count it as unresolved. Some Reports views count “ever solved” rather than “currently solved”. |
| Tag inclusion | Ours stricter | We require literal tags includes "vortex_iq". Legacy tags drop out of our population. |
| Pending status semantics | Ours stricter | We treat Pending as unresolved. Some default Tickets views suppress Pending (the SLA clock is frozen). |
| Workflow auto-resolve | Same | We count Workflow-rule-resolved tickets the same as agent-resolved (both move status to Solved). Some Reports views break them out separately. |
| Chat-to-Ticket conversions | Same | Tickets created from chat sessions count if they carry the vortex_iq tag (rare; Vortex IQ files via API directly). |
| Multi-license | Either | If the merchant runs multiple LiveChat licenses, each is a separate Vortex IQ instance; the card does not cross-aggregate. |
| 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.
- Capacity loss. Live chat volume spiked (BFCM, sale, viral product) and agents abandoned the Tickets channel. Pair with Open Tickets (all); if global Tickets backlog is also up, capacity is the answer.
- Workflow drift. A LiveChat Workflow rule that auto-tagged or auto-routed Vortex IQ tickets turned off. Open Settings -> Automate -> Workflows and confirm the
vortex_iqrules are still active.
- 75%+ : healthy. Audit programme is working; team has slack on the Tickets side.
- 60-75% : normal for a maturing programme.
- 50-60% : warn. Team is in chats and neglecting Tickets; investigate.
- <50% : critical. Findings are filed faster than closed; the Tickets channel is being abandoned.
vortex_iq (rare; the bot’s tickets tend to be order-status follow-ups, not audit findings). If it does, those tickets are counted alongside agent-created ones.
Pending tickets are dragging my rate. Why count them as unresolved?
LiveChat Pending freezes the SLA clock the same way Freshdesk Pending does. On a Vortex IQ ticket “pending” usually means “waiting for the developer to respond”, not “waiting for the customer”. We count it as unresolved to surface that aging honestly.
A reopened ticket dropped my rate. 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.
Workflow auto-resolved 4 tickets at quarter-end. Is that gaming the metric?
Not if the underlying issues were genuinely fixed. A perf-fix deploy that resolves a category of findings (e.g., all vortex_iq:performance tickets) is legitimately solved by the deploy; the Workflow rule just batches the closure paperwork. The honesty test: open three of those auto-resolved tickets at random and verify the underlying issue is fixed in production. If yes, the rate is honest; if no, the rate is inflated.
My account spans two LiveChat licenses (one per brand). Why a single number?
The card does not cross-aggregate licenses. Each license is a separate Vortex IQ connector instance. To see a single number across both, build a Stacked Panel in the Nerve Centre with both instances panelled side-by-side and compute the weighted average manually.
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; above 50% it shrinks. A 70% threshold would over-page in the first quarter of any new audit programme.
My agents live in chats. How do I get them to triage Tickets?
Three patterns that work:
- Dedicated Ticket-mornings. Pre-allocate the first 30 minutes of each shift to Tickets before any agent goes live in chat.
- Tag-routing Workflows. Auto-route
vortex_iq:catalogueto the merchandising lead,vortex_iq:performanceto engineering,vortex_iq:checkoutto the developer-on-call. Removes the “who owns this?” friction. - Slack notifications on Vortex IQ tickets. Post a Slack message to the engineering channel whenever a
vortex_iqticket is created. Engineers triage from Slack faster than they open the LiveChat dashboard.