Every retry schedule encodes a set of beliefs about strangers' bank accounts. The beliefs are rarely written down, which makes them impossible to argue with and even harder to improve. The schedule says day one, day three, day seven, and behind those numbers sit assumptions: that money arrives on certain days, that a bank's no softens over time, that persistence reads as diligence rather than pressure. Some of those assumptions are true for your subscribers. The only way to learn which is to treat the schedule as a hypothesis and run it like one.
Begin by writing the hypothesis in a falsifiable shape. Not "our timing is good," which no evidence could embarrass, but something like: most of our insufficient-funds failures heal when the retry lands near a payday, and attempts before that payday are mostly wasted. That sentence can lose. It points at a specific code, a specific mechanism, and a measurable outcome: recovery rate per attempt, by attempt timing, for that code alone. Most retry reporting blends every code into one recovery number, which guarantees the timing question can never be answered, because the signal from one code drowns in the noise of the rest.
The experiment itself is unglamorous. Hold the total number of attempts constant, because a schedule with more swings will usually win on volume alone and teach you nothing about timing. Move the attempts. Compare recovery per attempt, not recovery overall, and let the test run long enough to cross at least two pay cycles, since a window that covers one payday pattern proves only that the pattern existed once. The practical reference we keep open while doing this is this breakdown of when to retry a failed payment, mostly for its discipline about separating the codes before arguing about the calendar.
Two findings tend to survive this kind of test, across very different subscriber bases. The first is that the earliest retry is usually the most valuable one, not because day one is magic but because freshness compounds: the subscriber still remembers the service, the failure notice still reads as news, and the fix, if one is needed, happens while the episode is young. The second is that late attempts earn their keep only when they are aimed, placed on days when money plausibly exists, rather than spread evenly out of a sense of fairness to the calendar. Even spacing feels scientific. It is usually just tidy.
There is a failure mode to guard against, and it is the experimenter's own hope. A timing change shipped alongside new message copy, a new landing page, and a holiday weekend will produce a result that belongs to all four parents, and the team will credit whichever one they already believed in. Change one thing. Record what you expected before you look. Write down the result even when the hypothesis loses, especially then, because a schedule that survived an honest loss is worth more than a schedule that was never questioned.
Keep the log of these tests somewhere the next person can find it. Retry knowledge in most teams lives in one operator's memory, and when that person leaves, the schedule becomes folklore: numbers nobody chose, defended by nobody, changed by nobody. A short written record, what was tried, what was expected, what happened, turns a fragile habit into an asset the business actually owns.
Schedules are beliefs with dates attached. Test them like beliefs and maintain them like code.
That testing posture is built into Swipe Again: attempts are recorded against their outcomes code by code, so the calendar can be argued with evidence instead of seniority. Your subscribers' paydays are knowable. The only real mistake is never asking.
Top comments (0)