Chat Onboarder — Operator Guide
A step-by-step walkthrough of the dashboard, from creating a client file to handing off a tested chatbot.
What this tool is
Chat Onboarder is the operator dashboard for building the knowledge base and personality of a client’s chatbot. Each client lives as a single “file” made of eight parts. You fill the parts in order; the test chatbot at the end assembles them into a working agent.
- One client per row on the home page.
- Eight tabs per client — finish them in order.
- Everything is saved automatically to Supabase; you can leave and come back.
Creating a new client
- From the Clients page, click + New client.
- Enter the client name and website URL. The slug auto-derives from the URL.
- Save. You land in the client file with the eight-tab navigator across the top.
The eight tabs
1 · Intake
The questionnaire you answer live during the client interview. Free-form JSON answers. New questions are added in code via src/lib/intake/questions.ts.
Tip: capture anything that won’t appear on the website — hours, service area, off-menu offerings, who to escalate to.
2 · Website scrape
Playwright crawls the URL from the intake form and reduces every page (home, about, services, contact, privacy, FAQ, blog, etc.) to dense bullet points stored in Supabase.
- Click Run scrape. Re-runs overwrite.
- Review the bullets per page; delete or edit anything the model got wrong.
3 · Documents
Upload PDFs and DOCX files the client hands over — SOPs, refund policies, menus, price sheets, internal FAQs. Each upload is extracted to text and bullet-summarized.
- Drag-and-drop or pick files.
- Delete uploads you don’t want the bot to know about.
4 · Industry + competitors
Operator-authored facts that aren’t on the client’s website. One row per fact. Also where competitor names get tagged so the bot knows not to recommend them.
Example: “Real estate agents in Ontario are bound by RECO” or “Do not refer customers to Acme Corp.”
5 · FAQs
Seeded list of likely questions and your approved answers. The chatbot draws from these first when a user asks something close to a known FAQ.
- Add, edit, reorder, or delete entries.
- Keep answers tight — one short paragraph each.
6 · Tone
How the bot should sound. Persona, greeting line, do-say/don’t-say lists, and language style. This is the difference between a stiff FAQ bot and one that feels like the brand.
7 · KB review
A consolidated view of everything the bot will know — scrape + documents + industry context + FAQs. Use this to spot gaps and contradictions before handoff.
8 · Test chatbot
Live chat against Claude with the assembled system prompt. Try the questions the client’s real customers would ask. If answers are wrong, go back to the relevant tab and fix the source — don’t patch the prompt.
Recommended workflow
- Run the intake call. Fill tab 1 live.
- Trigger the scrape (tab 2) before the call ends so it’s done by the time you need it.
- Upload everything the client emailed you (tab 3).
- Add industry + competitor facts (tab 4) and seed the FAQ list (tab 5).
- Write tone last (tab 6) — easier once you know the content.
- Skim KB review (tab 7) for obvious gaps.
- Stress-test in tab 8 with at least a dozen realistic questions.
Troubleshooting
- Scrape returns very little.
- Site is likely JS-heavy or behind a paywall/login. Hand-feed the missing pages as documents in tab 3.
- Bot makes up facts.
- Check KB review (tab 7) — the answer the bot invented is usually a gap, not a model failure. Add it to industry context or FAQs.
- Bot answers off-brand.
- Tighten tab 6: add concrete do-say/don’t-say lines rather than abstract adjectives.
- “Supabase not reachable” on the home page.
- Env vars missing. Fill
.env.localand run the migration insupabase/migrations/0001_initial_schema.sql.
Saving this as a PDF
Click Download PDFat the top of this page. Your browser’s print dialog opens — choose Save as PDF as the destination and save. The dashboard chrome is hidden automatically for print.