Feedback & Communication

Permission Recovery

One channel permission closes → ask through another open channel → reopen or stop

Recover a closed email or SMS permission by asking through the other channel that is still legitimately available.

  • Consent & Permission
  • Email
  • SMS
  • In-app message

31 steps · 9 decisions · 8 exits

Open the canvas

Flow structure

  • 31 steps
  • 9 decisions
  • 8 exits

Core rule

Never ask a closed channel to reopen itself.

Journey plan

When to set it up

Permission reports showing a steady flow of people closing email or SMS permission while the other channel stays open, or the app stays in use, are the signal for this journey. Hold each channel's permission state per person with timestamp and wording, tell an explicit refusal apart from a quiet closure, and give the app its own preference screen; clarify with legal the Turkish restriction on requesting consent through commercial electronic messages. If permissions close because of too frequent or irrelevant messaging, fix that first, or you will be asking people to reopen what drove them away.

How to measure success

Incremental permission recovery rate vs control

What counts is how many more people in the asked group reopen the closed permission by their own explicit choice than in the control group that is not asked; seeing the preference screen or clicking a link is not consent.

How it is counted: Denominator: all people assigned to the two groups at entry. Numerator: those who give an explicit, time-stamped permission with its wording recorded for the closed channel within the same follow-up window after assignment; the journey's effect is the difference between the two shares, and delivery of the request or reaching the preference screen does not change the denominator.

Also track

  • Preference-center reach rateAssigned people who reach the preference screen, as a share; an intermediate step, measured separately from the permission actually being updated.
  • Result by branchRead the email request sent by SMS, the SMS request sent by email and the in-app route separately; each route's gap against control is its own decision.
  • New closures and complaints on the asking channelWatch whether the open channel carrying the request closes too, along with SMS or email complaints; if you lose one permission while trying to recover another, the journey is doing harm.
  • Share dropped as not allowedPeople with an open channel who were closed without being asked again because the request was not allowed, as a share of entries; it shows the refusal record is really being read.

How to set it up

  • Trigger and entryOne person's email or SMS permission closing starts the journey, which then branches on which permissions are open. Randomly split the eligible people who can be asked through an open channel into the journey group and a control group that is never asked.
  • Who must not enterA person with both channels open needs no repair; one with both closed and an inactive app is not reached. Anyone who explicitly refused, or for whom the request is not allowed, leaves before the first request despite an open channel. Scope is one person's email and SMS permissions, one instance each.
  • Timing and channelsEmail closed: SMS asks; SMS closed: email asks. If nothing reopens in 2 to 3 days, one final reminder goes on the same channel, checked 1 to 2 days later. Both closed with the app active: only the in-app preference screen, on each of the next two visits, waiting up to 7 days for each.
  • Exit and handoffReopened permission returns the person to normal email, SMS or CRM communication and cancels queued reminders. If still closed after the final reminder or second preference screen, it stays closed and is not asked again; where the request is not allowed permissions stay closed, and with no reachable channel the flow ends without a message.
  • Frequency and consentAt most two requests per closure, both only through the channel that is already open; a closed channel is never asked to reopen itself. If both channels are closed, no outbound message goes out; only a person who opens the app themselves sees the app's own preference screen, not the operating system's notification prompt.

What to watch when reading the result

  1. 1If the recovery share in the journey group does not exceed the control group, the requests only counted people who would have come back on their own; preference screen visits or clicks do not make up for that. If closures and complaints on the asking channel outweigh the permissions won, do not scale the journey; try dropping the final reminder first.
  2. 2Everything here holds for this branching, these waits and the check on whether the request is allowed. Purchases and engagement after the person returns to normal email, SMS or CRM communication belong to those journeys, not here. While a repair is open, Unengaged Subscriber Sunset stands down; do not count its silence outcome against this journey's period.
  3. 3Put each group's people and reopenings, branch by branch, into the A/B test significance calculator when the gap is small or unclear; if it is not significant, extend the follow-up window and repeat the same read instead of adding another channel or a new request to get around the same refusal.

Frequently Asked Questions

Can I message an opted-out user to request permission again?

Do not use the closed channel for promotional repermission. Turkey also restricts requesting consent through commercial electronic messages. Another open channel does not automatically authorize that request. Offer clear separate choices in a preference center the user voluntarily opens.

Does opening a preference screen or clicking its link count as consent?

No. Record the person's explicit choice for the channel and purpose, with timing and applicable wording. Do not treat preselection or silence as consent. Measure preference-center visits separately from actual permission changes.

When should permission recovery end if the person declines?

Keep permission closed and never reopen it automatically. End when no eligible route exists. Respect a later voluntary change using the current record. Do not repeatedly switch channels to work around the same refusal.

Explore other journeys