Skip to the report

2026 research brief · Evidence, interpretation & measurement

B2B SaaS AI visibility.
What does the answer say?

B2B SaaS AI search visibility: what the research tells us, what the numbers leave out, and how to find out whether buyers are getting an accurate account of your business.

The business question

Would the answer give the right buyer a reason to call?

A software company can appear in an AI answer and still come away badly explained. It can be described accurately and never be recommended. It can receive a citation that sends almost nobody to the website.

Those are different problems. They deserve different measurements and different work.

When I look at AI discovery, I want to know what happens between the buyer’s question and the next decision. Does the system understand the category? Does it recognize the problem the product solves? Does it describe the implementation honestly? Does it send the reader toward useful evidence, or toward a comparison that was already out of date when someone copied it?

This report brings published buyer research together with a practical way to examine those questions. The goal is a clearer business decision: where to improve the explanation, where to repair the evidence, and where a technical obstacle is preventing good material from being found.

Being mentioned is the beginning.
Being understood is the business problem.

Evidence with its limits attached

The number matters. So does the question behind it.

These findings describe different populations, questions and measurement systems. Read each row as its own observation. Averaging them would produce an impressive-looking number with very little meaning.

Selected published findings relevant to B2B software discovery
Finding Source and scope How to use it
51%Reported starting software research with an AI chatbot more often than Google. G2’s 2026 AI Search Insight Report; 1,076 B2B decision-makers surveyed in March 2026. [1] A reason to examine AI discovery alongside conventional search. It does not mean Google has disappeared from the journey.
94%Reported using LLMs during their buying process. 6sense’s 2025 B2B Buyer Experience Report, covering B2B purchasing beyond SaaS alone. [2] Usage during research does not establish that AI introduced the vendor, caused the purchase or replaced contact with sellers.
95%Chose a vendor from the shortlist established on day one. A separate finding in the same 6sense report. [2] Early familiarity deserves attention. This is a shortlist finding, not a measured AI-attribution rate.
89%Of unbranded prompts were fulfilled by third-party sources. Bain’s analysis of proprietary ScrunchAI data spanning about 500 million citations; a broad discovery analysis, not a SaaS-only benchmark. [3] Inspect the independent information describing your category and company. The figure does not make your own documentation expendable.
4.4×Higher visitor value, based on conversion rate. Semrush’s AI-search study compared observed non-Google AI referrals with traditional organic search visits. [4] An observation to investigate in your analytics. It is not a forecast for your conversion rate, revenue or customer lifetime value.

My interpretation

The useful work begins after the statistic.

A board does not need another alarming chart that ends with “publish more content.” It needs to understand which part of discovery is weak, why that matters to the business and what can reasonably be improved.

Category & positioning

Make the product’s place in the decision clear.

Many SaaS companies can describe their features more easily than the situation in which someone should choose them. The homepage offers a broad promise. The sales deck supplies a narrower one. The documentation uses the product team’s vocabulary. A review profile may describe the company it was two years ago.

That is an information problem with a positioning decision inside it. Establish who the product serves, what changes when it is used, where it fits into an existing process and which requirements it does not meet. Useful boundaries help the right buyer recognize a fit.

Owned & independent evidence

The company’s explanation travels through other people.

A product page, a customer review and an implementation discussion have different jobs. Your own site can define current capabilities. An independent account can describe what those capabilities felt like in use. Both become more useful when they are specific enough to examine.

Look for factual discrepancies before pursuing more mentions. An obsolete integration list or a review that confuses two product editions can create a practical sales problem. Correct the record with evidence and respect editorial independence. Manufactured praise adds another claim to maintain.

Intent & answer quality

A confident recommendation can still be a poor match.

“Best software for a growing business” is too broad to explain much. A buyer considering a migration has questions about data, integrations, permissions, training and the work required to switch. An enterprise procurement team has a different decision from a founder buying a first subscription.

Test the questions that belong to the actual sale. If the answer recommends your product for a requirement it cannot satisfy, a rising mention count can conceal a growing expectation problem. Record errors and poor-fit recommendations alongside omissions.

