Case Study: How an A/B-Tested Webflow Redesign Took Demo Requests From 1.2% to 3.7%

Context: a website that had to become a growth tool

Oscilar is a fraud-prevention SaaS. As the company scaled, the website had one job: bring in more demo requests. A brochure site was no longer enough.

I worked with Oscilar as a direct client. The full project is on the Oscilar case study page. Here I want to go deeper on one thing: how the testing worked, and what you can take from it.

A note on honesty. I will give you the verified results and the general method I use. I will not pretend to remember every single test, because the point of this article is the process, not a list of button colours.

What we measured

One primary metric: the demo request rate, meaning the share of visitors who ask for a demo. Everything else was a supporting signal.

• Demo request rate (primary): 1.2% at the start.
• Average session duration (supporting): are people exploring or leaving?
• Bounce rate (supporting): do visitors find the page relevant at first glance?

Why one primary metric? If you track ten goals, every test looks like a win on something. Pick one number that maps to revenue, and use the rest only to understand why it moved.

Before the first test I also write down the baseline and the date it was taken. It sounds obvious, but many teams skip it and later cannot prove anything improved. A baseline turns "it feels better" into a number you can defend in front of a founder or a client.

I keep the measurement setup boring on purpose: one conversion event for the demo request, one clear definition of a visitor, and the same reporting view every week.

The testing process: how I approach Webflow A/B testing

On Oscilar the approach was to analyse what held conversion back, design several solution variants, and test them against each other iteratively. Below is the general method I follow on Webflow projects. Treat it as how I work, not as a log of Oscilar's individual experiments.

1. Start with a diagnosis

Look at where visitors drop off before you design anything. Analytics, recordings and plain common sense usually show the same few problems: unclear promise, weak call to action, too much friction, slow pages.

2. Write a hypothesis

Not "let's try a green button". Write: "Visitors do not understand what we do above the fold, so a more specific headline will increase demo requests." A hypothesis tells you what to change and what result would prove you wrong.

3. Change one thing at a time

If you change the headline, the layout and the form together, you will not know which one worked. Test one change per experiment. It is slower, but you learn something every time.

4. Respect sample size and significance

A test needs enough visitors and enough time before you call a winner. Most testing tools show a statistical confidence figure, and a common convention is to wait for 95%. Do not stop a test the moment one variant pulls ahead, and run it across full weeks so weekday and weekend behaviour both count. Low-traffic B2B sites need patience, or bigger changes per test.

5. Ship the winner, then test again

A winner becomes the new baseline. The next hypothesis builds on it. This is what "iterative" means: a chain of small, measured improvements rather than one big redesign and a prayer.

Tools that work with Webflow

Webflow now has its own testing product. According to Webflow's announcement, Webflow Optimize covers A/B testing (for example headlines, images, CTAs and content formats) and no-code personalisation for audience segments. Check the current plan requirements on Webflow's site before you commit.

Other options are third-party:

• Optibase is a Webflow app built for A/B testing, described in its own guide. It is a vendor source, so read it as such.
• PostHog has a tutorial for running A/B tests in Webflow using feature flags and analytics.
• VWO, AB Tasty and Optimizely are the tools Google points to after it shut down Google Optimize. Google's help page says Optimize was sunset on 30 September 2023 and that Google works with these three on Google Analytics integrations.

My rule: pick the tool that matches your traffic, budget and team. The method matters more than the logo. A well-formed hypothesis in a simple tool beats a sloppy test in an expensive one.

What typically moves demo conversion on B2B SaaS sites

These are patterns I look for first. They are hypotheses to test on your site, not guarantees.

• Clear CTAs. One primary action per page, worded as the outcome ("Book a demo"), visible without scrolling and repeated where the reader is convinced.
• Targeted content. Copy that speaks to the buyer's real problem and role, not a generic feature list. For a fraud-prevention product, that means the fraud problem first and the product second.
• Better UX. Fewer steps, a shorter form, navigation that leads to the demo page rather than away from it.
• Faster performance. Heavy pages lose visitors before they read anything. Optimised images, lean interactions and clean structure help.
• Proof near the decision. Customer logos, quotes and results placed next to the CTA, not buried on a separate page.

On Oscilar, the outcome was credited to exactly this mix: clear CTAs, better UX, targeted content and faster performance.

Where I would test first

If traffic is limited, I start at the top of the funnel: the homepage headline and the main CTA. Those two elements touch every visitor. After that comes the demo page itself, then the form. Pricing and product pages follow once the main path works.

I also look at the mobile experience separately. A layout that converts on desktop can lose people on a phone, and a Webflow build makes it easy to check every breakpoint before a variant goes live.

Results: 1.2% to 3.7% in four months

The demo request rate roughly tripled. The engagement numbers matter too: longer sessions and fewer bounces suggest visitors found the content relevant and kept exploring, rather than being nudged into a form they did not want.

One caution: these numbers come from a redesign plus testing together. I cannot split how much came from the new design and how much from individual experiments, and I would not trust anyone who claims to.

For an agency or a retainer client, the lesson is about the time frame. Four months is long enough to run a chain of tests and short enough to keep momentum. A result like this is rarely one lucky experiment. It is the compound effect of several decisions, each one small.

Lessons and a checklist you can copy

1. Pick one primary metric tied to revenue (demo requests, not page views).
2. Record your baseline before changing anything.
3. Diagnose first: find where visitors leave or hesitate.
4. Write each hypothesis down, with the change and the expected effect.
5. Test one change at a time.
6. Decide sample size and duration up front, and run full weeks.
7. Do not stop early because a variant looks good on day three.
8. Check supporting metrics (bounce, session duration) to understand why.
9. Ship the winner, log the result, then write the next hypothesis.
10. Keep pages fast. A test result on a slow page is a result about a slow page.

If you run a retainer for clients, this checklist is also a reporting format: hypothesis, result, next step. Clients understand it, and it makes the retainer easy to justify.

My take

The Oscilar result is not magic. The jump from 1.2% to 3.7% came from treating the website as something you measure and improve, not something you launch and forget.

I build on Webflow because it lets me change a page and ship a variant quickly, without a developer queue. That speed is what makes iteration affordable. A test that takes three weeks to build rarely gets run twice.

My advice: do not start with the tool. Start with the one number you want to move, find the biggest obstacle, and test your best idea against it. If you want to talk about your own site, you can get in touch.

FAQ

Written byPeter CekanakDesigner & Webflow developer · white-label partner for agencies

I design and build Webflow sites for agencies and startups since 2018 — Client-First, GSAP, CMS and AI automations. Sites I built helped a client to a $10M exit and tripled demo requests for a SaaS.

Webflow Certified ExpertRelume ExpertClient-First