Skio Automation: The Sequences That Save a Renewal

What is skio automation, and which sequences does it actually run?

Most write-ups on skio automation describe each sequence as if it runs in a vacuum. It doesn’t. The collision risk between them — a win-back email landing on a subscriber who still has an open skip prompt sitting in their inbox, or a dunning retry firing the same week as the pre-renewal notice — is what actually decides whether a subscriber reads care or reads noise, and it’s the part no vendor documentation covers, because each sequence gets built and tested on its own.

Skio is a subscription management app for Shopify merchants, and Recharge is the other platform most $3M–$30M subscription brands will have evaluated at some point. Both expose the same four automated sequences around a subscription’s lifecycle, and this article stays on those sequences: how each one is triggered, what order they fire in relative to each other, and what breaks when two of them land on the same subscriber in the same week. It does not compare Skio against Recharge as a platform choice, and it does not cover migration — that’s a separate decision with its own separate page.

The four sequences are: a dunning sequence that responds to a failed payment, a pre-renewal notification that warns a subscriber before the next charge, a skip or swap prompt that intercepts a subscriber on the way to cancelling, and a win-back sequence that starts once a subscription has already lapsed. Each one answers a different question at a different point in the contract, and each one is configured with a different kind of trigger.

What triggers the dunning sequence, and where does it end?

A dunning sequence starts on one event: a payment attempt against the subscriber’s card fails. That’s it — no calendar date, no manual review, just a failed charge from the payment processor. From there it runs a fixed number of retry attempts, spaced out over a fixed window, before it either succeeds, or the account moves to a different state.

The retry count and spacing are settings, not a fixed rule. A common starting pattern is a short first retry within a couple of days, a second a few days after that, and a final attempt roughly a week to ten days out — described here as an illustrative structure, not a measured average, because the exact cadence that suits your average order value and your processor’s own retry logic is something to set and test in your account rather than copy from a guide.

Where dunning ends matters more than how it starts. A successful retry returns the subscriber to normal billing with no further action needed. A final failed attempt should hand the subscriber off cleanly to one of two places: a paused or grace-period state if the account allows one, or directly into the win-back sequence if it doesn’t. The handoff is the part teams skip. If dunning simply stops after its last retry with no downstream trigger, the subscriber sits in limbo — no longer being charged, not yet being asked to come back — and nothing in the automation notices.

Timing is the other place dunning collides with the rest of the system. If a payment fails during the same window the pre-renewal notice is scheduled to go out, a subscriber can receive a “your renewal is coming up” email and a “we couldn’t charge your card” email within days of each other, about the same charge. Neither message individually is wrong. Together, they read as a system that doesn’t know what it already told the subscriber.

What does the pre-renewal notification actually warn a subscriber about?

A pre-renewal notice is a calendar-triggered message: it fires a set number of days before the next scheduled charge, regardless of anything else happening on the account. That’s the setting that matters most here — a calendar trigger, not an event trigger — because the entire point of the message is advance warning. An event-triggered version, one that only fires after some other action, defeats the purpose.

The content is usually simple: the date of the next charge, the amount, and a link that lets the subscriber skip, swap or edit the order before it processes. What it should not do is arrive after the charge has already gone through. That failure mode is a trigger misconfiguration — someone set the notice to fire relative to the wrong date field, or the send window didn’t account for a time-zone offset — and it turns a proactive message into a confusing one, because the subscriber is now being warned about something that already happened.

The pre-renewal notice is also the point where a skip or swap offer most naturally belongs, since the subscriber still has time to act before being charged. Some programmes fold the offer directly into this message rather than waiting for the subscriber to initiate a cancel flow — worth deciding deliberately, because it changes who sees the skip/swap option: everyone approaching renewal, versus only the subset who go looking for the cancel button.

What do skip and swap prompts do before someone cancels?

