How a B2B software company gets recommended by AI assistants

In B2B the questions come from several people with different worries, and being recommended means having a clear answer for each of them: the user's workflow, the buyer's cost case, the technical reviewer's integration question, and the compliance reviewer's data question. Most vendors write for the user only, and lose on the other three.

What buyers of B2B software actually ask an assistant

Four different people ask four different questions, often in the same week, and they are rarely the same person who signs.

The user asks whether it does the job and what it is like day to day. Most existing content addresses this.

The person paying asks what it costs, in total, including implementation, and what happens at renewal. Published pricing and honest total cost of ownership are rare and heavily rewarded.

The technical reviewer asks about integrations, data export, authentication and limits. Public documentation answers these better than any sales page, and it is what gets cited.

The compliance reviewer asks where data is stored, who processes it, which certifications you hold and what your terms actually say. Specific, checkable answers here are worth a great deal, and vague claims are worse than saying nothing.

Write down the five questions each of those four would type into an assistant. That list of twenty is your content plan, and it looks nothing like a feature list.

Which sources the assistants read for this trade

Enterprise and B2B questions pull from a different mix than consumer or small business ones. The following six carry most of it.

• Analyst and research material, which dominates the broadest questions about large programmes and which a mid sized vendor will not displace.
• Established trade publications, which carry the category language and the vendor names.
• Your public documentation, which answers the technical reviewer better than anything else you own and is quoted with more confidence than marketing pages.
• Your trust, security and legal pages, for the compliance questions. These are read, and they are the only place a vague claim is genuinely dangerous.
• Roundups and directories, which supply candidate names for "best platform for" questions.
• Community and practitioner threads, which own the migration and "what went wrong" questions.

Three of those six are pages you own and control, and they are usually the three that get the least attention internally because they are not owned by marketing.

Why the enterprise category is the hardest one

For broad questions about large programmes, assistants prefer sources they can defend: analyst material, established publications and large well documented firms. A mid sized vendor is unlikely to displace them on the broadest question, and chasing it is the least productive work available.

The way through is to narrow. A specific platform, a specific migration, a specific industry, a specific team size. Those questions have fewer defenders, they are what a real buyer asks second, and they are where a well evidenced page genuinely competes.

The three fixes that matter most here

One: publish your documentation openly. The technical reviewer's questions are the easiest to win and the most often lost by accident, because the answers are already written and sitting behind a login. Making them public and indexable is a configuration decision, not a content project.

Two: write the cost page the payer needs. Not a pricing page with a demo button. A page that names the charging model, states a starting point with a date, lists what implementation involves and what it typically costs, and says plainly what happens at renewal. Nobody writes this, and it is the question that decides the deal.

Three: make the compliance answers specific and dated. Where data is stored, who the subprocessors are, which certifications you hold and when they were last audited, and what your terms say about export and deletion. Name them. A vague claim here is worse than no claim, because it is the one area where a reviewer will check.

After those three, narrow your target questions. One page for one migration, one industry, one platform pairing, rather than one page about digital transformation.

A worked example

Take the technical reviewer first, with a reading we actually have. On 17 September 2026, on a question about finding every case filed against a company, Claude ranked two enterprise vendors above clawlaw.in, our sister company, specifically because those two vendors publish explicit court and tribunal coverage lists. It said its ordering reflected price transparency and source authority rather than product quality.

That is the technical reviewer's question in another industry. What do you cover, stated where a reader can check it line by line. The two vendors that came out above had published theirs. The answer itself said the ordering was not about which product was better.

Your version of that list is the integration list, the export formats, the authentication methods, the rate limits and the data retention behaviour. If those are public and readable as text, an assistant asked whether your product can export purchase order data to an accounting system on a schedule has something exact to quote, and your own page gets the credit. If they sit behind a login, one of three things happens instead. The assistant says it cannot confirm, which reads as a no. Or it answers from a third party page that may be out of date. Or it answers from a competitor's comparison table, which will not flatter you.

Now the finance lead. On 6 August 2026 the pricing page for clawlaw.in rendered its prices only after scripts had run, so what a crawler received contained no prices at all, and the prices the assistants quoted had come from an app store listing instead of from the company's own site. A price you do not publish readably is still published, by somebody else, in a version you did not write. That is also what happens to a platform whose only pricing content is a demo form: the number comes from a competitor who published one, and your product is described as one where pricing is not disclosed.

Two questions, two people, two pages, and both pages are things you could publish this month without building anything.

What earns the citation

Numbers that survive checking. An exact and modest figure beats a generous one that fails, because a claim that fails once costs you the rest of the page.

Named enumerations. List the integrations, the regions, the certifications. Never "all major platforms".

Dates on everything perishable. Prices, certifications, coverage. A dated fact is trusted more and ages visibly rather than silently.

Plain statements of what you are not. The fastest route to being described accurately is describing yourself accurately, including the limits.

Sources on any claim about somebody else. A competitor's price with no source and no date is the quickest way to have your entire comparison page discounted.

What this approach cannot do

It cannot win the broadest enterprise questions in a crowded category. Analyst and large publisher sources hold those, and a page of yours will not replace them.

It cannot substitute for the evidence a real enterprise buyer needs. An assistant getting you onto a shortlist is the beginning of a procurement process, not a replacement for one.

It cannot move quickly. Documentation gets crawled, roundups depend on other people, and analyst relationships take years.

And it cannot be guaranteed. No one can promise you a place in an AI answer, and in this category the honest expectation is a better position on narrow questions rather than victory on the headline one.

How to measure it

Build four question sets, one per role, ten questions each, in the words that person would use. Run them monthly on two or three assistants without naming your company, and keep the sets separate. A single blended number hides the thing you most need to know, which is that you are fine with users and invisible to the three people who actually approve the purchase.

Record whether you were named, whether any page of yours was cited, and which pages supplied the answer. When your documentation starts appearing in the technical set, that is the first real sign the approach is working, and it usually shows there before anywhere else.

Common questions

Our documentation is behind a login for good reasons. What can we publish?

Publish the reference material that is not customer specific: the integration list, the authentication methods, the export formats, the rate limits, the data retention behaviour. Keep the customer specific parts private. That split is usually easy and it covers most of what a reviewer asks.

How often should we check our position?

Monthly per role set. In this category movement is slow, so a weekly check mostly produces the same answer and invites false conclusions. Keep every reading and look at the shape over two quarters.

An assistant cited an analyst page that leaves us out. Can we do anything?

Not directly, and you should not spend your quarter trying. Narrow the question instead. On "best platform for a mid sized manufacturer moving off spreadsheets" the analyst page is less relevant, the competition is thinner, and a well evidenced page of yours can genuinely win.

A competitor's comparison page is being cited for a fact about us. What do we do?

Check the fact, ask for a correction in writing if it is wrong, and keep a dated copy of the page. Then fix the reason it happened: publish the fact yourself, in text, on a page a reviewer would land on, with a date. In B2B the missing fact is usually in a slide deck or a security questionnaire rather than on the website.

Is being cited the same as being recommended?

No, and in this category a citation of your documentation is often more valuable than a mention, because it reaches the person who says no. Track both, and track which of the four roles the question came from.

Should we write about our industry or about our product?

About the decisions your buyers are making, which is neither. General industry commentary is not asked about, and product pages answer questions nobody typed. The page that works names a situation, a constraint and a decision, and answers it with facts.

What to do first

Pick the technical reviewer, because it is the cheapest win. Find out whether your integration list, export formats and authentication methods are publicly readable as text. If they are not, that is one configuration change and it makes you answerable on a whole class of questions you are currently losing silently.