Commercial judgment

Connect the explanation to an observable next step.

Useful outcomes may include a better-informed demo request, a prospect who understands the category or fewer conversations spent correcting the same misconception. Some of that evidence appears in analytics. Some appears in the questions the sales team hears.

Agree on what a qualified inquiry means before evaluating the channel. A trial start, an enterprise discovery meeting and a procurement review should not be counted as equivalent wins. Keep the observed result separate from the explanation you think caused it.

A repeatable measurement protocol

Build a baseline you could explain in a meeting.

A screenshot can start an investigation. A baseline needs a defined question set, recorded conditions and a consistent way to classify answers.

This is a proposed working protocol, not a claim that PaperBoat has already run the observations shown in the calculator.

  1. Define the buying decision.

    Choose a category, buyer role, company size and meaningful constraint. Use sales questions, implementation conversations and customer language to build the prompt set. Keep branded questions separate from unbranded discovery.

    Example: “What should a 200-person professional-services firm compare when choosing project-accounting software that must integrate with its existing finance system?”

    A second prompt might compare named vendors. A third might test an integration or migration concern. Label the purpose of each so a gain in branded recognition does not masquerade as a gain in category discovery.

  2. Record the surface, not just the company name.

    Capture platform, product surface, visible model or mode, date, locale, account conditions and whether web search was used. Distinguish a consumer interface from an API. Record a fresh conversation separately from a continuing thread.

    Use the same protocol for the next measurement window. If the interface or mode changes, document the change before comparing the numbers.

  3. Repeat prompts and retain the responses.

    Run each question more than once across a defined window. Keep the full answer, cited URLs and the time of observation. Record errors and incomplete runs instead of silently deleting them.

    For Google Search, record whether an AI feature appeared. A successful search with no AI Overview is still an observation; it is different from a failed request. Treat sampled outputs as observations under those conditions, not a census of what every buyer sees.

  4. Code several outcomes separately.

    Mark whether the brand was mentioned, recommended, described accurately and linked through an owned-domain citation. Also record competitor appearances, cited third-party pages, material errors and the reason a recommendation was judged relevant.

    Write the rules before scoring. Have a second person review a subset of the answers when judgment is involved. Disagreement can reveal an unclear rule rather than a bad reviewer.

  5. Compare like with like.

    Report results by platform and prompt family before producing an overall summary. Keep the original question set as a stable comparison group, and label newly added questions separately. Show counts with percentages.

    Maintain a change log for website edits, independent coverage and platform changes. A before-and-after difference may be worth investigating without proving that a particular content edit caused it.

A small tool for a better conversation

Calculate the rates.
Keep the denominator visible.

Use one platform, one prompt family and one measurement window at a time. The starting numbers are illustrative. Enter your own reviewed counts to see what each rate actually measures.

The optional calculator requires JavaScript. The definitions and formulas below remain available.

Four measures that answer different questions
Measure Calculation What it tells you
Mention rate Answers mentioning the brand ÷ completed observations How frequently the brand appeared in this sample.
Citation rate Answers citing the owned domain ÷ completed observations How frequently the site was linked as a source.
Accuracy rate Accurate brand mentions ÷ all brand mentions How often the observed brand descriptions passed your review criteria.
Recommendation rate Answers recommending the brand ÷ completed observations How frequently the answer put the brand forward as an option.

Platform-specific observation

One dashboard label can hide several different experiences.

A buyer using a search-enabled conversation, a research mode and an ordinary search-results page is not necessarily seeing the same source set. Test the surfaces that matter to the audience. Avoid turning a platform name into an unsupported theory about how all its answers are produced.

ChatGPT

Record whether search was used and which sources the answer displayed. Distinguish recognition of a brand from a current, linked explanation of its product. An answer without a citation needs its own classification; it is not proof that a particular page was retrieved.

Perplexity

