Your most valuable customers, right now, sitting in an open conversation that has already breached SLA — the queue you cannot afford to get wrong.
At a glance
High-Value Customer Waiting is a real-time cross-channel revenue-at-risk metric that joins your Intercom inbox to customer lifetime value from your commerce sibling. It lists open conversations that have already passed their first-response SLA and belong to a top-decile-LTV customer — the people whose churn would hurt Blitz most, kept waiting at exactly the wrong moment. It turns a flat queue into a prioritised one: not just “who is waiting longest” but “who is waiting that we most need to keep”. The card only renders when an ecommerce-platform or marketplace sibling is connected, because the LTV side of the join lives there.
| What it counts | A live table of open Intercom conversations where waiting_since (time awaiting agent reply) has exceeded the SLA target, filtered to contacts whose lifetime value falls in the top decile of the commerce sibling’s customer base. Each row shows the customer, their LTV band, how long they have waited, and a link to the conversation. |
| Sample type | Derived, real-time. Open Intercom conversations with statistics.waiting_since past SLA, joined to commerce_sibling.customer_ltv filtered to the top decile. Recomputed continuously rather than on the standard refresh. |
| Why it matters | Every breached SLA is bad; a breached SLA on a top-decile customer is a retention emergency. These shoppers carry the most future revenue, so a slow or dropped reply here costs far more than the average ticket. The card lets a support lead pull the highest-stakes conversations to the front of the queue before they become a churn event or a public complaint. |
| Reading the value | Treat any row as an action item. Read top to bottom by wait time within the high-value cohort: the customer at the top has the most accumulated wait and the most to lose. An empty table is the goal. A growing one during a volume spike tells you staffing is failing your best customers first. |
| Currency | mixed (customer, LTV band, wait time, links) |
| Time window | RT (real-time) |
| Alert trigger | >0 top-decile-LTV customers breaching SLA |
| Sentiment key | — |
| Roles | owner, operations |
Calculation
The card takes the set of currently open Intercom conversations whosestatistics.waiting_since (or equivalent first-response clock) has exceeded the configured SLA target, then joins each conversation’s contact to the commerce sibling’s customer LTV table and keeps only those in the top decile of LTV. Output is a live table — one row per breaching high-value conversation — with the customer, LTV band, elapsed wait, and a link into the Intercom thread. Because the time window is real-time, the table is recomputed continuously rather than on the standard data refresh. The only_when gate keeps it hidden unless an ecommerce-platform or marketplace sibling supplies the LTV figures.
Worked example
A representative reading of High-Value Customer Waiting for Blitz, the sports retailer. The overall inbox shows 40 open conversations, 9 of them past SLA — a normal busy afternoon. But this card shows 2 rows. The top one is a customer in Blitz’s top LTV decile (a club kit buyer who reorders every season) who has waited 3h 40m for a first reply on a damaged-delivery complaint; SLA was 4h… it just breached. The second is a personal-shopper-tier customer waiting 2h 10m. The support lead does not need to triage all 9 breaches equally — these 2 jump the queue and get assigned to a senior agent immediately. The founder sees the same card and knows the brand’s most loyal buyers are protected even on a bad day. Without the LTV join, both would have been buried among the 9 generic SLA breaches. For the broader breach picture, cross-reference the live SLA-breaches card; for natural-language exploration, ask Ask Viq “which VIP customers are waiting past SLA right now”.Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
ic_alert_sla_breach | Alerts sibling: the full live SLA-breach list this card filters down to the high-value subset. |
ic_alert_unassigned | Alerts sibling: a VIP waiting because nobody owns the conversation — check the overlap. |
ic_xc_support_spike_failed_payments | Cross-channel sibling: a waiting VIP may also be a refused-payment shopper. |
ic_xc_complaints_on_oos | Cross-channel sibling: the VIP may be waiting on a sold-out item you can recover. |
ic_alert_oldest_open | Alerts sibling: confirm whether your oldest open conversation belongs to a high-value customer. |
Reconciling against the vendor’s own dashboard
Where to look in Intercom’s own dashboard: Intercom shows the waiting side in the Inbox: sort an open-conversations view by “Waiting since” or “Longest waiting”, and SLA breaches surface in the SLA columns or in Reports → SLAs. What Intercom cannot do is rank by customer value — it has no lifetime-value figure, so it treats every breaching customer the same. The top-decile filter is what Vortex IQ contributes by joining the contact to the commerce sibling’s LTV. To inspect a single row, open it from the link and use Intercom’s conversation view; the SLA timer andwaiting_since shown there should match the card’s elapsed-wait value.
Why the Vortex IQ value may legitimately differ:
| Reason | Direction | What to do |
|---|---|---|
| LTV identity match. A customer who contacts you from a different email than their commerce account will not resolve to an LTV band and will not appear. | Vortex IQ lower | Confirm contact-to-customer matching; merge duplicate contacts. |
| SLA definition. Intercom’s SLA rules may differ from the SLA target configured in your Vortex IQ profile. | Variable | Align the SLA target so the breach clock matches. |
| Decile boundary. The top-decile cut-off is recomputed as the customer base shifts; a borderline customer can move in or out. | Marginal | Treat the LTV band, not the exact rank, as the signal. |
Known limitations / merchant FAQs
Q: How often does High-Value Customer Waiting update? It is a real-time card — recomputed continuously rather than on the standard 30-60 minute refresh — so a conversation appears as soon as it breaches SLA and disappears the moment an agent replies or closes it. Q: Why is a clearly important customer not on the list? Three common reasons: their conversation has not yet breached SLA (it is waiting, but within target), they did not resolve to a top-decile LTV band (often an email mismatch between support and commerce records), or the commerce sibling is not connected — the card is gated byonly_when.
Q: How is “top decile” defined?
The top 10% of customers by lifetime value in the connected commerce sibling. The boundary recalculates as your customer base changes, so focus on the band rather than a fixed cut-off.
Q: Can I customise the alert threshold?
Yes. The default alert fires whenever any top-decile customer breaches SLA; you can widen the value cohort (for example to the top two deciles) or tighten the SLA target per profile in the Sensitivity tab.