Tickets we created from audit findings that haven’t been resolved yet.
At a glance
The count of LiveChat (LiveChat Inc, Polish vendor) Tickets that Vortex IQ opened from a Nerve Centre audit finding (broken checkout, slow PDP, payment-form regression, conversion-widget misconfiguration, etc.) and the merchant’s team has not yet resolved. LiveChat is a longest-established standalone live-chat product with a strong Tickets module that is shaped for async work, separate from the chat queue.
| What it counts | Items in your LiveChat Tickets module (not the Chats queue) tagged vortexiq-finding whose status is in (open, pending). Each finding is one ticket. |
| Tickets vs Chats | LiveChat clearly separates Chats (real-time conversations with shoppers) from Tickets (async, email-shaped follow-ups). Findings are written as Tickets because they need an audit trail and asynchronous follow-up. The Chats queue is excluded entirely so customer chat does not pollute the count. |
| Why this matters for ecommerce | LiveChat is a leading conversion-lift tool for Shopify and BigCommerce; live-chat-engaged sessions convert at 2-3× the rate of non-engaged. Audit findings that affect the chat widget (load delay, mobile rendering, pre-purchase trigger rules) directly impact revenue, the merchant should triage these fastest. |
| Status definition | open (new or replied-to without resolution) and pending (awaiting customer or third-party) both count. solved, closed, and spam do not. |
| Group scope | All connected LiveChat groups. Merchants who isolate by group (e.g., Sales group vs Support group) will see findings aggregated unless filtered. The recommended setup is a dedicated engineering group for vortexiq-finding tickets. |
| Multi-license note | LiveChat allows multiple licenses on one account (typically one per brand). Findings are scoped to a single license, configured in Vortex IQ → Settings → Connectors → LiveChat → Default license. Cross-license aggregation is on the roadmap. |
| Time window | RT, refreshed every 60 seconds via the LiveChat List Tickets endpoint (POST /v3.5/agent/action/list_tickets). |
| Alert trigger | >20 open. The threshold above which the backlog stops being a working list and becomes a graveyard. |
| 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 US fashion brand on Shopify Plus uses LiveChat (Business plan, 6 agents, two groups:chat-pre-sales and support). The pre-sales group runs the LiveChat widget on PDPs and checkout for cart-abandonment recovery and is responsible for ~18% of attributed revenue. Snapshot taken on 28 Apr 26 at 14:00 EST.
The team has 4 active chats, 31 tickets in the Tickets module total. Filtering for tag = vortexiq-finding:
| Ticket | Group | Status | Tag | Body summary |
|---|---|---|---|---|
| #LC-7821 | engineering | open | vortexiq-finding | LiveChat widget delays render 1.8s on mobile PDPs (LCP impact) |
| #LC-7822 | engineering | pending | vortexiq-finding | Pre-purchase trigger fires on bots; agent volume inflated |
| #LC-7823 | engineering | open | vortexiq-finding | Shopify checkout step 3 errors for guest users on AmEx |
| #LC-7824 | marketing | pending | vortexiq-finding | Klaviyo flow trigger missing viewedProduct event |
| #LC-7825 | engineering | open | vortexiq-finding | Magento full-page-cache miss on collection pages (this is a stale doc, brand has migrated to Shopify) |
| #LC-7826 to #LC-7833 | mixed | mixed | vortexiq-finding | Eight smaller findings, four open / four pending |
- #LC-7821 (widget render delay) is a direct conversion-lift killer. LiveChat is on every PDP and checkout step; if it delays 1.8s on mobile, mobile shoppers bounce before the proactive-engagement trigger fires. This single finding is correlated with ~6% of mobile revenue. Top of triage list.
- #LC-7822 (bot-triggered chats) inflates the agent’s perceived workload, agents spend time on bots while real shoppers wait. Pair with Chat Volume Trend to size the impact.
- #LC-7825 is stale (brand moved off Magento 4 months ago). Resolve as “won’t fix, platform retired”; this drops it from the count and keeps Finding Resolution Rate honest.
tag = vortexiq-finding AND tag = widget) directly to the engineering on-call via LiveChat’s Routing so revenue-impact findings bypass the round-robin.
Sibling cards merchants should reference together
LiveChat is the only chat connector with first-class conversion-lift signal because the chat widget sits directly on the storefront. The peer cards reflect this:| Card | Why pair it with Open Findings | What the combination tells you |
|---|---|---|
| VortexIQ Findings In Progress | The “actively worked on” subset. | Open = 13, In Progress = 11, healthy. Open = 13, In Progress = 2, queue is parked. |
| VortexIQ Findings Resolved | The 90-day outflow. | Required to read whether the open count is shrinking, steady, or growing. |
| Abandoned Findings (>14d no movement) | The aged subset. | High abandoned + Open >15 = prioritisation problem. |
| Finding Resolution Rate (90d) | Closure efficiency. | Open 15 + Rate 80% = noise we tolerate. Open 15 + Rate 40% = process problem. |
| Avg Time-to-Fix (days) | Speed of closure. | If Open is high but Time-to-Fix is low, team is fast and findings are added faster than fixable. Add capacity. |
| Unassigned Tickets | The “no owner” subset. | Unassigned > 50% of Open = routing rules missing; fix first. |
| Shopify Conversion Rate / BigCommerce Conversion Rate | LiveChat’s most direct revenue peer. | Open findings on chat widget + falling conversion rate = high causal confidence; the widget is the lever. |
| Shopify Total Revenue | Dollarised peer. | LiveChat-touched sessions convert 2-3× higher than non-engaged; widget findings have outsized revenue impact. |
| LiveChat Open Tickets | Total tickets-module volume. | Findings as % of total tickets shows whether the merchant is using LiveChat tickets primarily for customer questions or for audit follow-up. |
Reconciling against the vendor’s own dashboard
Where to look in LiveChat’s own dashboard:LiveChat Agent App, Tickets section, filter by tagLiveChat’s tickets module is separate from its live-chat module; Vortex IQ findings only land in tickets, never as live-chat conversations. Confirm that you are looking at Tickets, not Chats, when reconciling. Why our number may legitimately differ from LiveChat’s view:vortex_iqand statusopen. The headline count at the top of the filtered view should match this card to within 1 to 2%. LiveChat Reports, Tickets, Tag breakdown for trend visibility on the same tag filter. Save the filtered view as a custom view via Save filter as for the team to use daily.
| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | LiveChat reports honour the agent’s profile timezone; the card uses account-level timezone for RT window calculations. For a real-time count this rarely changes anything; for date-bounded comparisons it can shift one boundary day. |
| Tag filter exactness | Ours stricter | We require the literal vortex_iq tag. Legacy tags from earlier Vortex IQ versions (vortexiq_v1, vortex) drop out of our population but may appear if you build a more permissive LiveChat filter. |
| Group / Department scoping | Either | The card aggregates across all groups the connector token can read; LiveChat’s UI typically scopes to the agent’s group. Multi-group merchants should compare a single-group view with care. |
| Archived tickets | Same in both | LiveChat excludes archived tickets from active views; we do too. |
| API rate-limit lag | Ours up to 60s stale | LiveChat caps ticket-list API requests at 180/minute. Accounts with very large open Vortex IQ counts may see a 30 to 60 second refresh lag during peak hours. |
| Ticket merge / split | Ours can lag | LiveChat agents can merge two tickets into one or split one into two. The merge/split webhook can take up to 90 seconds to reach our index, so the count may be stale on the most recent few minutes of merge activity. |
| Bot-handled tickets | Same in both | LiveChat’s ChatBot can handle tickets via auto-reply but does not change ticket status; the ticket stays open until an agent or rule closes it. The card and LiveChat’s UI agree on this. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
shopify.ecommerce_conversion_rate / bigcommerce.ecommerce_conversion_rate | When chat-widget findings stack up unaddressed, conversion rate typically dips within 1 to 3 weeks because LiveChat-engaged sessions convert 2 to 3x higher than non-engaged. | Findings up + conversion rate down with LiveChat-touch share rising = the widget is becoming a friction point, not an asset. |
shopify.refund_rate | Refund spikes drive a subset of audit findings (returns-policy drift, post-purchase confusion). | Refunds up + findings on returns-policy clusters = direct causal evidence; fix to reduce refunds. |
shopify.customer_service_sentiment | NPS-side outcome. | Findings dropping + sentiment rising = audit programme is protecting retention. |
datadog.dd_health_score | Independent peer; correlates only when audit findings are dominantly technical. | Datadog elevated + LiveChat findings on widget errors = compounding signal; the engineering team is firefighting and the customer experience is degrading simultaneously. |
Known limitations / merchant FAQs
Why does my LiveChat tickets count differ from this card by 2 to 3 tickets? Almost always one of these. (1) Tag scope: the card requiresvortex_iq exactly, while a saved LiveChat filter may include legacy variants (vortex, vortexiq). (2) Group / Department scoping: the card aggregates across all groups the connector reads, while your LiveChat UI scopes to your group. (3) API rate-limit lag (LiveChat caps at 180/min) on accounts with very large open counts; a 30 to 60 second refresh lag during peak hours is normal. Wait for the next refresh and re-check.
The ChatBot replied to one of my Vortex IQ tickets. Does that count as resolved?
No. The ChatBot reply does not change ticket status; the ticket stays open until an agent or rule explicitly sets status: closed. The count is still accurate. However, an auto-reply on a Vortex IQ finding is bad behaviour: stock ChatBot replies (refund status, shipping ETA, working hours) are not appropriate responses to a finding like “checkout error rate spiked 18%”. Configure the ChatBot rule with an exclusion: IF tag CONTAINS 'vortex_iq' THEN do_not_handle.
LiveChat is small in our stack; should we even use it for findings?
LiveChat is the right destination for findings only if your team already uses LiveChat tickets as a workflow tool, particularly findings related to chat-widget UX, post-purchase customer questions, or returns-policy drift that surfaces in chat conversations. If your team treats audit findings as engineering tickets, route to Linear or Jira; if as operations workflows, route to Asana or Trello. LiveChat’s strength is the chat-context inline view: an agent reading a finding about widget errors can see actual chat transcripts where customers hit the error.
A finding was important but we never used LiveChat to track it; we fixed it directly. Do we close the ticket?
Yes. Mark the ticket status: closed once the work is done. Otherwise it stays in this card’s count and the abandoned-rate timer (14 days of no movement) starts ticking. Vortex IQ does not auto-close findings just because the underlying audit signal cleared; the human acknowledgement is the close signal.
Open count dropped suddenly. What changed?
Three usual causes. (1) Bulk close by an agent or admin from the Tickets list; LiveChat does not surface bulk-close events as audit-log entries by default. (2) Tag drift: someone removed the vortex_iq tag from a batch of tickets (intentionally or via a misconfigured rule). The tickets exist but no longer match the card’s filter. (3) Vortex IQ outbound paused: check the connector status in Settings, Connectors.
Why is the count higher today than my typical baseline?
Most common cause on chat-widget-heavy stores is a promotional push driving traffic. New visitors hit chat-widget edge cases (mobile keyboard overlap, slow loading on flaky 4G, language-detection misfires) faster than during quiet periods. The mid-day spike during promos is normal. Pre-empt by running audits before promo windows.
Should I configure a separate LiveChat SLA for Vortex IQ tickets?
Yes if your team’s volume warrants it. LiveChat’s headline Avg First-Response Time includes Vortex IQ tickets by default, which can drag the metric your team is measured against. Two practical options. (1) Build a saved LiveChat filter for tags:vortex_iq with a separate FRT target (e.g. 24h vs the 4h target on shopper tickets); the team works the filter on its own cadence. (2) Use the LiveChat Automation engine to apply a different SLA tag to Vortex IQ tickets.
Multi-store: my account spans two storefronts under one LiveChat. Why does this card show one number?
The card aggregates by default. To break out by store, set vortex_iq.store_filter in the connector config to scope the card to one store, or build a Stacked Panel with one panel per store. Alternatively, build two saved LiveChat filters (one per store-tag) for the same answer in your agent UI.
Why is the alert threshold 20 and not 30?
20 reflects LiveChat’s typical inbox-size profile. Most LiveChat merchants run 30 to 150 daily total tickets (smaller than Zendesk-using merchants), so a Vortex IQ count of 20 means roughly 15 to 60% of the inbox is findings, which is the threshold above which the team perceives the audit programme as noise. Tunable per organization in connector settings.
Today’s count looks volatile. Why?
At low volumes (<10 open) a single close or new finding moves the count by 10%+ which can register as visual noise. The 30-day average and 7-day rolling are the steadier reads for trend; the headline number is the live count. Most LiveChat merchants run smaller finding queues than Zendesk-using merchants, so volatility is more pronounced here.
Is LiveChat the right tool for managing audit findings?
LiveChat shines when audit findings have a customer-experience framing (chat-widget UX, post-purchase confusion, returns-policy drift). The chat-context inline view makes the customer impact visible in the same view as the work. If your team treats findings as engineering tickets with sprint cycle times, Jira or Linear is a better fit; if they treat them as ops workflows, Asana or Trello. LiveChat is auxiliary in most stacks, not primary.
My team uses LiveChat but you also have Jira connected. Will Vortex IQ duplicate findings into both?
No. Each finding routes to one tool based on the connector setup’s outbound priority. Default for ecommerce-CX-led merchants is LiveChat (or Gorgias / Intercom equivalent); for engineering-led merchants the default is Jira. Override in Settings, Connectors, Routing if your operations team owns the queue regardless of engineering involvement.