Keep the question, answer and cited URLs together. Review what each citation actually supports. A source attached to a paragraph may support one detail while leaving the rest of the recommendation dependent on interpretation.

Gemini

Identify the app or interface and mode being observed. Keep its results separate from Google Search’s AI features. Shared corporate ownership is not a reason to merge distinct product experiences in a measurement sheet.

Google AI Overviews
& AI Mode

Record the search query, location and observed feature. Google’s documentation says supporting pages must be indexed and eligible for a Search snippet; it also says there is no special schema required for these features. [6]

Technical foundations

Give useful evidence a dependable place to live.

Technical work should resolve a specific obstacle. A fast page with a vague explanation is still a vague explanation. A well-written integration guide behind an unintended access block has a different problem.

Make the essential explanation inspectable.

Put the category, capabilities, limitations, implementation details and current product information into accessible page content. Do not make the only useful explanation a decorative animation, an image of a table or a sequence that requires an account before any public context is available.

Inspect both the delivered HTML and the rendered page. If essential information only arrives through client-side interactions, test whether intended readers and relevant crawlers can actually obtain it. Server rendering or static output can help; neither is a substitute for checking the response.

Separate search access from model-training choices.

OpenAI documents OAI-SearchBot for search and GPTBot for content that may be used in model training. Those controls are separate. [7] Perplexity documents PerplexityBot as a search crawler, with its own published network information. [8]

Review actual access rules and request logs against the purpose you intend to allow. A successful homepage request does not establish that product documentation, comparison pages and technical references are reachable under the same conditions.

Make performance a measured engineering question.

Track response reliability, server latency, page weight and rendering behavior. Investigate timeouts and inconsistent responses. Set performance goals based on the site, user experience and observed failures. This report does not assign a universal citation penalty to a particular millisecond threshold.

Use structured data to describe the visible page.

A product page may describe an actual software application. A research brief should describe its article or report, author, publisher and sources. Adding a software type to an unrelated editorial page would confuse the account of what the page contains.

Keep titles, canonical URLs and entity identities consistent. Remove duplicate or contradictory graphs when a plugin and a custom HTML block describe the same article differently. Structured data should make the existing meaning explicit.

Give each important question a sensible home.

Publish a dedicated page when the buyer has a substantially different task: assessing an integration, understanding migration or evaluating a particular workflow. Strengthen an existing page when the proposed “new topic” is only a synonym for the same question.

Connect those pages with useful internal links. The product overview should lead toward the evidence. A technical article should let the reader return to the product and understand where the detail fits. This is also how you keep an AI-discovery initiative from becoming a collection of competing landing pages.

A practical sequence

Start with the gaps you can name.

The first useful deliverable is usually an explanation of the problem. The following sequence turns that explanation into accountable work without promising that a publishing calendar will produce a particular answer in an external system.

First: establish the record

Find out what buyers could encounter.

Inventory product claims, priority questions, major third-party descriptions and the pages that should support them. Build the initial prompt set. Review technical access and record the current answers.

Deliverable: a baseline with named omissions, errors and sources, plus a prioritized list of questions the website should answer.

Then: improve the explanation

Make the evidence agree.

Resolve category confusion, update material product facts, strengthen the pages that already own the relevant intent and repair specific access problems. Give each change an owner and a review date.

Deliverable: corrected source material, clearer buyer pathways and a change log connecting the work to the original diagnosis.

Next: observe and adjust

Repeat the protocol.

Re-run the stable question set under comparable conditions. Inspect which source pages and claims changed. Review qualified inquiries and sales conversations alongside visibility measures.

Deliverable: a comparison that shows what improved, what remained uncertain and which next action has the strongest evidence behind it.

Measurement after the answer

Revenue deserves a better explanation than “AI traffic went up.”

Keep observable referral traffic separate from inferred influence. A person can read an answer, remember a company and return through another route. Conversely, an AI referral can arrive for a question with no realistic buying intent.

Review landing pages, qualified conversions and downstream opportunity stages. Compare similar audiences and periods, and show the size of the underlying samples. A conversion percentage from a handful of visits can move dramatically after one additional inquiry.

