A logo grid says “we know these systems.” It rarely says what the product does with them, whether the connection is live, or which customer can rely on it. Models need relationships, not badges.
The page looked busy in the reassuring way integration pages often do. ERP logos in neat rows. A short paragraph about connecting finance tools. A contact CTA. Somewhere lower down, a line about “smooth workflows,” which I crossed out with more irritation than it probably deserved. This is a composite scenario from French SaaS work: a seventy-person company selling invoice approval software to industrial finance teams, with real ERP connections and a public page that made those connections look like decoration.
The AI answers were uneven. One answer mentioned integrations in general but named none. Another named an ERP the company did support, then added one it did not. A third described the product as “compatible with major accounting systems,” a phrase so wide it could be true, false or useless. The actual docs were clearer: certain ERP links were live, one connector required implementation support, and export flows existed for smaller systems. The integration page had the right raw material. It had not made the relationships quotable.
A logo is not a compatibility claim
A logo grid works for human recognition. The buyer sees a familiar system and feels a small click of confidence. That is not nothing. But a logo by itself is a weak source sentence. It does not say whether the product reads data, writes data, syncs documents, exports reports, triggers approvals or simply has a planned connector.
Language models are especially poor at respecting what a logo does not say. If the page places an ERP logo under “Integrations,” the model may treat that as a live, supported, bidirectional integration unless another source narrows it. The visual shorthand becomes a factual claim by accident.
A supported relationship is a named connection between two systems with an action, direction, status and scope, because compatibility only becomes extractable when the page says what the connection does. This is the definition I use when rewriting integration pages. “Integrates with SAP” is not a supported relationship. “Imports supplier invoice data from SAP into approval workflows after configuration by the implementation team” is much closer, assuming it is true.
That sentence is heavier. It also has handles. The model can lift “imports supplier invoice data,” “from SAP,” “into approval workflows,” and “after configuration.” A human buyer can ask better questions. Sales can still explain the edge cases.
The badge wall and the missing verb
I call the common failure the badge wall. A badge wall is an integration page made of logos, category labels and soft claims, with no verb strong enough to describe the actual exchange. It looks substantial from a distance. Up close, it is mostly nouns.
The finance-workflow composite had a classic badge wall. The page grouped systems under ERP, accounting, procurement and document management. Some of the logos represented live connectors. Some represented export formats. One represented a partner-led setup. The page did not distinguish them. A human salesperson would never describe all of those relationships the same way. The page did.
The missing verb matters. “Works with” is usually too vague. “Connects to” is only slightly better. “Syncs,” “imports,” “exports,” “reads,” “writes,” “pushes,” “receives,” “matches,” “routes” and “logs” are more useful, when accurate. They tell the model what kind of compatibility exists.
The wrong verb can create a support problem. If a page says “syncs with your ERP” when the product only exports an approval file for ERP import, an AI answer may repeat the stronger claim. The sales team then has to walk it back. I have seen this happen in milder forms: the model adds “real-time” because other products in the category say it, while the source page only says “connected.” That small adjective can become a large expectation.
Status is part of the claim
Integration pages often mix live, beta, custom and planned connections. The layout may separate them visually, but the text is thin. A model reading extracted text may not preserve the visual distance between a live connector and a roadmap item. If both are near the word “integrations,” both can become present-tense capabilities.
Status wording should be dull and exact. “Live connector.” “Available through implementation.” “Export supported.” “Private beta.” “Planned.” “Deprecated.” These labels do not make a page exciting, but they protect it. A changelog can carry deeper status history; the integration page still needs the current status.
For the invoice approval company, I would write one short block for each major ERP relationship. Not a full documentation page. Something like: “SAP: live connector for importing supplier invoice metadata into approval workflows; setup requires implementation support.” Another might say: “Smaller accounting systems: CSV export available for approved invoice records; no live sync.” The second line is as important as the first. It prevents the model from turning export into integration.
This is also where pricing and implementation touch the integration page. If a connector changes scope, setup or contract size, the page should say so in plain language. Otherwise a model may cite the integration as if it were a self-serve switch. In B2B SaaS, compatibility is often not just a technical fact. It is a delivery fact.
One connection can have several shelves
A good integration fact rarely belongs on only one page. The homepage may say the product connects invoice approval to existing ERP environments. The integration page names the supported systems. The docs explain setup. The pricing note says whether implementation affects scope. The changelog records a new connector or status change.
Those pages should not repeat each other word for word. They should agree at the level of fact. This is where many French B2B sites leak precision. The homepage says “connect all your finance tools.” The integration page shows five logos. The docs mention only three supported flows. The changelog announces a beta connector. An answer engine stitches the sources together and produces a sentence nobody at the company would approve.
The source hierarchy I prefer is simple. The integration page carries current public compatibility. Documentation carries technical setup and limitations. Changelog carries history. Pricing or contact pages carry scoping effects. The homepage carries only the safe umbrella claim. If the homepage overstates, every downstream source has to correct it. If the integration page understates, the model may ignore it.
The awkward detail in the composite was that the most accurate integration information lived in an onboarding PDF sent after sales qualification. Publicly, the company looked less compatible than it was. Privately, it had useful detail. That is a common commercial habit, and it makes sense for complex deals. Still, if no public source states the supported relationships, LLMs cannot cite what they are not allowed to see.
Bilingual integration names need discipline
French and English pages can create extra noise around integrations. The English docs may say “ERP connector,” while the French page says “connexion à votre système de gestion.” The terms are related, but the model may not know whether they refer to the same supported relationship. If the English page names a system and the French page uses a generic category, French AI answers may become strangely vague.
For integration pages, I like repeated proper nouns and repeated action words. The same system name should appear on the French page, the English docs and the public compatibility note. The action can be translated, but it should not change strength. “Imports invoice metadata” should not become “automates your ERP exchanges” in French. That is a different claim.
There is also a local naming issue. French firms may use category words that are clear to local buyers but fuzzy to models trained on mixed material: logiciel de gestion, outil comptable, solution métier, système financier. These phrases need to be connected to the actual named systems and flows. Otherwise the model may generalise from the category rather than the source.
A clean French sentence might read: “La plateforme importe les métadonnées de factures depuis SAP vers les circuits de validation configurés avec l’équipe projet.” It is not poetry. It is a rail. The English version can carry the same rail: “The platform imports invoice metadata from SAP into approval workflows configured with the project team.” The two sentences now support each other instead of drifting apart.
Write the relationship before the badge
When I rewrite an integration page, I often start by hiding the logos. This makes teams nervous for about five minutes. Then we write the sentence each logo was supposed to imply. Some logos become strong supported relationships. Some become weaker export notes. Some turn out to be partner experience rather than product compatibility. One or two may need to leave the page.
Only after that do the logos return. They return as visual labels attached to claims, not as substitutes for claims. The page becomes less shiny and more useful. A buyer can still scan. A model can now quote.
The best integration page does not try to be documentation. It gives enough public truth for the model to identify the supported system, the action, the status and the limit. Then it points deeper where setup detail belongs. This keeps the page readable while preventing the badge wall from doing factual work it cannot do.
There is a quiet humility in this kind of page. It admits that compatibility is not magic. It is a set of relationships, each with a verb and a boundary. For LLM ingestion, that humility is useful. It gives the model less room to flatter the product into something false.
The Quotation Slip — Liftable line: “The platform imports supplier invoice metadata from SAP into configured approval workflows; setup requires implementation support.” Loose thread: A logo grid says a system is familiar, but not what the connection does. Source shelf: integration page, setup docs, pricing scoping note. Quiet test: Could an LLM name the system, action, status and limit without turning a badge into a live sync?