Autopilot / What it writes

What it writes

Autopilot does not write whatever it likes. It selects from a fixed set of activation archetypes, each with a purpose, a trigger shape and a list of facts it cannot be planned without — and three of the five are the only ones allowed to go live before your account has been measured.

The plan you see before authoring names every archetype it considered, which ones it selected, and — for the ones it did not — whether that was a missing fact or a deliberate hold. Those are different problems: a missing fact is fixed by you supplying it, a hold is fixed by time.

Permission warm-up

Day one

Explain what notifications are for, and ask only from someone who has seen the reason.

Fires on: A later session, from a user who has not granted it yet.
Cannot be planned without: Nothing beyond the profile bar.

Planned first when several gaps are open. A denied system permission is permanent until the user goes into Settings, so getting this one wrong is the least recoverable mistake in the set.

First result

Day one

Carry a new user to the moment the product makes sense, before they leave.

Fires on: The aha event has not happened, some days after install.
Cannot be planned without: Your aha moment — question three of the five.

Empty screen rescue

Day one

Give somebody staring at an empty screen a first thing to do.

Fires on: A later session, with the list still empty.
Cannot be planned without: An empty screen in your screen inventory.

If your app has no empty state, this is never planned. Proposing it would be proposing a flow with nowhere to appear.

Paywall

Waits for data

The subscription pitch, at the moment it has been earned.

Fires on: A qualifying event, subscription status, or a given session index.
Cannot be planned without: A connected revenue source, and how you charge.

A paywall is where being wrong costs money the same day, so autopilot waits until it can measure this account rather than assume from its category. It becomes available once purchases are flowing and your traffic can read a result.

Trial and billing moments

Waits for data

Reach somebody whose trial is ending, whose payment failed, or who is in a grace period.

Fires on: Trial ending within a window, billing retry, or grace period.
Cannot be planned without: A connected revenue source, and trial-shaped pricing.

These fire against real billing state, so autopilot waits until the revenue connection has been proven to deliver it. A reminder sent on a wrong trial date is worse than none.

Why the paywall is not in the day-one set

It is not that the paywall matters less. It is the most valuable flow in most subscription apps, and that is the reason: it is the one where being wrong costs money on the spot rather than costing you an unread screen. On day one autopilot has category priors and your profile — which is enough to write a permission warm-up and not enough to write the screen your revenue runs through.

Your existing paywall keeps doing its job in the meantime, whether it lives in RevenueCat, Adapty, Superwall or your own code. Autopilot does not need to own it to work.

How many, and in what order

The plan carries a coverage quota, so a first set is a handful of flows rather than everything at once. When more gaps are open than the quota allows, the ranking above decides. Later rounds pick up what was left once the earlier flows have data.

What it never writes

Your own screens.Autopilot writes Uplift flows. Your app's interface is not in scope on any tier or autonomy level.
Cancel-save and win-back flows.Out of scope by design — that is RevenueCat Customer Center's job, and doing it badly in two places serves nobody.
Anything you locked. Locks set at the approval gate are enforced in the schema, so a patch that would violate one cannot be represented, let alone published.