Tickets we created from audit findings that haven’t been resolved yet.
At a glance
The count of Crisp conversations Vortex IQ opened from a Nerve Centre audit finding (broken checkout, slow PDP, missing alt text, payment-form regression, etc.) that the merchant’s team has not yet resolved. Crisp is a real-time live-chat tool, so “open finding” here means a conversation in the inbox taggedvortexiq:findingthat is still inpendingorunresolvedstate.
| What it counts | Conversations in your Crisp inbox tagged vortexiq:finding whose state is pending or unresolved. Each finding is one conversation; bulk fixes that close many findings at once still close one conversation each. |
| Project / board scope | All Crisp websites attached to the connected workspace. Crisp organises by website not project, so multi-brand merchants see findings across every brand on the same Crisp account unless filtered by website_id. |
| Status filter | state IN (pending, unresolved). Crisp’s resolved state is treated as closed; pending (no agent has replied yet) and unresolved (agent replied but conversation still active) both count as open. |
| Conversation type | Vortex IQ-created findings only. Filtered by the vortexiq:finding segment tag, which we apply on creation via the Crisp Update Conversation Segments endpoint. Customer-initiated chats are excluded. |
| Multichannel inbox | Crisp aggregates email, Twitter DMs, Messenger, WhatsApp, and Telegram into the same inbox. Findings are routed in as native chat conversations (not email), so they do not pollute your support email volume metrics. |
| Free-tier note | Crisp’s free plan caps conversation history at 30 days. Findings older than 30 days on a free workspace are still counted via Vortex IQ’s own audit ledger but their Crisp body becomes inaccessible. Recommend Pro tier or above for merchants relying on this card. |
| Time window | RT, refreshed every 60 seconds via the Crisp List Conversations endpoint. |
| Alert trigger | >20 open findings, the threshold above which the backlog stops being a working list and becomes a graveyard. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Crisp 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 French DTC skincare brand on Shopify uses Crisp as its sole live-chat tool (Pro plan, 4 agents). Snapshot taken on 28 Apr 26 at 10:15 CET. Vortex IQ has opened 14 findings into Crisp over the last 6 weeks. Their states right now:| Finding | Created | State | Tag | Body summary |
|---|---|---|---|---|
| #VIQ-901 | 02 Apr 26 | resolved | vortexiq:finding | PDP image alt text missing on 47 products; fixed by content team |
| #VIQ-902 | 04 Apr 26 | resolved | vortexiq:finding | Stripe Radar rule blocking 8% of EU cards; rule disabled |
| #VIQ-903 | 09 Apr 26 | unresolved | vortexiq:finding | Cart drawer slow on iOS Safari (LCP 4.1s) |
| #VIQ-904 | 11 Apr 26 | unresolved | vortexiq:finding | Klaviyo welcome flow fires 6h after signup |
| #VIQ-905 | 14 Apr 26 | pending | vortexiq:finding | Out-of-stock variants visible in collection grid |
| #VIQ-906 | 16 Apr 26 | unresolved | vortexiq:finding | Shopify checkout step 3 errors for guest users |
| #VIQ-907 | 18 Apr 26 | resolved | vortexiq:finding | GA4 purchase event missing value parameter |
| #VIQ-908 | 21 Apr 26 | pending | vortexiq:finding | TikTok Pixel firing twice on PDPs |
| #VIQ-909 to #VIQ-914 | 22-27 Apr | mixed | vortexiq:finding | Six smaller findings, three pending, three unresolved |
Sibling cards merchants should reference together
Open Findings is the inflow side of a flow metric. Pair it with these to read direction, not just level:| Card | Why pair it with Open Findings | What the combination tells you |
|---|---|---|
| VortexIQ Findings In Progress | The “actively worked on” subset of the Open count. | Open = 14, In Progress = 11, that is healthy throughput. Open = 14, In Progress = 2, the backlog is parked. |
| VortexIQ Findings Resolved | The outflow over 90 days. Compare to inflow rate. | If resolved (90d) < created (90d), Open trends up forever. Resolved must lead created or the card crosses 20. |
| Abandoned Findings (>14d no movement) | The aged-out subset of Open. The dollars-leaking subset. | High Open + high Abandoned = team is creating findings without an owner. Time for routing rules. |
| Finding Resolution Rate (90d) | Closure efficiency, %. | Open = 25 with resolution rate 90% = noise we tolerate. Open = 25 with resolution rate 40% = process problem. |
| Avg Time-to-Fix (days) | Cycle-time peer. Cuts Open into “fast lane” and “slow lane”. | If Open is high but Avg Time-to-Fix is low, the team is fast and findings are being added faster than fixable. Add capacity. |
| Unassigned Tickets | The “no owner yet” subset of Open. | Unassigned = 8 of Open = 14 means most of the backlog has nobody on it. The card to fix first. |
| Crisp Open Tickets | The whole open inbox (not just findings). | Findings as % of total opens shows whether merchants are using Crisp primarily for customer chat or for audit follow-up. |
Reconciling against the vendor’s own dashboard
Where to look in Crisp’s own dashboard:
Crisp App → Inbox → Filters (top right) → Add filter → Segment → vortexiq:finding
Then in the inbox, set the state filter to Pending and Unresolved (toggle off Resolved).
The conversation count at the bottom of the filtered inbox should match this card. Crisp’s web app, desktop app, and mobile app all share the same conversation database, so any of the three will show the same number.
For aggregated reporting, Settings → Workspace Stats → Conversations shows total inbox volume but does not split by tag, so it is not a like-for-like check.
Why our number may legitimately differ from Crisp’s:
| Reason | Direction | Why |
|---|---|---|
| Sync lag | Ours lower for the most recent 60 seconds | We poll the List Conversations endpoint every minute. A finding created 30 seconds ago will not be in our cache yet. |
| Free-tier history cap | Either, depending on age | Free Crisp workspaces lose conversation history beyond 30 days. Findings older than that disappear from Crisp’s inbox but remain in Vortex IQ’s audit ledger; we count them. Pro tier and above retain full history. |
| State drift | Ours higher | If an agent resolves a finding without removing the vortexiq:finding tag, Crisp’s filter view excludes it (resolved filter off), but our count stays correct because we filter on state, not on Crisp’s UI defaults. |
| Multi-website workspace | Ours higher (aggregate) | Crisp’s UI defaults to one website at a time. Our card aggregates all connected websites in the workspace. Click the website-switcher in Crisp top-left to confirm; or set our card’s website_id filter to a single brand. |
| Time zone | Boundary days off | Crisp uses your workspace’s configured timezone (Settings → Workspace → Time Zone). We use UTC for “RT” measurements, so a finding created at 23:50 in Paris time may sit in a different “day bucket” than Crisp shows. Real-time count is unaffected. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
liveagent.liv_vortexiq_findings_open / livechat.liv_vortexiq_findings_open / tidio.tid_vortexiq_findings_open | Definitional twins on other live-chat tools. A merchant using two chat tools simultaneously will have findings on both. | Findings are written to whichever chat tool is set as the primary operations inbox. If you connected Crisp last but routed alerts to LiveChat, this card will read low while LiveChat’s reads high. |
zendesk.zen_vortexiq_findings_open / freshdesk.fd_vortexiq_findings_open | Helpdesk peers. Findings can be routed to a ticketing tool instead of (or alongside) chat. | Async helpdesk findings tend to age slower (24h SLA vs 5min SLA on chat); Open count on Zendesk legitimately runs higher than Crisp. |
shopify.total_revenue (or BigCommerce / Adobe Commerce equivalent) | Inverse correlation expected at high counts. Open findings >20 typically precede a 1-3% revenue dip within 30 days. | The lag is the time between an audit-detected regression and the merchant’s customers feeling it. The dollarised version is on the roadmap. |
Known limitations / merchant FAQs
Why is Vortex IQ writing findings into my Crisp inbox? My team uses Crisp for customer chat. You picked Crisp as your operational inbox during onboarding (Settings → Connectors → Crisp → “Use as primary findings inbox”). If that is wrong, switch the primary inbox to a helpdesk tool (Zendesk, Freshdesk) or a chat tool with a clearer separation between human-customer chat and automation traffic (LiveChat’s “ChatBot” stream is one option). Findings are taggedvortexiq:finding so you can filter them out of agent views in Crisp directly: Inbox → Filters → Exclude segment vortexiq:finding.
My team resolved a finding but the count did not drop. Why?
The card refreshes every 60 seconds. If 90 seconds have passed and the count is still wrong, the agent likely resolved the conversation in a way Crisp does not flag as state = resolved, for example by archiving without resolving. Open the conversation in Crisp and click Resolve explicitly; the count will sync within a minute.
My Crisp free plan deletes conversations older than 30 days. Are old findings disappearing?
The conversation body is wiped after 30 days on the free plan. The Vortex IQ audit ledger keeps the original finding intact, so the card count is still accurate, but the merchant cannot read the conversation history beyond 30 days. Two fixes: (1) upgrade Crisp to Pro tier ($25/mo at time of writing) for unlimited history; (2) action findings within 30 days, which is what the alert threshold of 20 is calibrated to encourage anyway.
Crisp is multichannel (chat + email + Twitter + Messenger + WhatsApp + Telegram). Are findings in every channel?
No. We write findings as native chat conversations to keep them out of your customer-email inbox. Customers cannot see findings (they are internal-only conversations with no participant). If you want findings to fan out to email or Slack as well, configure that on the Crisp side under Settings → Notifications → Routing.
Can I assign findings to specific agents automatically?
Yes, via Crisp’s Routing Rules. Create a rule: if segment = vortexiq:finding, route to <engineering@yourbrand.com>. The rule fires on creation; from then on, findings land directly in the engineer’s queue rather than the shared inbox. We recommend this for any team above 3 people, otherwise findings collect in the shared queue and nobody owns them.
My free Crisp plan has a 30-day data retention cap. Does the alert threshold (>20) account for that?
The threshold is set against ingest rate, not retention. If you are creating findings faster than your team can resolve them in 30 days, the count crosses 20 and pages you regardless of whether old conversations are still readable. The 30-day cap is about evidence retention, not about count accuracy.
How does this card relate to “Open Tickets” (the Crisp-native count)?
Open Tickets is every unresolved conversation in your Crisp inbox: customer questions, returns, shipping, plus our findings. This card is the subset tagged vortexiq:finding. On a busy DTC brand, total Open Tickets often runs 50-200 while VortexIQ Findings Open sits in the single digits. Track both; the ratio tells you how much of your operations work is reactive (customer-driven) vs proactive (audit-driven).
Why is “open” defined as pending OR unresolved? What about “responded but waiting”?
Crisp’s state model has only two non-resolved states: pending (no agent has replied) and unresolved (agent replied at least once, conversation still active). There is no “waiting on customer” state in Crisp; merchants who need that level of granularity tend to outgrow Crisp into LiveAgent or Zendesk. We treat both states as open because either way, the finding is not yet actioned.
Can I create findings in Crisp manually for things Vortex IQ has not detected?
Yes. Tag any conversation with vortexiq:finding and it joins the count. Useful for merchant-spotted issues you want tracked alongside automated findings. Use the Crisp Conversation → Tags → Add segment UI; the tag is case-sensitive.