Custom knowledge: FAQs, shipping, and policies

Build custom knowledge with FAQs

What custom knowledge FAQs are for

Custom knowledge FAQs let you add concise, maintained answers directly to Fynd. They are useful for information that is important to customers but does not belong in a product feed or cannot reliably be collected from a public page. Examples include shipping cut-off rules, returns instructions, warranty coverage, appointment policies, store collection guidance, payment methods, and service boundaries.

An FAQ is not a substitute for every content source. Product facts that change with your catalogue should usually come from an XML or CSV product feed or from the Catalog API. Public guides and blog content are often better collected with a sitemap crawl, which can recognize BlogPosting and Article JSON-LD and classify those pages as page_type=blog. Use custom FAQs for the short, authoritative explanations you want to state explicitly.

The goal is to help Fynd answer a real customer question clearly and safely. Each entry should contain one question and one self-contained answer. A person reading only that answer should understand what to do, what the limitation is, and where to go next when more detail is needed.

Decide what belongs in an FAQ

Start with questions your support team repeatedly receives, questions that block a purchase, and policies customers need before ordering. Collect them from support tickets, store documentation, and current policy owners. Then separate stable facts from time-sensitive operational data.

Good candidates include:

• How do I return an item?
• Which payment methods do you accept?
• Can I collect my order in store?
• How does warranty support work?
• Do you ship internationally?
• How do I contact support about a damaged order?

Avoid creating an FAQ simply because a phrase is searched often. If the answer is a product price, stock level, or variant-specific compatibility, connect a structured catalogue source instead. If the answer changes hourly, either maintain it deliberately or direct the user to the live source. An outdated FAQ can be worse than no FAQ because it sounds authoritative.

Do not place confidential operational instructions, private supplier terms, employee-only procedures, or personal data in custom knowledge. Write every answer as if it could be shown directly to a customer.

Write a strong question

Use the words customers naturally use. A question should express a clear intent and avoid internal terminology. “What is your returns process?” is better than “RMA workflow policy.” Add one FAQ per intent instead of combining unrelated questions such as “Do you ship abroad and can I return my order?”

Where wording varies, include natural alternatives in the question or answer without making it unreadable. For example:

Question: Can I return or exchange an item?

The answer can explain both return and exchange rules if they genuinely follow the same process. If the policies differ, create separate entries. Specific questions make retrieval more reliable and simplify future review.

Use a direct customer-facing voice. Refer to “you” and “your order” rather than internal department names. Keep titles and questions consistent with the terms used on your storefront, checkout, and email communications.

Write a complete answer

Lead with the answer, then give the required action and exceptions. The following pattern works for many policy FAQs:

1. State whether the service or policy is available.
2. Explain the action the customer must take.
3. State relevant conditions or deadlines.
4. Explain what happens next.
5. Link or direct the customer to the official process where appropriate.

For example:

You can request a return through our returns portal. Start the request using your order number and email address, then follow the instructions provided for your order. Items must meet the conditions in our returns policy. If the item arrived damaged, contact support before sending it back.

This is clearer than a vague answer such as “Returns are possible.” It tells the customer what to do without inventing a deadline or promise. Only include deadlines, fees, exclusions, and guarantees when they have been approved by the policy owner and are written precisely.

Use short paragraphs and plain language. Explain abbreviations on first use. Do not use aspirational language such as “always,” “instant,” or “guaranteed” unless it is a real, documented commitment. If an outcome depends on location, stock, carrier service, or order status, say so.

Add FAQs in Fynd

Open the custom knowledge area in Fynd and create a new FAQ entry. Enter the question, then add the approved answer. Give it a clear internal label if the interface supports labels or groups, such as Shipping, Returns, Payments, or Support. Labels make periodic reviews easier; they should not replace a well-written question.

Save the entry and test it with the kind of wording a customer would use. Try direct phrasing, a shorter phrase, and a related question. For example, after adding a return FAQ, test “How do I send something back?” as well as “Can I return my order?”

When several FAQs cover a process, review them together. Answers should not contradict each other. A shipping FAQ that says international delivery is available and a policy FAQ that says it is not will create inconsistent guidance even if both entries are individually well written.

Maintain ownership and review dates

Every FAQ needs an owner: a person or team responsible for confirming that it remains correct. For policy-related content, the owner may be operations, legal, support, or ecommerce. Record the source policy or internal approval route outside the answer itself if your team needs that audit trail.

Set a review cadence based on volatility. Payment methods and return conditions may need review after policy updates. Holiday delivery information may need a specific expiry date. Product care guidance may be stable, but should still be checked after a product range changes.

Review these triggers:

• a policy or legal wording changes;
• a payment or delivery provider changes;
• a support workflow changes;
• a seasonal exception begins or ends;
• customer conversations reveal misunderstanding;
• a product feed or Catalog API now provides better live data.

Archive or revise obsolete FAQs promptly. Do not leave two versions of a policy active and assume retrieval will choose the newer one. Make the currently approved answer the only authoritative custom entry.

Use custom FAQs with other sources

Fynd sources work best when each has a clear responsibility. A product feed or Catalog API provides structured, changing product data. A sitemap source provides public product and editorial pages; its sync UI can show blog counts for content detected as BlogPosting or Article. Custom FAQs provide concise, policy-level answers that may not exist reliably elsewhere.

When the same fact appears in two sources, decide which one is authoritative. For instance, a return period should normally come from one approved custom FAQ or policy page, not from multiple copied answers. Product availability should come from the catalogue source, not a manually typed FAQ.

Use the sync and knowledge UI to review each source after major changes. For sitemap sources, check blog counts and max_pages if articles are unexpectedly absent. For custom knowledge, test representative customer phrasing after each revision.

Troubleshooting FAQ quality

The answer is too broad

Split a long answer into separate questions when it contains multiple policies. One focused FAQ is easier to retrieve and update.

The answer has become outdated

Update it from the approved policy source, then retest common customer wording. If no owner can confirm the answer, remove it until it can be verified.

The assistant gives conflicting guidance

Search related FAQs and connected sources for the same policy. Choose one authoritative statement and revise or remove the competing version.

A question is not being matched

Rewrite it in customer language, add relevant natural terms to the answer, and test a few variations. Do not pad the entry with unrelated keywords.

Practical quality checklist

• One clear customer intent per FAQ.
• A direct answer before conditions and exceptions.
• No unpublished promises or internal information.
• Approved deadlines, costs, and eligibility rules only.
• A named owner and review trigger.
• Product facts left to feeds or the Catalog API.
• A quick test using natural customer wording.

Summary

Custom knowledge FAQs give Fynd an explicit source for important customer guidance. Keep every entry focused, approved, and maintained. Use them for stable policy and service answers, while letting sitemap crawls, XML/CSV feeds, and the Catalog API handle the public content and live catalogue facts they are designed to manage.