Set up bots and personas

Configuring bots and personas

Why bots are more than "turning on the chatbot"

In Fynd, each bot is a persona: name, tone, language, system prompt, widget copy, theme, and optionally dedicated knowledge. Visitors talk to that persona through the embed (data-bot="slug"). Catalog RAG supplies product facts; the persona shapes how answers sound and which boundaries apply.

This article helps shop operators choose between one or multiple bots, fill in fields correctly, separate knowledge, and avoid pitfalls when personas overlap.

One bot or several?

Start with one bot when…

• Your assortment serves one clear audience.
• You are just getting started with Fynd (Starter trial, first 14 days).
• Your plan is Starter: maximum 1 bot.
• You want to go live quickly without scope debates.

One well-configured default bot covers most storefronts. Invest in knowledge sources, prompts, and playground tests before splitting.

Consider multiple bots when…

• Product lines differ strongly (e.g. consumer vs. business, fashion vs. outdoor).
• Language or market needs a different tone (NL vs. DE with fixed bot language).
• Knowledge must stay separate (B2B catalog vs. consumer PDPs).
• Your Growth plan (up to 3 bots) or Pro plan (up to 10) allows it.

More bots mean more maintenance: sync scope, prompts, embed slug, and analytics per bot. Add only what delivers a measurable difference.

Plan limits at a glance

When you hit the limit, the dashboard shows an upgrade prompt. Do not delete unused bots lightly: linked knowledge is removed with them.

Persona wizard versus manual editing

Persona wizard (Bots → new persona), You describe your shop in one prompt; AI generates name, role, tone, welcome text, disclaimer, suggested prompts, and system prompt. Ideal for the first bot.

Manual editing: After creation, fine-tune every field. Use "Improve with AI" / "Extend with AI" on the system prompt for targeted changes, but always review and save.

Identity: field by field

Open Bots → [persona] → Edit.

Name (persona_name): First name or brand name in the chat header ("Mira", "Shop assistant"). Short and human; no internal code names.

Slug (slug): Technical key for the embed: data-bot="outdoor". Lowercase letters, numbers, hyphens only. Change slug only after updating embed documentation; old snippets will point to the wrong bot.

Role title (role_title): Subtitle under the name ("Running shoe advisor", "Skincare guide"). Sets expectations.

Avatar URL: Optional. Square image, HTTPS. Without avatar: initials from the name.

Voice and style

Tone: Choose from friendly, professional, expert, playful, premium, direct. Shapes default framing in generated prompts; align with brand.

Language: Fixed bot language or automatic:

• Always Dutch: Answers in NL even if input is English (unless the prompt says otherwise).
• Always English / German / French: Fixed language for that market.
• Visitor language (fallback NL): Bot follows the shopper where possible; Dutch fallback.

Pick one language mode per bot. Multiple markets with fixed copy? Often cleaner: one bot per language than one bot with mixed instructions.

Response length: Short, balanced, or detailed. Match mobile behavior (short) vs. complex technical catalogs (detailed).

Emoji: None, light, or expressive. Premium B2B: usually none; lifestyle: light can work.

Widget copy

Welcome message: A few sentences at most. State what the bot can do ("help you choose a product") and invite a concrete question.

Disclaimer: Honest about AI and catalog limits. No medical, legal, or price guarantees without approved copy.

Suggested prompts: Up to 8 lines. Use real shopper intents from support or on-site search.

Fallback when knowledge is missing: What the bot says when RAG finds nothing. For example: honestly "I don't know from the catalog" plus a handoff.

System prompt: the real control layer

The system prompt (max. 12,000 characters) is the sole source for persona and conversation flow. Fynd automatically adds catalog rules (no invented prices, max. three products, etc.).

Good prompts include:

1. Role: Who are you, for which shop?
2. Boundaries: No medical claims, no internal discount codes, do not ask for payment details.
3. Conversation flow: Ask questions first, then advise (default template already does this).
4. Assortment focus: "Running shoes only", "No accessories unless asked".
5. Language: Repeat language choice if it differs from dashboard settings.

Improve with AI: Polishes an existing prompt. Extend with AI: Adds sections (e.g. seasonal advice). Optional AI instruction: "more focus on students", "shorter answers".

After AI editing, check for conflicts with disclaimer or language settings. Always save manually.

Knowledge: shop-shared versus bot overlay

In Knowledge you link sources to the shop or to one bot.

Shop-shared (catalog): Sitemap, feed, API products without bot_id. All bots see this catalog unless knowledge isolation is active.

Per-bot overlay: Source with scope "Overlay: [persona]". Only that bot sees those products/chunks. Useful for separate assortments.

Knowledge isolation: Advanced setting (isolate_knowledge on persona). When on: retrieval sees only that bot's knowledge, not the shop-shared catalog. Use only when you deliberately want a demo or niche bot without shared products. Forgetting isolation while expecting overlays is a common mistake.

Practical rules:

• One catalog, multiple tones → shop-shared + different prompts, no overlays needed.
• Two real catalogs → two bots + overlays or separate feeds per bot.
• Test in playground with bot selector: product and chunk counts must match expectations.

Default bot and embed

Default bot (is_default), Used when the embed does not specify a bot or embed builder has no choice. Set via Bots → "Make default". One default per shop.

Embed builder: Chooses which slug goes in the snippet. Must match the bot you want to show. Default bot ≠ embed bot if you manually paste a different slug in theme code.

Pin to /demo

Pin to /demo shows this persona on your curated demo page (/demo). Useful for sales, onboarding, or internal review. Pinning does not change your live embed automatically. Keep demo and production copy aligned where possible to avoid surprises.

Theme per bot

Primary, accent, background, text, hex colors per bot. The embed loads theme via bot config. Multiple bots on different pages (different slugs) can show different colors; one site-wide embed shows one bot theme.

Test contrast on mobile. Dark primary with dark chip text can be hard to read.

Leads and handoff (brief)

Collect email after answers: Optional lead capture. Notification email: Internal address for leads. Handoff prompt: Text when human follow-up is offered. Align with privacy policy; do not ask for data before delivering value.

Pitfalls with overlapping bots

Two bots, same knowledge, prompts only differ: Can work for tone A/B, but shoppers often notice little difference. Measure whether the split pays off.

Overlapping overlays + shared catalog: Bot A and B both see everything; advice feels identical. Fix: tighten scopes or use isolation deliberately.

Wrong slug in embed: Bot B live while you tested Bot A in the playground.

Language mismatch: Dashboard "Always NL", prompt "Always English". Answers fluctuate.

Overlong system prompts: Guidelines get lost. Keep core rules at the top; use FAQs for facts.

Deleting a bot: Destroys linked knowledge. Export/document before delete.

Starter with a multi-bot plan in mind: You cannot; upgrade first or keep one persona sharp.

Operational checklist per new bot

• Clear scope: which assortment / language / pages?
• Unique slug, documented
• Knowledge sources: shared or overlay; isolation yes/no chosen deliberately
• System prompt + widget copy reviewed
• Playground: at least 10 scenarios including edge cases
• Embed snippet updated or separate pages with correct data-bot
• Default bot set deliberately if this is the main persona
• Analytics: filter by bot where the dashboard supports it

Maintenance

• After catalog sync: re-run core questions per bot.
• After price or policy changes: update FAQs (shop-shared) and test all bots that mention policies.
• Quarterly: read unanswered questions; decide which bot needs FAQ or prompt updates.

Bots are the steering wheel for how shoppers experience Fynd. One strong persona beats three half-finished bots. Add complexity only when assortment, language, or knowledge truly require it.