Our pricing page was killing conversions. We had 11 days to fix it and not enough traffic to run a proper A/B test. Here’s how we got unstuc

I’m a PMM at a B2B SaaS company. We make workforce scheduling software — shift planning, availability tracking, compliance alerts — mostly sold to retail and hospitality businesses with hourly workforces. Mid-market, mostly US and Canada, customers typically have 3 to 12 locations.

Last quarter we were gearing up for our biggest push of the year: a coordinated PH launch tied to a new pricing restructure. We’d moved from a per-seat model to a per-location model. Per-location pricing is pretty standard in workforce scheduling — tools like 7shifts, Deputy, and Homebase all structure it that way, because for a business running three restaurants or eight retail stores, paying per employee gets complicated fast. We’d been on per-seat since our early days and it had become a friction point with exactly the customers we were trying to win. The switch made sense. It also meant rebuilding the pricing page from scratch. New tiers, new positioning, new everything.

We had two page variants designed and ready. We’d been arguing about them for two weeks. And we had 11 days until launch.

I wanted to run a proper A/B test. Our CRO consultant had a different opinion about that.

Why a live A/B test wasn’t going to work

Our pricing page gets roughly 1,300 unique visitors a month. That sounds decent until you run it through a sample size calculator. With our baseline conversion rate of about 4.2%, we’d need somewhere between 2,800 and 3,500 visitors per variant to reach 80% statistical power on even a meaningful effect size. At our traffic levels, that’s a two-month test minimum.

Our CRO consultant was pretty blunt: “You can run the test if you want, but you won’t be able to read it. You’ll just be adding noise.”

So we had two options. Ship one of the variants based on gut feel and internal debate. Or find a faster way to get some signal before launch.

A colleague on the growth side had used Articos for messaging research a month earlier and suggested we try it. Her exact words were: “It’s not a replacement for real traffic data, but it’s better than the four of us staring at Figma files and arguing.”

That was a low bar, honestly, but it was accurate. So I set it up.

The two variants and why we couldn’t agree

Variant A led with the free trial. Big headline: “Try it free for 14 days, no lock-in.” The tier structure was below the fold. The CTA was low-commitment. The idea was to reduce friction at the top of the funnel, get people in, and let the product sell itself during the trial.

Variant B led with annual pricing anchored against our main competitor. The headline was something like “Stop overpaying for scheduling software.” We showed our Pro tier with monthly price/per location next to a greyed-out competitor logo. The CTA was harder: “Start saving today.” The trial was there, but it was secondary.

Our sales team loved Variant B. He said our best customers were churning from a competitor and the price contrast would land immediately. Our designer thought it looked aggressive and would put off buyers who weren’t already in evaluation mode. Our CEO was 60/40 on Variant A but admitted he was probably wrong.

We’d been going in circles. The core disagreement was really about who was landing on that page: warm prospects already comparing vendors, or top-of-funnel visitors who hadn’t committed to buying anything yet.

What I set up and what I was skeptical about

I want to be honest about my skepticism going in. I’ve been doing growth work for seven years. A/B testing, to me, means conversion data from real sessions. Click rates, scroll depth, form fills, time on page. It doesn’t mean asking AI personas what they think of a design. Those are completely different types of signal.

What I actually told Articos was that we had two message variants, along with a plain English description of what I was trying to figure out:

“We want to understand which message variant works better to convert a visitor who is actively evaluating scheduling software for a multi-location retail business.”

It asked a follow-up question for clarity. Then a few more — just enough to get a clearer picture of who we were and who we were trying to reach. It felt less like filling in a form and more like being interviewed about the brief. I didn’t expect that.

Then I gave it my test goals. I picked the ones that mapped directly to our internal disagreement: Value Proposition, CTA Effectiveness, Trust and Credibility, and Message Resonance. The final research goal was framed back to me before I confirmed it, which was a useful forcing function — it made me realise I’d been slightly vague about whether I was testing the message or the conversion mechanics, and I tightened the framing before moving on.

After that, I had to wait while it generated the target personas from synthetic data. Persona setup from my side took about ten minutes — less than I’d expected, though there was still some second-guessing about how specific to go. I hit “Generate Personas” and waited while it researched and built the profiles it would use for the interviews.

What I appreciated, once I understood the architecture, was that each persona was run through an independent AI-moderated interview session scored against the goals I’d set — rather than just asking an LLM to freeform-react to my queries. The synthesis in the report mapped findings back to each goal specifically. That structure is what made the output feel like something I could act on rather than just vibes from a chatbot.

The full report landed in just under an hour.

The results, which were more complicated than I wanted

The report came back with findings from two personas: Monique Chen, an operations leader overseeing a seven-location hospitality group in Toronto, and Daniel Cho, an HR leader at the same type of operation. The platform had run parallel interview sessions with both and synthesized across all four of my test goals.

