Moving from Gravy to RRLabs without interrupting billing
Gravy is a managed failed-payment recovery service that combines software with a human outreach team.
Why teams compare the two
- Wanting an in-house, automated workflow rather than outsourced outreach.
- Needing per-decline-code control over retry timing.
- Preferring a software price with a success fee over a managed-service engagement.
Gravy vs RRLabs, side by side
| Capability | Gravy | RRLabs |
|---|---|---|
| Channel reach | Software outreach supplemented by a human recovery team. | Multi-channel: email (Resend or SendGrid), WhatsApp (Cloud API or Twilio) and SMS (Twilio), chosen per attempt. |
| Recovery timing | Managed by the service team alongside the platform schedule. | Retry timing is derived from the decline reason — insufficient_funds, expired_card and 3ds_required each get a different schedule, with quiet hours respected in the customer's timezone. |
| Copy tuning | Written by the managed service team. | Message copy is generated per attempt from the decline reason, amount at risk and customer tenure, with a deterministic template fallback if the AI provider is unavailable. |
| Pricing model | Managed-service engagement, typically performance-based. | Performance-aligned: a monthly base plan plus a success fee charged only on provider-confirmed recovered revenue. Current figures live on the pricing page. |
| Implementation | Onboarding with the service team. | Connect your billing provider with read-only credentials and point one webhook at RRLabs. No code changes to your checkout and no migration of subscriptions. |
| Attribution | Reported by the service against the merchant's billing platform. | A recovery is only counted when the payment provider confirms the charge succeeded — the provider stays the source of truth for every dollar. |
Gravy details reflect that vendor's own public product documentation and may change. RRLabs details describe what is implemented today.
What happens after a payment fails
T+0s
Payment failed
Provider webhook received and verified
T+2s
AI analysis
Decline reason classified, amount at risk scored
T+5s
Dynamic email
Copy generated for that decline code and customer
Day 2
Smart retry
Retry scheduled only when the decline code is retryable
Day 2
WhatsApp push
Second channel used when the email went unanswered
On success
Recovered
Counted only when the provider confirms the charge
Timings describe the configured workflow, not a guaranteed outcome. Every step is skipped when the decline reason makes it counter-productive.
Switching without a billing interruption
Step 1
Run RRLabs alongside Gravy
Connect your payment provider to RRLabs with read-only credentials and leave Gravy switched on. RRLabs ingests the same failure webhooks and builds its recovery view without sending anything yet.
Step 2
Move one segment across
Enable outbound recovery for a single plan, currency or decline reason. Both systems keep reading from the provider, so nothing about the active subscription or its billing cycle changes.
Step 3
Turn Gravy messaging off
Once provider-confirmed recoveries are landing in RRLabs for that segment, disable Gravy's outbound dunning and widen the RRLabs scope. Historic attribution stays in Gravy — RRLabs never rewrites past invoices.
Frequently asked questions
- Does RRLabs include a human recovery team?
- No. RRLabs is software. Every message is generated and delivered automatically, and you can inspect the exact copy, channel and timing for each attempt.
- Which is better, managed recovery or automated recovery?
- Managed services can be worth it for high-value B2B contracts where a phone call is appropriate. For self-serve subscription volumes, automated multi-channel recovery scales without a per-account cost.
Run RRLabs alongside Gravy first
Connect your payment provider with read-only credentials. RRLabs reads the same failure events and shows you what it would have done before it sends anything.
Get early access