A skip prompt asks a subscriber to keep the plan and delay the next order. A swap prompt asks them to keep the plan and change what’s in it — a different flavour, a different size, a different product entirely. Both are intercepts: they exist to give the subscriber an alternative to cancelling outright, offered at the moment they’re most likely to walk away.

Most setups trigger these from the cancellation flow itself. The subscriber clicks cancel, and before the cancellation completes, the interface offers skip or swap as an alternative. Some programmes add a second, proactive version sent by email a few days before a renewal, independent of whether the subscriber has opened the cancel flow at all — this catches the subscriber who would otherwise just let the card fail on purpose rather than go through a cancellation screen.

Running skip and swap prompts together only works if the copy is explicit about which is which. A subscriber shown two buttons that both read like “change something” without saying what changes will pick whichever is listed first, not whichever actually solves their reason for wanting to cancel. The prompt that gets the reason wrong — offering a swap to someone who wants to pause spending, or a skip to someone who’s unhappy with the product itself — doesn’t reduce cancellations, it just delays them by one cycle.

Cancellation reason matters here as a setting, not an afterthought. If the platform captures why someone is cancelling — too expensive, too much product, quality issue, no longer needed — that reason should route to a different offer, or to no offer at all. A quality complaint routed into a discount-based skip offer answers a problem the subscriber didn’t raise.

What starts the win-back sequence, and how long does it wait?

The win-back sequence starts on a status change: the subscription moves from active to cancelled or lapsed, whatever the underlying cause — a voluntary cancel, a final failed dunning retry, an expired card that was never updated. From the automation’s point of view, all three look the same: a subscription that was active and is now not.

That’s the setting worth checking carefully, because it means a win-back sequence by default treats a subscriber who churned over a product complaint identically to one who churned because a card expired while they were travelling. The two need different offers, if they should get an offer at all. A subscriber who cancelled after a refund request or a quality complaint should be excluded from the standard win-back flow and reviewed separately — sending a discount code to someone who just complained about the product reads as indifferent to what they said, not persuasive.

The sequence itself typically waits a period after the lapse before the first touch, rather than firing immediately — enough time that a lapse caused by a temporary card issue has a chance to resolve on its own, through dunning, before the subscriber gets treated as fully gone. How long that wait should be is a setting to test against your own subscriber base rather than assume: too short, and win-back messaging overlaps with dunning retries that are still in progress; too long, and the subscriber has moved on entirely before the first message arrives.

How do the four sequences compare on trigger, timing and effort to configure?

The table’s main point is the trigger-type column: two of the four sequences run on a calendar, two run on an event, and mixing up which kind a given sequence should use is the most common configuration mistake. A skip prompt built as a calendar trigger fires on a fixed schedule whether or not the subscriber has any intention of cancelling; a pre-renewal notice built as an event trigger might not fire at all if nothing else on the account changes.

For a rough sense of how much churn is actually within reach of these four sequences versus outside their scope entirely, the subscription churn calculator gives a starting split between recoverable and structural churn, and the DTC consumables churn benchmark gives a category reference point to check your own numbers against.

Where do teams get the sequencing order wrong?

The most common mistake isn’t in any single sequence — it’s in the absence of a shared view across all four. A payment fails three days before a scheduled pre-renewal notice was due to go out. Dunning starts. The pre-renewal notice, built on its own calendar trigger with no awareness of the dunning state, sends anyway. The subscriber now has two emails within a week referencing the same charge, one asking them to update a card and one telling them a charge is coming — and only one of those is still true.

Skip/swap and win-back show a second version of the same problem. A subscriber clicks the skip option in a cancellation flow, which delays their next order by one cycle rather than cancelling outright. If the win-back sequence is triggered purely off a lapse event and doesn’t check whether a skip is currently active on the account, a subscriber who just chose to stay can still land in a “we miss you” sequence built for people who left.

