How to teach AI about your products and services

Keep interventions, hypotheses, assets, observations and decisions in a searchable workspace. Record what is known and what still needs checking.

An AI assistant does not need more promotional copy to understand an offer. It needs structured, current facts: what the product is, who it serves, which problem it addresses, what it can prove, what it requires and where the canonical page lives.

Why a homepage is not enough

A homepage compresses several audiences and offers into one narrative. The AI may infer missing details, confuse a service with a feature or repeat an old commercial promise. A structured record separates the fields that matter and keeps their provenance visible.

What to record for every offer

Field	Useful content
Name and type	Canonical name; product or service
Audience	Specific buyer or user with relevant context
Problem	Situation the offer genuinely addresses
Outcome	Result the customer can reasonably expect
Capabilities	Current functions, without inferred promises
Requirements	Setup, provider, account or eligibility needed
Evidence	Documentation, customer proof or approved source
Limitations	What is not included or guaranteed
Destination URL	Canonical page for the offer
Owner and review date	Person responsible for keeping it current

Write one claim per idea. Keep qualifications with the promise they constrain. “Free” should state whether external provider usage may still cost money.

Products and services are not the same record

A product is usually a repeatable offer with defined functionality. A service often depends on scope, delivery process and human involvement. Mark the type so the AI does not describe consulting as an automated software feature or a software function as bespoke work.

If several plans or variants share a product, define the common entity and attach version-specific conditions. Do not create duplicate records that will drift independently.

Add reliable sources

Prefer current product documentation, approved commercial terms and canonical pages. Store third-party descriptions as external evidence, not as the brand's own fact. Date price, compatibility and policy claims because they change.

When sources conflict, select the authoritative one and archive or label the obsolete record. A source-aware memory is valuable only when contradictions are visible.

Import a catalogue without importing its problems

For many offers, bulk import can save time. Clean the table first: one row per entity, stable identifiers, explicit types, no merged cells, canonical URLs and consistent status values. Map columns before writing and review a small sample after import.

Do not import API keys, private customer details or internal notes that the workflow does not need. Data minimisation remains important even inside an authorised workspace.

Test retrieval with real questions

Ask the system to produce:

• a factual two-sentence description of each offer;
• the correct offer for a defined audience and problem;
• requirements and limitations before benefits;
• related pages already published;
• claims lacking a supporting source.

Inspect which records were used. If the answer is wrong, determine whether the fact is missing, ambiguous, obsolete or poorly retrieved. Fix the source record rather than adding another contradictory prompt.

Use product context in SEO and content

Search volume alone does not make a topic valuable. Connect each editorial opportunity to the offer, audience and stage it supports. This helps reject high-volume topics unrelated to the business and prevents generic pages that never lead to a meaningful next step.

Frequently asked questions

Should I paste all product copy into one knowledge document?

No. Keep structured offer records and attach longer evidence where needed. Retrieval becomes more precise and updates are easier.

Can the AI decide which claims are approved?

No. Approval and source hierarchy belong to the organisation. The AI can flag gaps or contradictions.

How often should records be reviewed?

Review after product, price, integration or policy changes and on a regular owner-defined cadence.

Can one record serve three languages?

The canonical facts can be shared, but names, examples and market language need native localisation. Keep the relationship visible.

Give the AI a governed offer catalogue

Create one source-aware record per product or service, test it with real tasks and update it at the source. The AI can then use commercial context without inventing what the company sells.

What BeKnow keeps

Keep interventions, hypotheses, assets, observations and decisions in a searchable workspace. Record what is known and what still needs checking.

A change in performance after an intervention does not prove that the intervention caused it. Cross-platform attribution and a complete analytics dashboard are not available today.

Project memory and data imports do not require an AI model key. A compatible external AI client may have its own costs. BYOK applies only to available functions that actually call an external provider.

Next step

Start with one project, one documented change and the evidence needed to review it. Source connections.

Record your first intervention. How it works.