> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Finding Resolution Rate (90d), LiveChat > Finding Resolution Rate (90d) for LiveChat stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Project Management](/nerve-centre/connectors#connectors-by-type) ## 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":"","created_at_to":"","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 | The card reads **70%**. Five observations: 1. **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. 2. **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:performance` after 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. 3. **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](/nerve-centre/kpi-cards/livechat/abandoned-findings) to confirm no findings have been Pending for >14 days. 4. **Pair with [`bigcommerce.refund_rate`](/nerve-centre/kpi-cards/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. 5. **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. 6. **Reconcile with [`liv_open_tickets`](/nerve-centre/kpi-cards/livechat/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](/nerve-centre/kpi-cards/livechat/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)](/nerve-centre/kpi-cards/livechat/abandoned-findings) | 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)](/nerve-centre/kpi-cards/livechat/avg-time-to-fix) | 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)](/nerve-centre/kpi-cards/livechat/open-tickets) | 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](/nerve-centre/kpi-cards/livechat/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)](/nerve-centre/kpi-cards/shopify/refund-rate) | 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)](/nerve-centre/shopify/customer_service_sentiment) | 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](/nerve-centre/kpi-cards/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](https://my.livechatinc.com/reports/tickets/)** filtered to `tags:vortex_iq` and date range last 90 days. Read the percentage of `Solved` against `Total`. That is the same calculation this card runs. > **[Tickets list](https://my.livechatinc.com/tickets/)** with `tag:vortex_iq` plus a `status:Solved` filter, 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. **Why our number may legitimately differ from Reports' number:** | 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. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes the divergence | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) / [`bigcommerce.refund_rate`](/nerve-centre/kpi-cards/bigcommerce/refund-rate) / [`adobe_commerce.refund_rate`](/nerve-centre/kpi-cards/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`](/nerve-centre/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`](/nerve-centre/kpi-cards/datadog/operational-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. |
Documentation cross-reference (for agencies running multiple helpdesk vendors) The "Finding Resolution Rate" metric exists with the same definition on every helpdesk Vortex IQ files findings into. This is **not** a reconciliation; the merchant typically runs only one helpdesk. These references exist purely so an agency running clients across helpdesks can cross-link the same metric across docs. * [`zendesk.zen_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/zendesk/finding-resolution-rate) * [`freshdesk.fre_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/freshdesk/finding-resolution-rate) * [`gorgias.gor_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/gorgias/finding-resolution-rate) * [`helpscout.hel_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/helpscout/finding-resolution-rate) * [`intercom.int_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/intercom/finding-resolution-rate) * [`tidio.tid_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/tidio/finding-resolution-rate)
## 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. The denominator grew faster than the team's closure rate. 2. **Capacity loss.** Live chat volume spiked (BFCM, sale, viral product) and agents abandoned the Tickets channel. Pair with [Open Tickets (all)](/nerve-centre/kpi-cards/livechat/open-tickets); if global Tickets backlog is also up, capacity is the answer. 3. **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_iq` rules are still active. **Why does LiveChat have a separate Tickets product?** LiveChat treats live chat (synchronous) and tickets (asynchronous) as distinct products under one license. The chat side handles real-time customer queries; the Tickets side handles follow-ups, escalations, and async work. Vortex IQ files findings into Tickets exclusively (chat is for human conversation, not bug reports). This card therefore only ever queries the Tickets API. **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. **What is a healthy rate on LiveChat?** * 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. **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. Lower the threshold to surface more borderline issues; the rate will dip but the merchant outcome will improve. **My team uses ChatBot to handle initial chats. Does ChatBot affect this card?** Only if the bot creates Tickets tagged `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: 1. **Dedicated Ticket-mornings.** Pre-allocate the first 30 minutes of each shift to Tickets before any agent goes live in chat. 2. **Tag-routing Workflows.** Auto-route `vortex_iq:catalogue` to the merchandising lead, `vortex_iq:performance` to engineering, `vortex_iq:checkout` to the developer-on-call. Removes the "who owns this?" friction. 3. **Slack notifications on Vortex IQ tickets.** Post a Slack message to the engineering channel whenever a `vortex_iq` ticket is created. Engineers triage from Slack faster than they open the LiveChat dashboard. *** ### Tracked live in Vortex IQ Nerve Centre *Finding Resolution Rate (90d)* is one of hundreds of KPI pulses Vortex IQ tracks across LiveChat 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.