The fix in both cases is the same: before any of these four sequences goes live, check what state fields the platform exposes — active, paused, cancelled, in dunning, skip pending — and make sure every sequence’s trigger condition excludes the states that belong to a different sequence. This is configuration work, not a feature request, and it’s the step that gets skipped when each sequence is built by whoever happens to own that part of the lifecycle that week, without anyone reviewing the four against each other.

What settings actually decide whether this reduces churn?

Frequency capping is the setting most programmes skip. Without a cap, a subscriber approaching renewal with a recently failed card can receive a pre-renewal notice, a dunning email and a proactive skip prompt inside the same seven days, from three sequences that were each configured correctly in isolation. A cap that limits how many automated messages a single subscriber can receive in a rolling window, regardless of which sequence they come from, is worth setting even if it means occasionally delaying a message by a day or two.

Suppression rules matter as much as triggers. A subscriber who has already skipped this cycle shouldn’t also see a proactive skip prompt for the same cycle. A subscriber currently in an active dunning sequence shouldn’t simultaneously enter a win-back sequence, even if a status field technically reads “lapsed” for a few hours between a failed final retry and the account update. Building suppression checks against current sequence membership, not just subscription status, closes most of these collision cases.

Channel choice is a smaller but real decision: whether a given sequence sends by email only, or adds SMS. Whether SMS is available at all, and what consent it requires, is a plugin and platform setting to confirm directly rather than assume, and it varies by account and by market — worth checking with your platform’s current documentation before building SMS into any of these four sequences, and worth confirming consent requirements with counsel rather than guessing at what a given regulation allows.

How do you check these sequences are working once they’re live?

Testing a single sequence in isolation is straightforward: trigger a test failed payment and watch the dunning emails arrive on schedule, or set a test subscription’s renewal date a few days out and confirm the pre-renewal notice fires. What that kind of test doesn’t catch is the collision behaviour, because a single test account only ever has one sequence active at a time.

A more useful check is to build a small set of test subscriptions that each sit in two overlapping states at once — one with a failed payment during its pre-renewal window, one with an active skip pending during a status change to lapsed, one recently refunded and then cancelled — and watch what each one actually receives over the following two weeks. This catches the cases a single-sequence test can’t: whether suppression rules actually stop a duplicate message, and whether the win-back exclusion list correctly holds back a subscriber who complained rather than one who simply drifted away.

Worth checking on a recurring basis, not just at launch: a plugin update, a change to cancellation-reason categories, or a new payment processor added to the account can quietly change what data a sequence’s trigger condition can see, which breaks a suppression rule without breaking the sequence itself. A quarterly review of a handful of test accounts moving through overlapping states is cheap compared with finding out from a subscriber complaint that two sequences fired at once.

Who is this level of automation not for?

This setup assumes a subscriber base large enough that manual review of every dunning, renewal, skip and win-back event isn’t realistic — which in practice means brands doing $3M–$30M in revenue on Shopify Plus or a paid subscription platform, the audience these four sequences are actually built for. Below that volume, a founder or a small support team reviewing failed payments and cancellations by hand each week will likely catch the collision cases this article describes faster than a rules-based automation stack will, simply because there are few enough of them to see directly.

It’s also not for a subscription programme still deciding on its cadence, pricing or product fit. Automation sequences make an existing subscription model run more smoothly; they don’t fix a subscription model that subscribers are leaving because the product itself, the price or the delivery interval doesn’t match what they actually want. Sequencing four messages correctly around a subscription nobody wants to keep just delivers the cancellation more politely.

For brands that are past that stage and scaling a subscription programme that’s already working, the sequencing questions in this article are the next layer to get right — covered in more detail for scaling brands building out the rest of their retention stack.

Skio automation only works as a whole when the four sequences are treated as one subscription retention problem rather than four separate build tickets: reviewing trigger types, suppression rules and state fields across all four sequences at once, rather than building and testing each one in isolation. That’s the kind of work covered under subscription retention.