Findings sat in the backlog with no status change for two weeks, these are the ones losing money silently.
At a glance
Of all the open Vortex IQ findings sitting in your Crisp inbox, this card counts only the ones that have not had a single agent action (reply, status change, tag edit, assignee change) in 14 days. Crisp is a real-time tool; a finding that has been silent for a fortnight is no longer being worked on, it has been forgotten. These are the findings quietly costing the merchant money while everyone assumes they are “in the queue”.
| What it counts | Conversations tagged vortexiq:finding, in pending or unresolved state, where last_activity_at is more than 14 days before now. last_activity_at is Crisp’s roll-up of message-sent, status-change, assignee-change, and tag-change events. |
| The 14-day rule | Calibrated against typical merchant data: 95% of findings that get resolved are touched at least once within 14 days. Past that point the resolution probability collapses, the finding is statistically more likely to be closed by a quarterly inbox cleanup than by being fixed. |
| Why activity, not creation date | A finding created two weeks ago that the team has been actively replying to is being worked on. A finding created two weeks ago that nobody has touched in 14 days is abandoned. The card uses last activity, not creation, to make this distinction. |
| Resolved findings | Excluded. If the team eventually resolves an aged finding, it leaves this count immediately. The card only ever holds open work. |
| Free-tier note | On free Crisp workspaces (30-day conversation retention) findings between 30-90 days old will be in our audit ledger but have no Crisp body to inspect. The count is still accurate; merchants on free tier should resolve or upgrade. |
| Real-time vs ticketed | Crisp’s customers expect <60-second human response time on chat; an aged finding in Crisp signals a worse process failure than the same finding aged in a ticketing tool (Zendesk, Freshdesk) where 24h SLAs are normal. Hence the harsh threshold. |
| Time window | RT, refreshed every 60 seconds. |
| Alert trigger | >5 (warn) and >15 (critical). 5 abandoned findings is a process-leak signal; 15 is a process-collapse signal that requires owner-level intervention. |
| Sentiment | Threshold gauge with warn=5, critical=15. |
| 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 2-person UK home-goods brand on BigCommerce uses Crisp Pro plan. Snapshot taken on 28 Apr 26 at 09:00 GMT. The team has 18 open findings. Vortex IQ checkslast_activity_at for each. Today’s date minus 14 = 14 Apr 26. Anything with last activity before that is abandoned.
| Finding | Created | Last activity | Days since activity | Abandoned? |
|---|---|---|---|---|
| #VIQ-820 | 12 Mar 26 | 17 Apr 26 (agent replied) | 11 | No, recently touched |
| #VIQ-821 | 18 Mar 26 | 24 Mar 26 (created, then silence) | 35 | Yes |
| #VIQ-822 | 02 Apr 26 | 02 Apr 26 (created, then silence) | 26 | Yes |
| #VIQ-823 | 05 Apr 26 | 22 Apr 26 (status change) | 6 | No |
| #VIQ-824 | 08 Apr 26 | 08 Apr 26 (created, then silence) | 20 | Yes |
| #VIQ-825 | 09 Apr 26 | 13 Apr 26 (assignee added, then silence) | 15 | Yes |
| #VIQ-826 | 11 Apr 26 | 27 Apr 26 (agent replied) | 1 | No |
| #VIQ-827 to #VIQ-837 | various Apr | 18 Apr - 28 Apr (active) | < 14 | No, all active |
- #VIQ-821 and #VIQ-822 were both created during a sprint where the team was launching a Black Friday landing page; they were tagged into Crisp but nobody picked them up because the launch took priority. Classic priority-bumping pattern.
- #VIQ-824 and #VIQ-825 are both Klaviyo email-deliverability findings. The team’s email specialist was on holiday from 09 Apr to 23 Apr, and these findings have no fallback assignee.
vortexiq:finding and last_activity > 7 days, escalate to <owner@brand.com>) so the next abandonment is caught before crossing 14 days. Pair with Unassigned Tickets and Overloaded Assignees to see whether the issue is structural (too few people) or routing (work going to busy people).
Sibling cards merchants should reference together
Abandoned Findings is a leakage detector, not a workload metric. Pair it with the cards that explain the why and the cost:| Card | Why pair it with Abandoned Findings | What the combination tells you |
|---|---|---|
| VortexIQ Findings Open | The pool that abandoned findings come from. | Abandoned / Open ratio. Above 25% = process collapse; under 10% = healthy backlog with normal aging tail. |
| Unassigned Tickets | Most abandoned findings were never assigned. | If unassigned > abandoned, your routing rules are missing. Findings without an owner age fastest. |
| Overloaded Assignees (>10 open) | Other abandoned findings were assigned to people drowning in work. | High abandoned + 1-2 overloaded agents = redistribution problem, not capacity problem. |
| Avg Time-to-Fix (days) | Cycle-time peer. | Avg time-to-fix < 5d AND abandoned > 5 = the team fixes fast when they engage, but engagement is patchy. Routing rules. |
| Throughput Trend | Outflow. | If throughput is steady and abandoned is rising, the team is choosing easier findings and ducking the hard ones. |
| Oldest Open (days) | The maximum-age outlier. | Oldest = 90+ days but Abandoned only = 3 means most aged findings are actually being touched lightly; the 90+ day items are the truly forgotten ones. |
| Scope Added Mid-Sprint | Why findings get parked. | High scope-creep in current sprint + abandoned rising = product/feature work is preempting audit follow-up. |
| Shopify Total Revenue (or BC / Adobe equivalent) | The dollarised peer. | High abandoned for >30 days has shown 1-3% trailing revenue dip on commerce platforms. The cost of inaction. |
Reconciling against the vendor’s own dashboard
Where to look in Crisp’s own dashboard: Crisp does not surface “no activity in N days” as a built-in inbox filter, but you can construct it:
Crisp App → Inbox → Sort by → Last activity (oldest first)
Then filter Segment = vortexiq:finding and toggle off Resolved state.
The conversations at the top of the list are your abandoned findings. Eyeball the last_activity_at column; anything older than 14 days from today matches our count.
Why our number may legitimately differ from Crisp’s manual count:
| Reason | Direction | Why |
|---|---|---|
| Definition of “activity” | Either | Crisp’s UI groups silent conversations together but does not strictly define the inactivity boundary. Our 14-day rule is exact; counting in the UI requires the merchant to draw the cutoff manually, which often disagrees by 1-2 days. |
| Bot ping events | Ours lower | Some Crisp accounts have a “ping bot” (automated nudge after N days). If the bot sends a message, it counts as activity in Crisp’s last_activity_at, so the conversation does not appear abandoned to us. Disable the ping bot for vortexiq:finding segment if you want pure human activity to count. |
| Sync lag | Ours lower | We poll every 60 seconds. A finding that just crossed the 14-day boundary takes up to a minute to appear in our count. |
| Free-tier history cap | Ours higher | Free Crisp workspaces lose conversation bodies after 30 days; the conversations themselves remain in Vortex IQ’s audit ledger and continue to count even if Crisp’s UI no longer shows them. Pro tier eliminates this. |
| Time zone | Negligible | We compute NOW - 14 days in UTC. Crisp’s UI shows last-activity timestamps in the workspace timezone. Boundary differences average <1 hour, well below the 14-day threshold. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
liveagent.liv_vortexiq_findings_abandoned / livechat.liv_vortexiq_findings_abandoned / tidio.tid_vortexiq_findings_abandoned | Definitional twins on other live-chat tools. Same 14-day rule. | If a merchant runs Crisp for customer chat and LiveAgent for findings, abandoned will sit at 0 on Crisp and concentrate on LiveAgent. The card on each tool reads its own primary inbox only. |
zendesk.zen_vortexiq_findings_abandoned / freshdesk.fd_vortexiq_findings_abandoned | Helpdesk twins. Findings tend to age slower in chat than in helpdesks because chat SLAs are tighter. | The same merchant rarely has high abandoned counts on both; either chat absorbs the work and helpdesk runs low, or vice versa. |
shopify.total_revenue / bigcommerce.total_revenue / adobe_commerce.total_revenue | Statistical inverse over 60-day windows. | A persistent abandoned count >5 has shown 1-3% trailing revenue dips. Not all abandoned findings cause revenue loss, but enough do that the correlation is reliable. |
Known limitations / merchant FAQs
Why is the threshold 14 days specifically? Calibrated against ~6 months of merchant data. We modelled time-from-creation-to-resolution for findings that did eventually get resolved, and 95% of them were touched at least once within the first 14 days. Past that point, resolution probability drops below 30%. Setting the threshold at 7 days produced too many warns on findings that were genuinely being investigated; setting it at 21 days missed the ones quietly dying. 14 days is the inflection. A finding is “abandoned” but my engineering team has been working on it offline. They just have not replied in Crisp. This is the most common reason a finding shows as abandoned when work is happening. Crisp only knows about activity that touches the conversation: a reply, a status change, an assignee change, a tag edit. If your team works in GitHub or Linear, paste a status comment into the Crisp conversation once a week, two clicks, and the finding stops aging. We recommend a weekly Friday “ping all open findings” routine for engineering-heavy merchants. One of my abandoned findings is from 90 days ago. Will it ever leave this count? Only when it changes state toresolved, gets touched (any activity), or is deleted from Crisp. The card has no upper age cap; a finding silent for 365 days is still counted. This is intentional, the whole point is to surface forgotten work.
The count went from 8 to 0 overnight. Did someone fix everything?
Two scenarios. (1) Someone bulk-resolved the abandoned conversations without fixing the underlying issues, common during quarterly inbox cleanups. The count is gone but the merchant problems remain. Always pair this card with Finding Resolution Rate which differentiates “closed because fixed” from “closed because given up”. (2) Someone bulk-tagged or moved findings to a different segment. Check Crisp audit log: Settings → Audit Log → Filter by user.
My free Crisp plan deletes conversations after 30 days. Does that drop them from this count?
No. The conversation body is wiped from Crisp’s UI but the vortexiq:finding ID stays in our audit ledger and continues to count. Free-tier merchants will see abandoned counts higher than the visible inbox; resolve, archive, or upgrade to Pro tier ($25/mo) to align the two views.
Does Crisp’s “ping bot” feature reset the abandonment timer?
Yes, if active. The Crisp ping bot sends an automated nudge to silent conversations after a configurable interval; that nudge counts as activity in last_activity_at. If you want pure-human activity to count, disable the ping bot for the vortexiq:finding segment: Settings → Workflows → Ping bot → Exclude segment. We recommend this; otherwise the card’s signal degrades to “did the bot fire” rather than “did a human engage”.
Can I exclude specific findings from this count?
Yes, by removing the vortexiq:finding tag. The conversation stays in Crisp but leaves the Vortex IQ findings universe entirely (it also drops out of Open Findings). Useful for findings the merchant has consciously deferred (e.g., “wait for Q3 platform replatforming”). Tag them with vortexiq:deferred instead, so they are still discoverable but not counted.
Is this card the same as Crisp’s “stale conversations” feature?
No. Crisp has a feature called Routing Rules → Auto-resolve old conversations which auto-closes anything inactive for N days. If you turn that on, abandoned findings get auto-closed and silently disappear from this card AND from your real-finding queue. We recommend disabling auto-resolve for the vortexiq:finding segment specifically; otherwise the data loss is compounded.
My team is small (2-3 people). 5 abandoned findings feels harsh.
The threshold is calibrated against typical SMB merchant data and 5 is the inflection where the same person handles each conversation. For very small teams, the practical answer is to keep open count under 10 and focus on velocity rather than abandonment, but the threshold itself does not need to change. If 5 reads chronically, the team is either too small for the work or the routing is not directing findings to the right people; either way, the alert is doing its job.
I see “abandoned” but my agent has the conversation open in their Crisp tab.
“Open in browser tab” is not activity in Crisp’s data model. The agent must click into the conversation, send a reply or change status, for last_activity_at to update. Reading without responding does not count, which is intentional, otherwise a curious agent could “investigate” a finding for 30 days without ever working on it and the metric would silently fail.