Stop Selling Features, Sell the Switch

Summary

Your client's SaaS website isn't failing because it looks bad. It's failing because it never answers the one question that matters: why should I switch? For agency work, you can't rebuild a unique persuasion model for every product. Instead, use the same five-question audit to find the switching trigger for any SaaS. Then apply that trigger across every page: features become proof, pricing becomes clarity, FAQ becomes objection-crushing, and API docs become a developer's first win. This framework turns a one-off redesign into a repeatable process. The result: faster delivery, fewer revisions, and pages that actually convert.

Your client doesn't have a design problem. It has a switching problem. The buyer already has a tool, a workflow, and a team who hates change. They are not comparing your client's features against a blank page. They are comparing the pain of staying with the pain of leaving. The website's job is not to list what the product does. It's to make the switch look easier and more valuable than the status quo. If it doesn't do that, the site is wallpaper.

Working at an agency, you feel this acutely. You take on a SaaS client, the founder says 'we need a modern site,' and everyone assumes the fix is visual. It isn't. You can drag an award-winning design onto the wrong message and it will convert exactly the same as the old site. But find the switch trigger and the message does the heavy lifting. You just have to find it quickly — for every client, every quarter, across industries you don't know yet. That's why you need a framework you can run on day one, without a three-month discovery phase.

Think about what a switch involves: exporting data, training the team, learning a new UI, changing habits. Your client's website must make that sequence feel inevitable. A feature list cannot do that. A clear picture of life after the switch can. That picture is the message. Everything else on the site supports it.

Here's the framework: define the switch. Then force every page to argue for it.

Objection	What it's really protecting	What to do instead
'Every client is different.'	Your fear of templates	Find the switch trigger with a five-question audit
'We need more screenshots.'	The fear of empty sections	Replace product shots with proof
'Pricing is sacred.'	The CFO's anxiety	Use clarity to reduce sticker shock
'API docs are a dev problem.'	The dev team's gatekeeping	Treat docs as a persuasive medium
'FAQ is boring.'	Support's overwhelmed inbox	Use FAQ to close last-moment doubts
'We don't have time to customize.'	Perfectionism over delivery	Build a skeleton, not a snowflake

Use this table as a checklist in the first meeting. Any objection on it is not a real blocker. It's a request for a different framework.

'Every client is different' is true — and irrelevant

Here's the shift: the product is different, the market is different, the buyer's behavior isn't. Buyers want three things: 'Do I understand this?' 'Can I trust it?' 'Is switching cheaper than staying?' That's universal. So don't standardize the design. Standardize the interrogation.

Start with a five-question audit. Run it in the first discovery call. It takes twenty minutes and works for any SaaS.