The summary didn’t tell me Variant B won. It told me the stronger landing page was whichever one made visitors feel like they were already in the right place before they read a single claim. The report’s framing was: “The winning message is not the most ambitious or polished. It is the one that helps buyers quickly recognize ‘this is for a business like mine.’” Neither of our variants was doing that well. Variant B was leading with price comparison. Variant A was leading with low commitment. Neither was leading with audience fit.

On the specific goals I’d chosen: Variant B scored better on Value Proposition and Overall Resonance, but only once visitors had already decided they were in evaluation mode. Monique’s responses reflected exactly what our Head of Sales had predicted — she responded to specificity and operational proof. What she didn’t respond to was the competitor anchor itself. The report noted she lost interest fast when copy felt like “marketing for software” rather than naming real scheduling workflows: manager time, callouts, shift changes, approvals. The price comparison read as the former.

Variant A scored better on CTA Effectiveness. Daniel’s responses were consistent with what our designer had argued: the hard push in Variant B felt premature. His exact framing in the report was that a demo request reads as a commitment signal — time with sales, internal follow-up, potential implementation exposure — and neither variant had done enough to de-risk that step before asking for it. The low-commitment trial CTA reduced friction, but only because the alternative was worse, not because Variant A had earned it.

So the internal debate we’d been having — price anchor versus free trial — turned out to be the wrong argument. Both options were skipping a step.

The finding I hadn’t anticipated at all came from a pattern that ran across both personas. The report flagged that our page needed to speak to multiple internal stakeholders simultaneously, not just the person clicking around. Monique described pulling in HR, finance, and location managers during any real evaluation. Daniel said he brings “payroll and at least one operator in fairly early because something can look clean in HR and then create extra work for them.” The implication for the page was pointed: a pricing page that only speaks to the economic buyer — which both our variants essentially did — was going to feel incomplete to anyone doing a real evaluation. The managers who’d actually use the product needed to see themselves in it too.

We hadn’t been thinking about the pricing page as a document that needed to work for five different people at once. We’d been thinking about it as a conversion surface for one.

What we shipped and what happened

We made a call. We took the structure of Variant B but rewrote the headline to lead with audience fit instead of price comparison: something that named multi-location retail teams specifically before getting into any cost claims. We softened the primary CTA from “Start saving today” to “See how it works” — lower pressure, educational framing. We also added a short section below the pricing tiers with three operational callouts: scheduling, callout coverage, and manager approvals. Not feature bullets — brief descriptions of actual workflow moments. That was the multi-stakeholder finding made concrete.

Six weeks after launch, we had enough data to do a rough retrospective. I went back through the Articos report and compared its findings against what the actual session data showed.

The audience-fit finding held up cleanly. Visitors who engaged with the operational callout section had a noticeably higher demo request rate than those who didn’t scroll past the pricing tiers. The multi-stakeholder framing held up too: the most common comment in demo calls for the first month was some version of “this is the first scheduling tool we’ve seen that mentioned approvals on the pricing page,” which is a weird thing to hear but also exactly what the research had predicted would matter.

Where the synthetic research was off: it overestimated how much the competitor price anchor would land with visitors who weren’t already familiar with that specific brand. In session recordings, a meaningful chunk of visitors clearly didn’t recognise who we were anchoring against and scrolled straight past it. The report assumed the anchor would be legible to anyone evaluating scheduling software. It wasn’t. That was a gap in how I’d set up the persona context — I hadn’t specified that our competitors were well-known to our target buyer, so the personas couldn’t surface that friction.

Overall I’d put the directional accuracy somewhere in the 75 to 79% range. Enough to make a confident call, not enough to replace the actual data once we had it.

What this changed about how I think about testing

I’m not going to pretend I’ve changed my fundamental view on A/B testing. Real traffic data is real traffic data. If you have the volume, run the test. The synthetic research didn’t replace that and I wouldn’t use it that way.

What it changed is how I think about the gap between “we have a decision to make” and “we have enough data to make it.” That gap used to just mean more Slack threads and more opinions. Now there’s something I can do with it.

The thing is, when you’re in that gap, you don’t actually have many good options. You can’t run a live A/B test without the traffic. You can’t wait six weeks for traditional research when the launch is in eleven days. And prompting an LLM to “pretend to be a buyer” doesn’t give you anything defensible — no structured goals, no defined personas, no synthesis you could take to a stakeholder. Articos sat in a different place from all three of those, which is mostly why it was useful for getting insights on A/B testing.

The other thing it gave us — and this one surprised me — was the multi-stakeholder finding. That came out of a method I set up to compare two page variants, not to audit who the page needed to speak to. But because the personas were reacting to the full page experience, they picked up on something our internal debate had missed entirely.

That’s probably the more honest case for this kind of research: not “it tells you what will convert,” but “it tells you what questions visitors are walking in with that you haven’t answered yet.”

We still ran a live A/B test after launch, once we had traffic. By that point we already knew what we were looking for.

Has anyone else hit the low-traffic wall on A/B testing and found a different way around it? Would genuinely like to know what’s worked.