Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.elasticfunnels.io/llms.txt

Use this file to discover all available pages before exploring further.

ElasticFunnels integrates with external call center providers to automatically push data for abandoned cart recovery, sales follow-ups, failed payment calls, subscription dunning escalation, cancellation routing, and winback (re-engagement) leads.
These are outbound data pushes to third-party providers. If you want to run your own call center with agent tools, phone orders, and commission tracking, see the Call Center Suite.

Supported Providers

Organization Callcenter

Send work to your own in-house call center module instead of an external webhook. Creates internal queue items for your agents.

HelpGrid

Full suite: abandoned carts, new sales, failed payments, subscription dunning, cancellations, and winback leads.

Tauk (Listflex)

Cart recovery and lead management via the Listflex API. Supports the full event matrix including abandoned carts.

Logicall

Full suite: enterprise abandoned-cart recovery plus sales, failed payment, and full subscription-lifecycle support.

SalesBound

Sales follow-ups, failed payments, subscription dunning, cancellation, and winback routing. Does not receive abandoned carts.

Committed Coaches

High-touch coaching, failed payments, subscription dunning, cancellation, and winback routing. Does not receive abandoned carts.

Nuyu

Sales, failed payments, subscription dunning, cancellations, and winback. Phone number is not required for sales.

What Each Provider Supports

Event TypeOrg. CCHelpGridTaukLogicallSalesBoundCommitted CoachesNuyu
Abandoned cartsYesYesYesYes
New salesYesYesYesYesYesYesYes
Failed paymentsYesYesYesYesYesYesYes
Subscription renewal failedYesYesYesYesYesYesYes
Subscription cancelYesYesYesYesYesYesYes
Subscription winbackYesYesYesYesYesYesYes
A “Yes” in the matrix only declares what the provider can technically receive. Each event still has to be explicitly enabled on your integration — see Per-Event Configuration below. By default only Abandoned carts is enabled for HelpGrid / Logicall / Tauk. All other events are off until you turn them on.
Committed Coaches and Nuyu are purchase-endpoint providers — subscription events are sent via their sales webhook. Nuyu is outbound-only (no incoming postbacks from the provider back to ElasticFunnels).
Organization Callcenter is only enabled when an active call center exists for your organization (Settings → Call Center). Use it to keep work in-house; mix and match with external providers per-merchant if needed.

Common Use Cases

Abandoned Cart Recovery

When a customer enters their email but doesn’t complete the purchase, their data is sent to HelpGrid or Logicall after a short delay. A call center agent can then reach out to help them complete the sale. If the customer comes back and buys within the delay window, the pending abandoned-cart call is automatically cancelled.

New Order Follow-Up

After a successful purchase, order data is sent to SalesBound, Committed Coaches, Nuyu, HelpGrid, or Logicall. Ideal for high-ticket offers where a “welcome call” or “upsell call” is part of the flow.

Failed Payment Calls

When a first-time charge fails (bad card, fraud decline, AVS mismatch, etc.), the customer data — plus the full decline context — is sent to the provider after a configurable delay. If a successful sale for the same customer lands inside that delay window, the pending call is automatically cancelled, so you never call a customer who just recovered themselves.

Subscription Dunning Escalation

When a subscription renewal fails and the retry count reaches your configured escalation threshold, the failed payment data — including the gateway decline code and message — is sent to providers with subscription support. Agents can call the customer to update their payment method. If the next retry succeeds inside the delay window, the pending call is cancelled.

Cancellation Routing

When a subscription is cancelled (voluntarily or because dunning was exhausted), the data can be routed to providers for a retention call attempt.

Winback / Re-engagement

30 days after a subscription cancels, a subscription_winback event is fired with the cancel reason, original purchase details, and contact info. Providers can use this as a re-engagement lead (“we miss you, here’s X% off to come back”).

Setup

1

Create the integration

