A B2B user story is only as good as the behavior it's built on. Most of the ones I see are built on a guess: someone on the marketing team imagines what a buyer wants, writes it up in the standard format, and ships it as research. It reads fine, and it's still fiction wearing a template.
The fix is to check whether the behavior in the story actually happened, the way you'd check any other claim before you publish it. No template does that work for you.
I write user stories for my own business and for clients, and the pattern that separates the useful ones from the decorative ones is always the same: did anyone verify this, or did we just write down what sounded plausible?
What a user story actually is
The format comes from agile software development. Mountain Goat Software, run by Mike Cohn, one of the people who popularized the practice, describes stories written from the perspective of a user or customer, and gives the common template verbatim: "As a \[type of user\], I \[need/want/am required\] to \[do something\], so that \[reason or benefit\]."
Cohn's own framing matters here: a user story is a placeholder for a conversation you still have to go and have. The card is a reminder to go verify something with a real person. That's the part B2B teams skip. They write the card and stop.
For a B2B site, that looks like: "As an operations manager evaluating vendors, I want to see pricing before I book a call, so that I don't waste an hour on someone outside my budget." That's a reasonable guess, and it stays a guess until somebody confirms that operations managers actually bounce over hidden pricing on your site specifically.
Where the assumption becomes a liability
This gets expensive when the story sits downstream of a number that was never checked, and the number is wrong.
Marketing platforms report conversions generously by default. A "conversion" in an ad account can mean a form fill, a phone click, a page view, or a click to get driving directions, depending on how the account is configured, and those configurations drift over time without anyone deciding it should happen. If your user story about "why buyers convert" is built on a platform's conversion count, you've inherited whatever that count actually measures, which is often not what you think.
Eric Ries made the general version of this argument back in 2009: a metric earns its place only when it changes what you do next, whatever it happens to do for the look of the dashboard. In his words, vanity metrics "might make you feel good, but they don't offer clear guidance for what to do." He wrote that about startup analytics in 2009, and it applies just as directly to a conversion count in a Google Ads dashboard in 2026.
What verification actually looks like
I ran into an extreme version of this on an urgent care group with several locations. The ad platform was reporting about 4,000 "conversions" a month. When I checked what was actually tagged as a conversion, most of it turned out to be page views and clicks to get driving directions instead of bookings, both of which the account had been counting as if a patient had scheduled a visit.
So I stopped trusting the label and went to find the behavior the label was supposed to represent. I built a new event that only fires on the page a patient actually lands on once a booking is confirmed, then checked what showed up over the next 60 days: 5,505 of those events, 100 percent of them landing on an actual confirmation page, across every one of the group's locations.
That's the difference between a user story you can publish and one you can't. "Patients book appointments online" is a claim either way. One version of it is backed by a platform's default conversion count. The other is backed by an event that only fires when the specific behavior actually happened, checked against every location instead of assumed to be consistent across all of them. Only one of those survives someone asking "how do you know?"
Writing one that survives scrutiny
A B2B user story, or a customer story built the same way, holds up when three things are true:
The number is sourced, not asserted. If you can't say where a figure came from and how it was checked, cut it rather than round it to "approximately." A reader can't verify a claim you can't source either.
The method is disclosed. Say how you checked, not just what you concluded. "I traced the event to the confirmation page" is a method. "Conversions were up" is not.
The limitation is named. A story with no caveats reads like it wasn't checked very hard. Real verification usually turns up something imperfect, and saying so is what makes the rest of the story believable.
None of that makes the writing slower in any meaningful way. It makes the story defensible, which is the entire point of publishing one. If you want a second set of eyes on how your own conversion data holds up before you build a story around it, that's a conversation worth having; see how we work or get in touch.
A user story that starts with "as a buyer, I want" and ends without anyone checking whether a buyer actually did that is a guess wearing a format. Write the guess if you need to start somewhere. Just don't publish it as research until you've gone and checked. You can see how that verification shows up across real engagements on the results page.
