- Important considerations
- What does the feature do and how does it work
- Setup instructions
- Skio’s new dunning feature provides robust optimizations for the dunning process for failed payments
- Customize your dunning logic to as many retries as you see fit and offer discounts to subscribers if they are successfully recovered
- Use the “enhanced retries” to let Skio predict the best time of day, week, and number of retries to recover the most subscriptions for you
- Use our Klaviyo integration to build our robust flows notifying
- All merchants have historically been setup with a default, daily retry process for 14 days
- Dunning settings previously set up will be migrated to our new dunning logic and all subscriptions currently in dunning will continue with their expected retry count
- Please reach out to firstname.lastname@example.org or your Merchant Success Manager to enable this feature
What does Enhanced Dunning do?
The dunning process is an important churn prevention window that starts when a subscription fails to renew due to an invalid payment and ends when the subscription successfully renews or hits the max number of retries possible and is canceled.
Skio’s upgraded, enhanced dunning introduces new retry logic previously unavailable for merchants as well as a brand new tool built on our newest data model. Previously, merchants could only change the number of max retries for a subscription in dunning and the number of retries during the dunning process.
Now, merchants can create treatment blocks and each treatment block can have its own retry count and number of retries. Additionally, merchants can include automatic discounts into a specific treatment such that if the subscription is recovered via a successful payment, the subscription will get a discount on their successful rebill order.
What do Enhanced retries do?
Our enhanced retries allows Skio to choose the best time to recover your subscriptions based on our newest data model. We have analyzed the optimal time of day, day of week, and day of month for recovering subscriptions by error.
When enabled, Skio will choose when to retry a subscription in the dunning process for the merchant. We will not override the total number of retries, but we will override the retry interval if there is a more optimized solution based on our model. For example, in the first campaign block in the screenshot above the retry interval is every 1 day for 3 total attempts before moving to the next retry block. Based on our model, we may space out the retries interval to 2 days after the first retry, then 3 days, and then 4 days before moving to the next campaign block.
If a subscription is recovered via our enhanced retries logic, we’ll mark the subscription in the user table under the smart adjustment column:
In addition to the Dunning dashboard which can be found in the Skio Data Platform (see Dunning dashboard guide), there are analytics built into the campaign blocks under the “Results'' tab. Within each block, there are 3 main metrics that give you an overview of the performance of the dunning campaign. For more granular insights, use the Dunning dashboard.
The three metrics provided:
- Currently in dunning: the count of subscriptions currently in dunning in this campaign block
- Recovered so far: the count of subscriptions that were recovered in this specific campaign block (and didn’t progress to the next block)
- Failed so far: the count of subscriptions that failed all retry attempts in this campaign block and would progress to the next block
Are there any recommendations or best practices?
Make sure to enable the “enhanced retries” toggle so that Skio can choose the optimal rebill time for each subscription!
For campaign blocks, we recommend a few back-to-back retries in an initial block, then spacing it out, and then offering a discount in a third campaign block like this:
Klaviyo & notifications
In Klaviyo, Skio passes over a Failed Billing Attempt metric that will fire for each failed billing attempt. This metric can be used to create a robust flow to notify subscribers their order failed to process and that they need to update their payment method on file. The error code and error message are passed over in this metric so you can create trigger splits in the flow to only notify subscribers if their order failed for a specific reason. For example, it might be worth tailoring a custom message to subscribers who have an order fail due to "insufficient funds" letting them know their order will be retried rather than asking them to update their credit card.