Add and maintain business facts

Choose one useful subject#

Before writing an entry, identify the customer question and verify the answer with the business owner or an authoritative policy. Good entries cover a coherent subject such as delivery, returns, a service area or a product range.

Include conditions and exceptions, not just a promising headline. A rule like “Returns are accepted” is incomplete without the period, eligible items, required condition and customer next step. Avoid customer-specific records and secrets: this is information intended to support customer-facing answers.

Create a Business facts entry#

1. Open Knowledge and select Add Knowledge, or open a website's Knowledge tab and select Add entry.
2. Write a descriptive Title.
3. Choose Scope: the website, or Shared workspace Knowledge.
4. Choose Business facts under Type.
5. Write the verified text in Content and select Save Knowledge.

The saved source is ready for new answers without waiting for a website crawl. Shared entries apply to every website in the workspace, so verify that the selected scope matches the policy.

Write the fact with its boundaries#

Title: Standard delivery in the United Kingdom
We deliver standard orders within the United Kingdom.
Standard delivery costs £4.95 and is free on orders over £75.
Delivery normally takes 3–5 working days after dispatch.
Made-to-order items have their own lead time on the product page.
Customers with a delivery issue should use the contact form at
https://example.com/contact/ and provide their order reference.

This is an example structure, not a Reesponder delivery policy. Replace every amount, timeframe, condition and URL with verified information from your own business. Do not invent a service guarantee to make the entry sound complete.

Keep entries focused and within limits#

A title can contain up to 200 characters. The content field permits up to 100,000 characters, but the portal also checks the UTF-8 size of the combined title and body before sending. Keep each entry comfortably below 60 KB and split large material into useful subjects if the size check rejects it.

Non-English characters, pasted formatting and escaped characters can increase byte size. Shorter, coherent entries are easier to review than a single pasted document containing unrelated policies.

Edit, pause and resolve conflicts#

Open the entry, update its Title or Content, and select Save Knowledge. The editor does not offer a scope or type change for an existing entry. To stop using it, clear Use this entry in answers and save; the library shows the paused state.

If another person changed the entry after you opened it, Reesponder refuses to overwrite their revision. Copy your draft if needed, close and reopen the entry, then reconcile the changes. A failed save keeps the draft in the editor. Corrections affect new answers, while earlier transcripts stay unchanged.

Worked example: opening hours with an exception#

For an opening-hours entry, record the location, ordinary days and hours, the relevant time zone and any approved holiday exception. If the business closes on certain holidays, state that condition and the route for checking a specific date. Do not invent holiday hours from the ordinary weekday schedule.

If two stores have different hours, use their own website scope or clearly approved applicability instead of one shared sentence saying that every branch closes at the same time. A reviewer can test an ordinary opening question, a holiday question and a question about the other branch. This tests the conditions in the fact rather than simply checking whether the source contains the word “hours”. These are content examples, not Reesponder's own operating hours.

Retire an obsolete fact deliberately#

When replacing a manual policy, inspect whether the previous statement remains active in another entry or crawl. Correct or pause obsolete manual content through Use this entry in answers, then save. If the original public page is also wrong, assign that correction and refresh separately rather than leaving an active contradiction behind.

Keep the approved rule and its owner in the maintenance note, without private customer examples. The editor's original scope and type are not editable, so a shared policy that now belongs to one site needs a deliberate new scoped entry and retirement of the obsolete shared version. The conflict and review sections below cover preserving other people's edits and testing the result.

Write a rule that survives a specific question#

A useful policy entry contains scope, the approved rule, conditions, exceptions and a next step. Take the vague sentence free delivery is available. A customer can ask where, for what order value, for which items and from which date. Obtain the details from the business before writing. If a condition is genuinely undecided, do not fill it with an invented number merely to make the prose look complete.

For a hypothetical shop, distinguish standard items from made-to-order products, state the market where the policy applies and refer to the current product page for special lead times. Your actual entry must use approved business values. Avoid unsupported universal words such as always or guaranteed when the policy has conditions. Explain working days if they affect the customer outcome, and distinguish dispatch time from delivery time.

Keep related rules together, but use different sources for unrelated subjects. A delivery-policy owner may differ from the person maintaining opening hours. Separate entries make those responsibilities visible and reduce accidental changes to unrelated information. Give each a specific searchable title. Include the real approved policy or contact link when it supplies a practical next step, and recheck the link after a website release.

Example: reconcile simultaneous edits safely#

Two colleagues open a returns entry. One updates its contact URL while the other updates an approved product exclusion. If the first saves before the second, the second's older revision must not silently replace the new URL. The editor reports the concurrent change. Copy the unsaved draft to a safe working location, close and reopen the entry, and compare the latest source with your proposed edit.

Merge the business changes deliberately. Retain the newly approved URL and verified exclusion if both are intended. If they conflict, ask the policy owner instead of choosing whichever sentence is longer. Save the merged version and test both the contact question and exception. Refreshing the library is not an automatic content merge; it updates the visible list. The underlying source needs the deliberate edit.

Do not paste the old draft over the entire latest entry without reading it. That recreates the lost-update problem the revision check prevented. Record the approved changes and resulting checks. For larger material, split independently maintained subjects so fewer people need to edit one oversized source. This is an editorial organization decision, not a way to change an existing source's immutable scope or evade the supported size limits.

Test the actual conditions in the new fact#

After saving, inspect title, scope and enabled state. A shared entry must genuinely apply to every website that uses it. For a single-site policy, check it on that website and consider whether an old shared source still contradicts it. A correct new entry does not automatically neutralize an incorrect old one. Pause or correct obsolete text through the supported flow.

Prepare two or three questions from the conditions you wrote. The normal case should receive the approved rule. An excluded case should explain the boundary. An unknown case should avoid inventing missing facts. Use Private test for factual wording and the installed widget when current-page context affects which product or policy the customer means. Write expectations from the approved policy before reading the answer.

If the editor rejects the text as too large, preserve the draft and split independent topics. Character limits and serialized UTF-8 size measure different things; escaped pasted text or multilingual characters may reach the byte check earlier. Smaller coherent entries also improve review. Do not fix a size error by deleting critical exceptions while keeping only the headline promise. Keep each business rule complete and distribute independently maintained subjects into appropriately scoped sources.