External Call Center Integrations

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.

​

Supported Providers

​

What Each Provider Supports

​

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

​

Per-Event Configuration

Each integration exposes an Events table with one row per supported event type. For each row you can configure:

​

Send from an automation

Instead of the Events table, you can send leads from an automation. Use it when you want to choose which contacts go to which call center, test two call centers against each other, or add steps around the call (an email first, a wait, a condition).

1. Open Automations and create an automation with one of these triggers: On Abandoned Cart, On Failed Payment, On New Purchase, On Subscription Renewal Failed, On Subscription Cancelled or On Subscription Winback.
2. Add the Send to call center step and pick the call center.
3. Optional: set a Delay (minutes). Empty uses the delay from the call center’s Events table.
4. Optional, for failed payments and failed renewals: a Decline codes list and whether to send for those codes only or for every code except them. Empty uses the call center’s own filter.
5. Save and turn the automation on.

The step sends the trigger’s event with the same lead format the Events table uses: product names, commission, merchant and affiliate filters and the phone requirement all come from the call center’s settings. A purchase still cancels a pending abandoned-cart or failed-payment call, a paused call center still sends nothing, and the provider must support the event (see the table above: Committed Coaches, SalesBound and Nuyu do not take abandoned carts). The builder will not save a step whose call center does not take the trigger’s event: the error names the call center and the event, so pick another call center or another trigger. When a contact who got an abandoned-cart call buys, the call center gets its recovered notice as before. Two rules from the merchant still apply: a Test merchant sale is never sent, and On Subscription Renewal Failed only sends after the merchant’s call-center escalation retry count is reached. A test run from the builder never sends.

​

Move a call center to automations

A call center that already sends from its Events table keeps doing so until you move it. The Automations panel at the top of the integration page shows how it sends today and how many automations use it.

1. Click Move to automations.
2. Check the list: one automation for each event the call center receives today (an event whose switch is off is not moved, and an event an active automation already sends is skipped).
3. Click Move to automations to confirm.

In one step the automations are created and turned on, and the call center’s event switches are turned off, so no lead goes out twice and none is missed. Calls already scheduled still go out. The merchant rules that applied before still apply: a cancellation goes out only from merchants with Send to Callcenter on Cancel on (no cancellation automation is created when no merchant has it on), and a failed renewal waits for the merchant’s escalation retry count. The delay, decline codes, merchant and affiliate filters stay on the integration page and the automations use them. You can then edit each automation, for example to put a split test in front of it. Call centers are moved one at a time; nothing is moved for you. When the step does not send for a contact (the call center is paused or off, its merchant filter or phone rule leaves the contact out, the decline code is filtered, or a rule above applies), the reason is kept in the call center’s dispatch log. In a split test the arm counts it as not sent, next to sent, cancelled and failed calls.

​

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