Build your source of truth

Supported Knowledge sources#

The customer portal provides three source types: Website crawl, Business facts and Answering guidance. Crawls collect usable page text from a connected website. Business facts and answering guidance are manual entries you write in the portal.

There is no file-upload control for PDFs, Word documents, spreadsheets or other attachments. Linked PDF and media files are not parsed by the website crawler. If an important policy is available only in a document, put its verified customer-facing text in a manual entry or publish an accessible HTML policy page, then review what was collected.

Website-specific and shared Knowledge#

A website-specific source applies to that website. A Shared workspace Knowledge entry applies to every website in the selected workspace. The website Knowledge view includes both its own sources and shared sources.

Share only facts that really apply everywhere, such as a common company contact policy. Keep different returns rules, service areas or price lists scoped to their own websites. Shared sources do not cross into other workspaces, even if the same account can manage both.

Facts and guidance serve different purposes#

Business facts state what is true: delivery regions, fees, product details and published policies. Answering guidance explains how to handle those facts: when to ask a follow-up, when an exception needs review, and which verified contact path to use.

Guidance is prioritised for answers, but it does not grant access to a system or create an Action. A sentence saying “book the appointment” cannot make a calendar connection exist. Nor is guidance a safe place for passwords or customer-specific records: retrieved text can influence customer-facing responses.

Review before trusting the result#

Open Knowledge, filter by website if needed, and select a source to read its active documents. Compare important facts with the original website and check for missing, outdated or contradictory information.

A Ready source means usable information has been prepared. It is not a certificate that every statement is accurate. Reesponder uses the information you publish and provide, so review prices, exclusions, business contacts and requirements before launch.

Separate Knowledge from live data#

A crawl captures information at the time it runs. It does not continuously monitor inventory, fetch a logged-in visitor's order or reserve availability. Use a suitable connected Action when the answer depends on a current system result.

Test both known and unknown questions. If a required fact is absent, add or correct the source and test again. Updating Knowledge affects subsequent answers; it does not rewrite previous transcripts. Treat the assistant's fluent wording as a response to verify, not evidence of an undocumented business promise.

Worked example: turn a document policy into maintained facts#

A service business keeps its customer preparation policy only in a PDF. The portal has no attachment importer, so uploading or linking that file is not a supported way to make its content available. The policy owner identifies the customer-facing information and creates focused manual facts or publishes accessible HTML text that can be reviewed after collection.

They separate preparation requirements from contact details when different people maintain those subjects. Each entry includes the actual conditions and approved next step, with website scope where services differ. They then test a normal preparation question and a customer who cannot meet a requirement. This makes the source useful without publishing internal notes or pretending the PDF itself was parsed.

Leave the next maintainer a clear source decision#

For each topic in the inventory below, state whether its owner updates the public page, edits a manual fact or maintains guidance. Identify which websites should use it and which review event makes it stale. A source title alone does not tell a colleague whether it was intentionally shared.

When a fact is uncertain, ask the business owner to resolve it before publishing a new answer source. Do not choose an arbitrary value just to finish setup. The follow-up can remain a truthful contact route while the rule is approved. Keep the test expectation tied to that approved decision so later review can detect a real change rather than merely prefer a different phrasing.

Turn customer questions into a source inventory#

Start with five or ten important customer tasks and identify where each answer belongs. A question about delivery destinations belongs to approved delivery information. A compatibility question needs relevant product details and perhaps guidance to ask which model the customer owns. A request for a current individual order needs a live authorized connection, not a static Knowledge entry. This task-to-source map prevents the library from becoming unrelated text that nobody can maintain.

For each topic, record its public source or manual entry, applicable website, factual owner and next review event. Review events can be concrete: a policy revision, seasonal opening-hours change, product launch or new service area. There is no customer-configurable automatic crawl schedule to substitute for that responsibility. A useful source title names the topic and scope so a colleague can find it with title search without knowing a sentence hidden deep in its contents.

Prioritize gaps that change a customer's decision. A missing returns exception can be more consequential than an omitted marketing adjective. Check currencies, timeframes, eligibility, required conditions and the next step. If the business cannot establish a fact, give the customer an honest route to obtain help rather than inventing a confident policy to make the library appear complete.

Example: two stores with different returns rules#

Suppose a workspace contains two brands. One accepts eligible returns under one policy while the other has a different product exclusion. A shared entry saying all products can be returned contradicts at least one store. The correction is not to add both policies without labels and hope the assistant chooses correctly. Identify which sites each statement applies to and scope the sources accordingly.

Review existing crawl and manual entries before introducing another source. If the public page is wrong, correct it and refresh its snapshot. If a manual fact is wrong, edit or pause that entry. If a shared statement is valid for only one site, create the appropriate site-specific source and stop using the obsolete shared entry. Scope is chosen when a source is created; the existing editor does not offer a scope-change control.

Test a usual and excluded case from each store afterward. The expected result should use the correct policy and useful next step, not combine the most generous sentence from each brand. Record the approved decision and source owner. More sources are not automatically better: duplicated inconsistent text increases maintenance and leaves the underlying business disagreement unresolved.

Tie review to actual business changes#

A new delivery fee, holiday closure or service restriction should trigger a source update before customers ask. Decide whether the change belongs on the public website, in Business facts or in Answering guidance. Update that authoritative location, then use the relevant refresh and verification flow. The library refresh button only reloads visible state; it does not change the public content or run a new crawl.

Keep a small regression set containing an important fact, an exception and an unsupported request for each major topic. Repeat the affected cases after a change. Include the exact public page when page context matters. A private preview efficiently checks facts and wording, but it cannot establish installed page behaviour or private workflow execution. Write the expected outcome from the approved policy before reading the answer; do not revise expectations merely to make a test pass.

Treat recurring-topic suggestions as leads for review, not approved facts. A frequent question may reveal a missing policy, but the business supplies the correct policy. Helpful feedback suggests an answer worth inspecting, rather than certifying accuracy. Record the source and observed corrected answer. Earlier transcripts remain evidence of what the customer originally saw, which lets your team understand the effect of subsequent source improvements.