Go to SettingsIntegrations. Choose your provider and enter the Webhook URL or API Keys provided by your call center account manager. Save.
2

Configure merchant filtering

Set the integration to listen to All Merchants or a specific Whitelist. Use the whitelist if you have different call centers for different products or regions.
3

Configure per-event behavior

In the Events table on the integration form, toggle on each event you want the provider to receive and — for failed-payment / subscription-failed events — set a delay and an optional decline-code filter. See Per-Event Configuration below.
4

Enable subscription escalation (optional)

Go to SettingsMerchants, edit your merchant, and open the Email tab. In Dunning Configuration, set Callcenter Escalation After Retry # and enable Send to Callcenter on Cancel if needed. These are merchant-level gates on top of the per-event integration config — the integration still has to have the corresponding event enabled for anything to be sent.
5

Test the connection

Use the Test Webhook button (available for most providers) to send a sample payload and verify the connection is active.
Always verify your Webhook URL with a test before going live to ensure your data is being captured correctly.

Per-Event Configuration

Each integration exposes an Events table with one row per supported event type. For each row you can configure:
OptionWhat it does
EnabledMaster on/off for this event on this integration. When off, no sends of this event will go to this provider — even if the merchant-level dunning gate fires.
Delay (seconds)How long to wait before actually sending the event. Lets counter-events (e.g. a successful sale) cancel the pending call. Default 60 for abandon / failed_payment / subscription_failed; 0 for immediate-fire events (sale, subscription_cancel, subscription_winback).
Decline-code filterOnly applies to failed_payment and subscription_failed. A comma-separated list of decline codes combined with a Whitelist (only these) or Blacklist (skip these) mode. Lets you avoid calling customers whose card was declined for a reason they can’t fix (e.g. do_not_honor hard fails) or only call for actionable decline reasons.

Delays & Auto-Cancellation

Delays are the mechanism that makes the system self-correcting. Two high-value cancellation flows happen automatically:
  • Purchase cancels abandoned-cart and failed-payment calls. If a customer’s email or phone matches a pending abandon or failed_payment call and a successful sale comes in inside the delay window, the pending call is marked cancelled and the provider is never contacted.
  • Successful renewal cancels pending subscription-failed calls. If a subscription_renewal_failed was queued for a customer and the next retry succeeds before the delay elapses, the pending call is cancelled.
You can monitor this in the Logs section — cancelled dispatches are labelled with the counter-event that triggered the cancellation.

Decline Code Filtering

For failed_payment and subscription_failed events, each failed charge is enriched with the full decline context from the gateway:
  • decline_reason — human-readable reason (e.g. “insufficient funds”)
  • decline_code — gateway-normalized short code (e.g. insufficient_funds, generic_decline, lost_card)
  • error_code — top-level error class (e.g. card_declined)
  • gateway_response_code / gateway_response_message — raw gateway output
Use the Decline-code filter on the event row to control which failures reach the call center:
  • Blacklist (default mode, empty list) — send every decline except the codes you list. Useful for excluding hard fails (lost_card, stolen_card, fraudulent, do_not_honor).
  • Whitelist — only send declines with the codes you list. Useful when you only want to call for specific recoverable reasons (insufficient_funds, expired_card, card_declined).
The exact code values depend on the gateway. Stripe codes are listed in Stripe’s decline_code docs; NMI returns the response text as both responsetext and response_code.

Monitoring

You can see all outbound postbacks to your call centers in the Logs section of your dashboard. Each dispatch shows:
  • Integration + event type
  • Scheduled time and actual send time
  • Status (pending, sent, cancelled, failed)
  • If cancelled — which counter-event triggered the cancellation
  • If failed — the error response from the provider
If a failed_payment call is never being dispatched, check (in order): (1) the provider’s global capability in the matrix above, (2) the Enabled toggle for that event on your integration, (3) the decline-code filter mode + list, and (4) the merchant-level Callcenter Escalation After Retry # gate if this is a subscription renewal.