• Who is the user, and who is the buyer? (They're rarely the same person.)
• What are they doing today instead of using your client's product?
• What is the single annoying pain in that current workflow?
• What do they fear will break if they switch?
• What is the fastest 'win' they'd get right after switching?

Walk through two clients to see how it works.

First, a project management tool. The user is a team lead, the buyer is also the team lead. It does the same thing as the incumbent. The pain? No one knows who owns the next task. The fear? Migrating hundreds of projects and losing all status. The fast win? A dashboard that shows task ownership at a glance. The trigger: 'Never chase a task owner again.' That's the headline.

Second, a real estate lead tracker. The user is an agent, the buyer is a broker. The pain? Duplicate leads appear in three places and the good ones go cold. The fear? Agents won't log data. The fast win? Auto-enrichment from MLS listings so agents are done in two clicks. The trigger: 'Never lose a lead twice.'

Same five questions. Two different products. You now have the central message for the homepage, the first paragraph of the feature section, and the subject line for the email sequence. The switch trigger is a renewable resource: every page, every section, every subhead can argue for it. That's your starting line.

The same trigger also gives you the site map. The page that explains the trigger is the homepage. The page that proves the trigger is the feature section. The page that removes the fear is the FAQ. The page that shows the cost of switching is the pricing page. Suddenly the whole site has one narrative instead of a page-by-page committee.

You can also run a competitive teardown by asking the same five questions about the competitor's site. That's a cheap way to show value on the first call. You'll find the competitor's missing switch trigger, and your client becomes the obvious alternative.

What if the product is a nice-to-have, not a pain-killer? Then the switch trigger is bigger: money saved, risk avoided, or status gained. For a compliance tool, the trigger is 'avoid a fine.' For a security tool, the trigger is 'pass the audit.' For a social media scheduler, the trigger is 'get two hours back every week.' The audit still finds it. Some triggers are just less emotional.

Screenshots are the lowest-value proof on the page

Take the loneliest line in your client's feature table: 'OAuth 2.0 support.' What emotion does that trigger? None. It's a checklist item for a developer who isn't the buyer. Yet when you ask the client for their feature page, they hand you a wall of these. Fill the page with screenshots and you're doing something even more common: showing the product instead of the outcome.

Screenshots have a place. A good GIF of the product at work is evidence. But most screenshots are product portraits. Buyers need a before-and-after story. The feature section is the best place to tell it. Use the Feature-Benefit-Proof formula (FBP). Name the feature, connect it to a benefit, then prove it with a fact, a process, or a small demo. No invented numbers — use observable outcomes like 'works with Google Workspace' or 'set up in under a minute.'

Original block from the client:

• OAuth 2.0 support
• Role-based access control (RBAC)
• SCIM provisioning

Three bullets of supplier jargon. Now run each through FBP.

Feature: OAuth 2.0 support.
Benefit: One login for the whole team. No more IT tickets.
Proof: Works with Google Workspace and Microsoft Entra.

Feature: Role-based access control.
Benefit: Give admins, editors, and viewers exactly the permissions they need.
Proof: Grant view-only to a contractor in under a minute.

Feature: SCIM provisioning.
Benefit: Add and remove users automatically from your HR system.
Proof: Syncs with Okta and Rippling.

The features didn't change. The persuasion did. Your client will say, 'But enterprise buyers expect to see the words OAuth and SCIM.' True. Add a technical sub-line for the developers who audit the page. But put that line in small type below the benefit. The first audience is the buyer who decides whether to book a meeting. The second audience is the developer who checks the boxes. Structure your feature showcase around proof, not product shots, and you'll stop designing filler.

When you do use a screenshot, make it show a result, not a screen. For the project management client, a screenshot of a board where every task has a clear owner is proof. For the real estate client, a screenshot of a single clean contact record with auto-enriched data is proof. A screenshot of the dashboard's empty state is a design asset, not a persuasion asset.

Put the technical specifications in a collapsible section or a developer resources tab. The user sees the benefit; the developer can dig in. That keeps the page clean and the auditor happy.

A good test for any feature claim: would a buyer repeat it to their boss? 'One login' is repeatable. 'OAuth 2.0 support' is not. If your client's feature page can't pass the water-cooler test, it's not persuasive yet.

Pricing pages are a minefield. That's exactly why you should touch them

You'll hear, 'Don't touch pricing. It's been like this for years.' What they're really saying is 'we're scared.' A confusing pricing page doesn't protect revenue; it leaks it. Your job is to turn the page from a cost negotiation into a clarity statement.

Start by listing the questions your sales team answers every week. Write them down verbatim. 'Do you charge per user?' 'What happens if I downgrade?' 'Is there a setup fee?' 'Can I try it without a credit card?' 'What's your refund policy?' Put those on the page. A buyer shouldn't have to book a call to learn whether you require a credit card for a trial.

Next, take the client's three plans: Basic, Pro, Enterprise. Rename them after the customer's situation. What does each plan actually do for someone? Solo, Team, Organization. Or Creator, Studio, Enterprise. The name is not decoration; it's the first moment of clarity.

Here's a concrete example of a renamed plan table:

Old plan	New plan	The promise
Basic	Solo	For one person who needs a simple workflow
Pro	Team	For a team that needs collaboration and dashboards
Enterprise	Org	For a company that needs security, SSO, and support

Then build the comparison table. Break the pattern of dumping every feature into each row. Lead each row with the user question it answers. 'How many users?' 'Who can we invite?' 'What security features do we get?' The buyer reads a table to search for 'do I fit.' Make that search easy.

Finally, add a pricing FAQ. Answer the ugly question: 'What happens to my data if I leave?' Write the answer like a human: 'Export everything in one click before your subscription ends. No fees, no lock-in.' That's the switch trust-breaker. Most clients won't write it because it feels like an invitation to leave. It's not. It's permission to buy without fear.

Your agency has a built-in advantage here: you've already asked the five-question audit, so you know the fear. Put the fear in the FAQ. If you need a template to start, the pricing page conversion guide is the template.

Don't let the client hide the pricing. A 'contact us' page is a wall. The switch needs a number to compare against. If the price is high, the page should explain what's included and why it's worth it. If the price is low, anchor it against the cost of the status quo. For a project management tool, the status quo is three separate tools: a task app, a chat app, and a spreadsheet. The price of the switch doesn't look high when you compare it to the monthly cost of all three. Make that comparison explicit on the page.

When you write the pricing FAQ, don't use vendor language. Say 'you' and 'your data.' A pricing page that uses 'we offer, we provide' all the time feels like a company brochure. Flip it to 'you can, your team.' That's the switch happening in the grammar.

You can test the pricing FAQ the same way you test anything else: read it aloud. If a stranger on the other side of a desk would relax, it's good. If they'd raise their hand for a salesperson, you've added friction.

The docs you ignore are closing (or killing) deals

Here's a developer at a laptop. She's evaluating your client's API. Her boss asked, 'Can we integrate with this?' She wants one thing: proof that her team won't waste a week. She isn't starting with the reference docs. She starts at the quick start.

Companies like Stripe, GitHub, and Twilio set the standard for API docs. The secret isn't that they document every endpoint beautifully. It's that they make the first run take five minutes. They show a tiny result that looks like success. That's the switch trigger for a developer: instant, concrete progress.

Your client's API docs are the first page a technical buyer reads after the homepage. If it reads like a phonebook, the deal dies quietly. The docs are a marketing asset, not a technical chore. So do this:

Put the quick start before everything else. Example time. Your client builds a document automation API. The reference is a dense table of contents that goes on for thousands of lines. A developer lands, sees 'Authentication,' and gets discouraged.

Restructure the top of the docs:

1. Write a three-sentence description in plain English. 'Send a contract, get an executed copy back. This API turns templates and data into signed PDFs.'
2. Paste a copy-paste code sample that calls a sandbox endpoint. Show the first response JSON that proves success.
3. Add one use case, 'Invoices that self-assemble,' and link the specific endpoints involved.

Move the full reference below. The developer who copies the first snippet becomes an internal champion. The champion requests a security review, not a rejection. Your client lands before the sales call. The API docs guide walks through the same process.

A use case is a promise with a route. For the document automation client, write 'Invoices that self-assemble: send a PO number and get a formatted invoice, line items, and a PDF back in one call.' That's not a docs page; it's a sales page that happens to contain code.

Include an embedded API key for the sandbox. The moment a developer can paste and see a success, the switch becomes real. No sales call required.

The docs page also feeds SEO. Developers search for exact error messages and integration names. Write pages for those queries: a paragraph for each error code, a page for each integration. That's how the docs become a channel.

Use a persistent sidebar with a 'try it now' button. Add a search bar that indexes code examples. The smoother the search, the more competent the company looks. And don't forget a short video under 90 seconds that shows a working example, not a company overview.

The FAQ isn't support content. It's last-hurdle conversion

'Nobody reads FAQs' — that's what you'll hear until you remember who does: a buyer in a quiet room, hesitant to ask a question. The FAQ is the page where deals close in private. Treat it like that.

HubSpot, Slack, and Zendesk get this right. Their FAQ and help sections are organized, searchable, and concise. That structure is the point. It signals competence. A searchable FAQ makes a buyer think: these people have thought about my problem.

Here's the cheapest improvement you can make to any client's site today: reorganize the existing FAQ into four buying-stage buckets: Getting started, Pricing and billing, Security and compliance, Switching and migration. Then rewrite one answer per bucket.

Let's do the switching bucket. The current answer to 'How hard is the migration?' says: 'Our import tool supports CSV and API.' That's a feature list. Rewrite it as a promise plus a step list:

'We'll import your data for you. Send a CSV, we run a dry run, you verify a sample, and we cut over in a 30-minute window. If anything looks wrong, we roll back instantly.'

Now compare the two answers. Which one closes the deal? The first describes a mechanism; the second describes a safe process. That's the same structure as the feature page: benefit plus proof.

Go further: pull every question that support answers twice a week and write the answer before the ticket happens. That's a never-ending source of landing content. Once the FAQ stops being a dumping ground and starts being a persuasion tool, the whole story stays unified. It's part of the inside-out approach you use for everything else.

Organize with search in mind. A searchable FAQ that finds the answer in one keystroke feels like a product feature. That's exactly the competence signal you want.

Don't make buyers open a separate help center. Put the FAQ on the page that triggered the question. If a pricing question appears on the pricing page, answer it there. If a security question appears on the pricing page, answer it there too. The answer belongs at the point of doubt.

The security bucket is where IT decides to block the tool. Answer things like 'Where is data stored?' with specifics. If you say 'in the EU,' say the region. If you say 'encrypted at rest,' name the standard. A concise answer is stronger than a whitepaper link.

Every FAQ answer should be as short as possible and end with a next step: 'Sign up with a sandbox account' or 'Talk to support.' An answer without a next step is a dead end.

No time? Build a skeleton, not a snowflake

The last objection is the one you're probably feeling right now: 'But I have four clients and a deadline on Monday.' Fair. Treat each project as a custom portrait and you'll always be scrambling. Instead, build a single reusable deliverable: the Switch Memo. It takes 90 minutes to fill out, and it outlines every page.

Switch Memo — one page, six lines:

1. User / buyer split: who shows up, who pays.
2. Current behavior: what they do today instead.
3. The single pain: one sentence, the annoyance.
4. The fear: what they worry will break in a switch.
5. The fast win: the first visible improvement after switching.
6. The proof: logos, results, or security postures that remove fear.

Bring this to the first discovery call. Fill it in as you ask the five questions. By the time you're back at your desk, you have the message framework. The homepage headline is the fast win. The feature page intro is the pain. The pricing table's middle column is the buyer. The FAQ is the fear list. The API docs quick start is the fast win for developers.

This skeleton doesn't make every site look identical. It makes every site persuasive in the same way. You still design for each client's voice, but you stop under-designing the message. If the message is already settled, you can produce the first draft of every page in a day. The agency's real product is the process, not the pixel.

Here's the shift: you're not redesigning sites anymore. You're repositioning them. And because the switch framework survives across industries, you can charge for strategy, deliver it in a repeatable form, and hand over assets that actually convert. Your next kickoff should start with the five-question audit, not with a mood board.

Use the memo to set client expectations early. The founder sees the site is not an art project; it's a persuasion document. That prevents the 'just make it pop' feedback and turns the conversation toward outcomes. Share the memo with the client's in-house marketing team so they can write new pages later without reinventing the message.

When you present the site, start with the switch memo, not the design. Clients approve strategy faster than they approve aesthetics. You'll get fewer 'can we make the logo bigger' requests because you've given them a reason to evaluate the page on message.

The switch is the strategy. Everything else is decoration.

Take one thing from this: don't commission another redesign until you've answered the switching question. Most SaaS sites fail because visitors never find a reason to abandon their current workflow. The site doesn't fail because the logo is too small or the gradient is dated.

Your next kickoff call should be the five-question audit. If the founder can't articulate the switch, push them. If you can articulate it, then every page has a job: feature pages prove it, pricing pages justify it, FAQ pages defend it, and API docs demonstrate it. You'll deliver a better product faster. And you'll have a framework you can run on every client, forever.

A switch-framed site also gets better over time. You now have a hypothesis — the trigger — and you can test it in heatmaps, session recordings, or A/B tests. The framework turns redesign from an event into an experiment.

You don't need a 40-page strategy deck. You need six lines and a willingness to say no to pages that don't serve the switch. That clarity is what clients are paying you for.

Stop selling features. Sell the switch. That's the entire strategy.