Ask buyers how they found the company, while recognizing the limits of recall. Give the sales team a simple way to record recurring misunderstandings and useful pre-call knowledge. That information can help explain why an answer matters even when there is no clean referral trail.

For a board or investor discussion, I would separate three columns: what we observed, what we think it means and what we will do next. That separation makes the recommendation easier to challenge and the next round of work easier to judge.

Questions worth answering

Before the next dashboard review.

Is this an original PaperBoat benchmark study?

No. It is a sourced research brief with original analysis and a proposed measurement protocol. The numerical findings remain attributed to their publishers. The calculator starts with clearly labeled illustrative counts.

Is there one accepted AI visibility score?

This report does not treat a vendor’s composite score as an industry standard. A score needs a disclosed prompt set, observation method, weighting and denominator before it can support a meaningful comparison. Separate rates are often easier to explain and act on.

Does a citation mean the brand was recommended?

No. A page can be cited for a definition, background fact or comparison without the answer recommending its publisher’s product. Measure the source link and the recommendation separately.

Should we create a page for every prompt?

No. Group prompts by the underlying buyer decision. Build a distinct page when the task and evidence warrant one. Otherwise, improve the page that already owns that subject and link to the details that help the reader.

How often should the baseline be repeated?

Choose a schedule that fits the pace of product, content and platform change. Preserve a stable set for comparison and document major events between runs. More frequent measurement is useful only when the team can interpret and act on it.

Can you help with implementation as well as strategy?

Yes. My work can include positioning, requirements, writing, information architecture, AI processes, team training and coordination with the people responsible for the build. The assignment determines the scope. We begin with what the company needs to change.

Source register & method

Keep the trail back to the evidence.

The research table is a selective synthesis of the primary publications below. It is not a meta-analysis. Studies differ in timing, respondents and definitions; their results have not been pooled or independently reproduced here.

Sources were reviewed on October 1, 2026. Publisher pages and platform documentation can change. Retain the relevant version when using a finding in a board paper, investment document or longitudinal comparison.

G2, 6sense, Semrush and the other organizations retain their own methodologies and commercial perspectives. A citation identifies a source; it does not imply a partnership or endorsement.

  1. G2: The Answer Economy, 2026 AI Search Insight ReportPrimary buyer survey; source for the 51% finding and its March 2026 sample.
  2. 6sense: 2025 B2B Buyer Experience ReportPrimary research on the buying journey; source for LLM usage and day-one shortlist findings.
  3. Bain: Your Next Customer Will Find You Using AI. Now What?Published April 7, 2026; analysis using ScrunchAI citation data.
  4. Semrush: We Studied the Impact of AI Search on SEO TrafficPublisher’s analysis of AI-search traffic and conversion-based visitor value.
  5. G2: 2026 Buyer Behavior ReportA separate report; source for the 38% and 37% shortlist-influence comparison.
  6. Google Search Central: AI Features and Your WebsiteOfficial guidance on eligibility, content and structured data for Google Search AI features.
  7. OpenAI: Overview of OpenAI CrawlersOfficial distinctions among search, training and user-initiated access.
  8. Perplexity: Perplexity CrawlersOfficial crawler purposes and access documentation.

The person behind the analysis

Rob Urban.
PaperBoat Media.

I work with companies and leaders whose expertise is harder to explain than it should be. The assignment may begin with search visibility and lead into positioning, product information, a technical discussion, an AI workflow or the way a team gathers and uses its knowledge.

I perform the PaperBoat contribution personally, working with executives, boards and the specialists responsible for their part of the project. A useful explanation needs someone willing to understand the work behind it.

More about my background · AI search and organic growth consulting

Bring the real question

What does a buyer need to understand before your company belongs on the list?

If the answer is buried across product meetings, old web pages and a sales team’s working knowledge, I can help bring it into a useful public account.

Tell me what you sell, who needs it and where the explanation seems to fall apart. That is enough to start a serious conversation.


Scroll to Top