Customers with ≥2 failed orders in the window. Critical recovery target: high intent, multiple attempts. Sort by failed_value desc; surface ‘any_recovered=Yes’ flag (means at least one attempt succeeded → soft-decline → retry-recoverable).
At a glance
Customers who attempted checkout multiple times in the window and failed two or more of those attempts. The highest-intent recovery cohort on the entire BigCommerce store, they want to buy, they came back, the checkout broke them again. Critical for human / SMS / personal-email follow-up.
| What it counts | A customer-level (billingAddress.email lowercased, customerId fallback) aggregation of failed orders. The list shows every customer who has ≥2 failures (paymentStatus = declined OR status = Incomplete) in the window, sorted by total failed_value descending, with a any_recovered = Yes/No flag indicating whether at least one of their attempts ever succeeded. |
| VAT / tax treatment | The failed_value column uses total_inc_tax (always tax-inclusive) summed across all failed attempts per customer. |
| Shipping | Included in the per-attempt total_inc_tax. |
| Discounts | Already deducted, the values shown are what the customer was trying to pay. |
| Refunds | Not in scope. Refunds happen after successful orders; this card is about the failure side. |
Incomplete quirk | An Incomplete status order counts as one attempt. A customer who hit Place Order three times and got Incomplete on each shows as 3 attempts, all failed. The recovery flag is Yes only if attempt N+1 succeeded after one of those Incompletes. |
any_recovered = Yes semantic | Means at least one of the customer’s attempts eventually succeeded within the same 30-day window (email-first join). This is the soft-decline / retry-recoverable signal: the customer was clearly genuine, the gateway just had a momentary issue. These customers are the easiest-to-reactivate segment. |
any_recovered = No semantic | Customer attempted multiple times, all failed, never succeeded within the window. This is the structural-decline / human-follow-up segment, the customer is likely facing a payment-method, fraud-rule, or address-verification issue that retry alone cannot fix. Sales / support should reach out personally. |
| Currency | Per-customer values sum across currencies without FX conversion. Rare per-customer issue (most customers transact in a single currency), but multi-currency stores see mixed totals on the small minority of customers who shop across regions. |
| Channels / sources | Not filtered. A customer who failed once on web and once on POS still counts. The list shows the dominant channel per customer for context. |
| Time window | 30D (no vsP, this is a snapshot list, not a trend) |
| Alert trigger | None directly. Companion alert: a sudden growth in repeat-failure cohort size signals a structural checkout problem worth investigating. |
| Roles | owner, marketing, operations |
Calculation
Calculated automatically from your BigCommerce 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 homewares brand on BigCommerce Enterprise. The 30-day window covers 14 Mar 26 to 12 Apr 26. Total failures: 485 orders across 421 unique customers. Of those, 38 customers failed 2+ times (the population in this card).| Customer (top 8 by failed_value) | Attempts | Failed | Failed value | any_recovered | Dominant paymentMethod | Action |
|---|---|---|---|---|---|---|
j.smith@example.com | 4 | 4 | $1,872 | No | PayPal Express | Phone call |
robinson@bigcorp.co | 3 | 3 | $1,540 | No | Credit Card | Email + offer alt method |
margaret.lee@gmail | 5 | 4 | $1,210 | Yes | Credit Card | Soft retry email |
t.patel@gmail.com | 3 | 3 | $988 | No | PayPal | Phone call |
reema_b@outlook | 4 | 3 | $920 | Yes | Apple Pay | Soft retry email |
sales@vendor.io | 6 | 6 | $878 | No | Credit Card | Investigate fraud-rule |
linda.k@yahoo.com | 3 | 2 | $612 | Yes | Credit Card | Soft retry email |
mike@startup.dev | 3 | 3 | $577 | No | Klarna | Phone call (BNPL decline) |
- The top 8 customers carry $8,597 of unrecovered failed value, ~14% of the store’s total at-risk dollars. Long-tail principle: a small list of repeat-failure customers concentrates a disproportionate share of the prize. Personal outreach to the top 20-30 names typically converts 30-50%, an order of magnitude higher than cold abandonment-recovery emails.
any_recovered = Nois the high-priority segment. These customers have NEVER succeeded with this merchant in 30 days. The fiveNo-flagged customers above represent $5,855 of failed value and zero recovery, this is real money walking away. TheYes-flagged customers are easier to win back (the gateway has shown it can authorise them; they just need a nudge).- The vendor email pattern is suspect. Six attempts, all failed, generic email format, the same card across attempts. This is either (a) a fraud / card-testing attempt that the gateway correctly rejected, or (b) a B2B buyer trying to use a corporate card that’s hitting the merchant’s fraud rules. Investigate before reaching out, you don’t want to manually approve a fraud attempt.
- The Klarna decline pattern (the startup-domain row above) is structural. Klarna runs its own credit check; multiple Klarna declines for the same customer means Klarna’s underwriting has rejected them three times. A retry won’t change the outcome; offer this customer a credit-card or wallet alternative.
- Top 5 by
failed_valuewithany_recovered = No: human phone call from sales / customer-service, “We saw you tried to order, can we help complete it?” Conversion rates 30-60% when done within 24 hours of the last attempt. - All
any_recovered = No: personalised email from a real human address (not anoreplymailbox) within 48 hours, offer to switch payment methods, optional 5-10% incentive. - All
any_recovered = Yes: Klaviyo / Bloomreach Engage abandonment-recovery sequence, lower priority, the customer is likely already on an automated nudge. Conversion 8-15%. - Suspicious patterns (generic email, identical card across many attempts, IP velocity): flag for fraud review, do NOT include in recovery outreach.
Sibling cards merchants should reference together
| Card | Why pair it with Repeat Failure Customers |
|---|---|
| BC Top Unrecovered Today | The daily action list of biggest single-attempt unrecovered failures. This card is the multi-attempt version, customers worth a phone call rather than just an email. |
| BC Size of the Prize | The aggregate dollar opportunity. This card identifies the highest-value individuals inside that aggregate. |
| BC Failed Orders Count | The store-wide failure headline. The repeat-failure cohort is typically 8-15% of total failed orders but disproportionately concentrated in dollar value. |
| BC Decline by Payment Method | If the same method shows up across many of your repeat-failure customers, the issue is that method, not the customer. |
| BC Failures by Channel ID | If repeat-failure customers concentrate on one channel, that channel has a structural checkout problem. |
| Customer Segments | Cross-reference: are your repeat-failure customers high-LTV existing customers (urgent intervention) or new prospects (less urgent)? |
| BC Top Customers | If a name on your top-customers list is also on your repeat-failure list, that’s an account-management emergency. |
| BC Organic Recovery Rate | The store-wide rate at which failures self-recover. This card surfaces the customers who didn’t self-recover and need help. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Customers → All customers gives you the customer list, then per-customer drill-in to Orders shows their attempt history. There is no native BC view that surfaces “customers with multiple failed attempts in the last 30 days”, you would have to build this manually by exporting orders and pivoting in a spreadsheet. Other BC views that look adjacent but miss the point:- Customers → Customer groups: segments based on order count and value, not failure count.
- Customer Insights → Cohort report: tracks lifetime cohorts, not failure cohorts.
- Orders → Filter by status
Declined: shows individual failed orders, doesn’t aggregate per customer. - Storefront → Abandoned carts: tracks pre-checkout abandonment per session, not multi-attempt customers.
| Reason | Direction |
|---|---|
Email-first join semantics. We aggregate failed orders by billingAddress.email (lowercased), with customerId as fallback. A naive BC export aggregates by customerId only and misses guest checkout customers who failed multiple times under the same email but no logged-in account. | Vortex IQ HIGHER count than naive exports |
Email normalisation. We lowercase emails before joining; BC stores them case-sensitively. Customer who shopped as J.Smith@example.com once and j.smith@example.com another time appears as one customer here, two in BC’s raw data. | Vortex IQ slightly LOWER unique-customer count |
| 30-day window. We use a strict 30-day rolling window. BC’s customer-history view is lifetime. | Different timeframe, expect different numbers |
| Time zone. UTC vs store. | Marginal |
| Excluded statuses. Cancelled and Refunded are excluded; some merchants would manually count Refunded as a “failed customer experience”. | Vortex IQ LOWER if merchant counts refunds |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
klaviyo.klaviyo_at_risk_segment | Klaviyo’s “at-risk” segment includes customers who haven’t purchased in N days; this card is a stricter subset (those who tried and failed) | Klaviyo segment is much larger; this card is the highest-priority sub-cohort. |
stripe.stripe_repeat_decline_customers | Stripe sees repeat-decline at the customer dimension only when the merchant uses Stripe Customer objects | Many BC stores process Stripe charges without saving Customer IDs; the dimension is invisible Stripe-side. |
paypal.pp_repeat_decline_customers | Same shape for PayPal-routed declines | PayPal exposes only the PayPal account email, which often differs from the BC billing email. |
Order.customer.email joins exist), but the recovery-list output card is BC-only for now. Equivalents are tracked on the CONNECTOR_BACKLOG.
Known limitations / merchant FAQs
How aggressive should I be reaching out to repeat-failure customers? Aggressive but personal. A real human email from a real human address (not the marketing automation IP) within 24-48 hours of the last failed attempt converts at 30-50%. Generic “we noticed you had trouble” emails sent en masse fromnoreply@store.com convert at 5-10% and feel creepy. The signal-to-noise on this list is extraordinarily high; treat it as warm B2B leads, not as a cold-marketing segment.
Should I offer a discount to repeat-failure customers?
Not as the first move. A discount implies the price was the problem; it almost never is on this list. The customer was willing to pay the original price (they tried, repeatedly). Offer help (a different payment method, a sales-rep call to take the order manually, a deferred-payment option). If after the human touch they still don’t convert, then a small (5-10%) discount can break the deadlock, but starting with a discount erodes margin unnecessarily.
Why does the same email show up multiple times in my list?
It shouldn’t. The aggregation is per email; if you see duplicates, the most likely cause is that the customer used the same email in different cases (Customer@Example.com and customer@example.com) and the underlying join didn’t catch them. Vortex IQ lowercases before joining, but in rare cases (Unicode normalization, email-plus-suffix variants like customer+1@example.com) edge cases sneak through. Report the duplicate to Ask Viq and we’ll investigate.
A customer is on this list with any_recovered = Yes, are they low priority?
Lower priority than No, but not zero priority. Yes means they eventually got through, but the friction tells you something about your checkout. If you have many Yes-flagged customers all on the same payment method, that method is causing soft declines at scale. Fix the method, you’ll prevent future repeat-failures and reduce existing-customer frustration.
Some entries are clearly fraud / card-testing, can I exclude them?
Yes, but currently it’s a manual process. Patterns to watch for: identical IP across attempts, sequential card numbers, generic / new email domains, very small order values ($1-5 testing transactions), velocity (5+ attempts in <10 minutes). These are NOT real customers; do not include them in recovery outreach. The Vortex Mind fraud-velocity signal in the payment-performance-intelligence report is the right place to filter these out before exporting your action list.
My B2B / wholesale customers show up here often, what do I do?
B2B buyers commonly fail multiple checkout attempts because of corporate-card fraud rules, Net-30 / Net-60 invoice-payment misconfigurations, or address-validation issues with company billing addresses. Move B2B buyers to a non-card-on-file flow (manual invoicing, BC’s Net-30 Order extension, a B2B-specific portal). The retail-checkout flow is structurally hostile to corporate cards; you cannot retry your way through this.
Should I integrate this list with my CRM?
Yes, ideally daily. Vortex IQ exposes this list via the BigCommerce API (subject to BC’s order-list rate limits), so you can sync to HubSpot, Salesforce, or your CRM of choice and route names to the right rep. The Vortex Mind decline-recovery-intelligence report has a daily CSV export option that pre-formats this list for direct upload to most CRMs.
Why not include customers with only one failed attempt?
That cohort is in BC Top Unrecovered Today. The two cards complement each other: single-attempt failures are higher volume but lower per-customer intent, multi-attempt failures are lower volume but higher per-customer intent. Different recovery playbooks for each cohort, mass-email for the single-attempt list, human follow-up for this multi-attempt list.
My multi-currency store, how is the failed_value computed?
Per-customer values are summed across the customer’s failed attempts without FX conversion. A customer who failed once for $100 and once for €80 shows as failed_value = 180 (mixed-units, meaningless number). For multi-currency stores filter by currencyCode directly in the OpenSearch view; per-currency repeat-failure cards are on the BC roadmap.