A settings panel that sells: ~20% more self-serve upgrades from locked states

At FlippingBook, a platform for interactive flipbooks, content protection meant one thing: a password. Enterprise clients wanted more. Sales lost about 6 leads a month, support got 50+ tickets a month asking how to restrict access, and enterprise customers were ready to pay up to 3x the base price for advanced security. The subscription tiers had no access controls to sell them.

I redesigned the privacy settings into five modes: Public, Shareable link, Password, Protected Embed and Private. This post is about one part of that project, how the modes a customer does not have yet are shown.

Show it locked

The usual move is to hide advanced settings from lower plans. I displayed every mode, with a locked state on the ones the plan does not include.

A customer finds out that the product can do something at the moment they try to do it. If the option is hidden, that moment never happens.

I designed the panel as a vertical stack of large radio cards. Users read it from top to bottom as a scale from public to strict. The locked cards sit on that scale, so a customer on an entry plan sees where the free options end and what comes next.

What happens on click

A click on a locked option opens a contextual tooltip with three things: a short value proposition for the business, a link to the help center, and an Upgrade button. The self-serve sales funnel lives inside the feature, so the customer does not need to leave the settings or talk to sales.

I also made the locked state a component. I added global system-locked states to our UI kit, which gave us one visual language for paywalls, and the same states were reused in other areas of the product.

The numbers

Analytics showed that locked states and contextual tooltips raised self-serve upgrades initiated inside the portal by about 20%, measured by clicks on the CTA. Self-serve means the upgrade bypassed the sales team.

The effect got stronger in Phase 2. When we launched Restricted Access (email, domain and SSO verification), these advanced settings became the main upgrade trigger for B2B accounts on entry-level plans, moving them to Team or Enterprise tiers straight from the Privacy panel.

Across the project, privacy-related tickets dropped from about 50 to about 10 per month, and over 70% of enterprise accounts configured two or more modes in the first three months.

A checklist for a locked state

This is what I would check on any paywalled setting.

1. Visible. The option is on the screen in its natural place, in the same list as the open ones.
2. Obviously locked. The state reads as unavailable before the click, and a hover or press still responds, like on any other control.
3. One sentence of value. The tooltip says what the setting gives the customer, in business words.
4. One action. One Upgrade button, with the help center link next to it as the secondary path.
5. One component. The locked state lives in the design system, so each team that needs a paywall does not draw its own.
6. Measured at the click. Track the CTA from each locked option, and connect clicks to completed upgrades where you can, because a click shows interest and revenue comes later.
7. Honest. Lock only what the higher plan really includes. A fake lock costs more trust than it earns.

Four ways it goes wrong: hiding the feature so customers never learn it exists, a modal wall on click that interrupts a person in the middle of a task, an Upgrade button with no line about what it unlocks, and a different paywall in every part of the product.

What I would still change

In the retrospective of the case I note a structural compromise: password protection is both a standalone mode and a modifier on top of other modes. We kept it to reuse the legacy password logic, which saved weeks of development. A cleaner model would have a user choose who has access first and then toggle password required. It matters for this topic as well, because every extra modifier is one more thing to lock and explain.