AI Chatbot for Notion: the documentation exists, the customer still asked
Somebody wrote it all down. The refund policy, the setup guide, the twelve edge cases — three years of careful Notion pages, nested four deep, and the person emailing you at 9pm will never find any of it. Writing the answer and delivering the answer are different jobs. A chatbot fed from your Notion content does the second one, and this page is honest about which parts of that are easy and which are not.
Get Started Free See the three routesSee what the chatbot would answer
Enter your website. The assistant reads your public pages first — a useful baseline before you decide which internal documents are actually missing.
Why a good Notion wiki still leaves customers stuck
A Notion wiki is organised by the mind that built it. Sections nest inside sections because that is how the work is structured, and the structure is genuinely correct. Then a customer arrives with a sentence like "does the warranty still count if I bought it secondhand", and there is no branch of your tree called that. There is a Notion page called Warranty → Coverage → Ownership transfer, and the sentence in the middle of it is the answer.
Search does not close that gap either, because search matches words and the customer used different words. What closes it is retrieval plus a chatbot that can read the paragraph it found and answer the question that was actually asked. The wiki stops being a place to browse and becomes a place to draw from.
The writing is already done. What is missing is a way for someone who does not know your structure to get one paragraph of it, in their own words, at 9pm.
Worth setting an expectation before the steps: there is no Notion connector in Asyntai, no OAuth screen and no stored token, so nothing reads your workspace in the background. Content moves across deliberately. That sounds like a limitation and it is one, but it also means you decide exactly what a customer-facing assistant can and cannot repeat — and in a workspace that also holds salary bands and half-finished strategy docs, that is not the worst default.
Three routes out of Notion, and how to pick one
The right route depends entirely on what shape your content is in. Get this wrong and you will spend an evening on an export that could never have worked.
| What you have | Route | What it costs you |
|---|---|---|
| A full-page Notion database: FAQ rows, a product table, a policy list | Export as CSV, upload as spreadsheet knowledge | Five minutes, repeated whenever the table changes |
| A wiki of written Notion pages, already public or publishable | Publish to the web, point the crawler at the address | One decision about what becomes public |
| A Notion workspace that must stay private | Move the customer-facing pages across by hand, as text or documents | An hour, once, for the ten pages that matter |
Most teams need two of the three. The FAQ database goes into the chatbot as a CSV because rows retrieve beautifully; the written guides go in through the crawler or by hand, because prose does not fit in a spreadsheet.
Route one: a Notion database becomes chatbot knowledge
This is the clean one. A full-page Notion database exports as a CSV, and the spreadsheet import in Asyntai is built for exactly this shape: each data row is stored as its own retrievable chunk, so the chatbot answers a question about one policy with that policy rather than a paragraph mentioning eleven.
… menu at the top right, choose Export, and set the export format to Markdown & CSV. You get a ZIP. A full-page database comes out as a CSV of its rows and properties, with Markdown files for the subpages if you asked for them.Question, Answer, Applies to or Region are read by the AI as part of the answer. Delete internal columns — owner, review date, tags nobody outside your team understands — because they add noise to every chunk..csv and .xlsx are accepted; a Markdown file is not a spreadsheet and will be refused. Row limits follow your plan: 100 data rows on Free, 500 on Starter, 2,000 on Standard, 10,000 on Pro. The header row is not counted.If a monthly manual export will not survive contact with reality, the same upload exists as an endpoint — a multipart/form-data POST with the file in a field called file. API access needs a paid plan.
The response reports rows_processed and chunks_created, and it is worth checking the first number against what you sent: the dashboard refuses an oversized file outright, while the API accepts it and stops at your plan's row limit. Reference is in the API documentation.
Route two: written pages, where a spreadsheet stops helping
Most Notion wikis are not tables. They are prose — headings, callouts, toggles, a numbered procedure with a warning in the middle — and no honest advice turns that into rows. Two things actually work.
Publish the pages and let the crawler read them
In Notion, under Share, there is a Publish tab, and publishing gives the page a public address on a notion.site domain. From that point it is simply a website, and the Asyntai crawler treats it as one: give it the address and it reads the pages it can reach. This is the fastest route for any team whose documentation was going to be public eventually.
Do check what came through rather than assuming. Look at the knowledge entries after the crawl and read a couple. Deeply nested pages, content hidden behind toggles and anything the crawler could not reach from a link may simply not be there — better to find that out now than from a wrong answer later.
Move the pages that matter, by hand, once
If the Notion workspace has to stay private, resist the urge to solve the whole thing. Look at your last fifty support conversations, find the ten questions that keep coming back, and bring across the pages that answer them — paste the text in as a knowledge entry, or export the page and upload it as a document. It takes an hour, and it beats a bulk import of three years of meeting notes, which mostly shows the chatbot how your team talks internally.
Ten pages that answer real questions outperform a whole workspace. Coverage is not the goal; hit rate is.
Route three: chat events that create a Notion page
The other direction — conversations landing in your workspace as rows in a database — needs one piece in the middle, and it is fair to explain why. Asyntai webhooks POST a fixed JSON body with an event field and a payload field, and they send exactly three headers: Content-Type, X-Webhook-Event and X-Webhook-Signature. There is nowhere to put a Notion token, so the webhook cannot call the Notion API on its own.
Four events are available, configured in Asyntai under Settings → API: escalation.requested, conversation.started, message.received and takeover.started. Tick the ones you want per webhook.
Then add a connector. In Make, start a scenario with Webhooks → Custom webhook and finish with the Notion Create a Database Item module. In Zapier, start with Webhooks by Zapier → Catch Hook and finish with Create Page, which creates a page inside a parent page, or Create Data Source Item, which creates an item in a data source. n8n, Pabbly and a small endpoint of your own work the same way. Paste the connector's URL into Asyntai, set a signing secret, and send one real chat so the tool learns the field structure from an actual request.
Begin with escalation.requested only. Enabling message.received on a busy site creates a page per exchange, and your connector's operation count will find that before you do.
Two workflows worth building first
Both are a webhook trigger plus one step, and together they form a loop rather than two separate features.
The documentation gap list writes itself
Send escalations into a Notion database called something blunt like Questions we could not answer, with a status property. Every row is a customer telling you which page you have not written yet, in their own words, dated. A writer opening that database on a Monday has a prioritised backlog that did not exist on Friday — and unlike a survey, nobody had to be asked.
Closing the loop back into the assistant
Now finish it. When somebody writes the missing answer into that same Notion database, the row has a question and an answer sitting side by side. Export the database as a CSV, upload it, and the gap the chatbot had last month is knowledge it has this month. Your gap list and your knowledge base are the same object, viewed twice.
What a Notion-fed chatbot does well
Answers using your own content
Replies are drawn from the pages and rows you supplied, not from generic AI knowledge, so the assistant speaks with your policies rather than around them.
Row-exact retrieval
Each row of an exported Notion database is stored and searched separately, so one question retrieves one policy instead of a page that mentions several.
You choose what is exposed
Nothing reads your Notion workspace in the background. What the chatbot can repeat is exactly the material you moved across, which matters in a workspace holding more than support docs.
Replies in their language
Documentation written in one language still answers visitors in theirs. 30+ languages, detected from the question, nothing to configure.
Signed webhooks
Every delivery carries an HMAC-SHA256 signature of the body generated from your secret, so your connector can reject anything that did not come from your account.
A knowledge base that improves itself
Unanswered questions arrive as rows, get answered by a human, and go back in as knowledge on the next upload. The loop is short and it is visible.
Notion chatbot questions
Can the chatbot answer from my Notion workspace?
Yes, but not by connecting to it. There is no connector and no stored token, so nothing reads your workspace in the background. You move content across one of two ways: export a full-page database as CSV and upload it as spreadsheet knowledge, or publish the pages and let the crawler read the notion.site address. Private prose pages can be pasted in as text or uploaded as documents.
How do I export a database as CSV?
Open the page, click the … menu at the top right, choose Export, and pick Markdown & CSV as the format. You get a ZIP. A full-page database becomes a CSV of its rows and properties, plus a Markdown file per row if you included subpages. Asyntai accepts the CSV; the Markdown files are a separate job.
Does the CSV include the text inside each page?
No, and this catches people out. The CSV holds the properties — the table you can see. The body of each page, the paragraphs written inside a row, exports as its own Markdown file. If your real answers live in those bodies, the CSV route alone will not carry them; use the published site or a document upload instead.
What is the best way to bring a whole wiki across?
Publish it. Share, then the Publish tab, gives the page a public notion.site address, and the crawler reads a public URL like any other website. Check what it actually captured afterwards. If the workspace must stay private, bring across the ten pages that answer real customer questions and leave the rest — hit rate beats coverage.
Can a conversation create a page?
Yes, with one connector in the middle. The webhook posts a fixed JSON body and sends only Content-Type, X-Webhook-Event and X-Webhook-Signature, so it cannot authenticate on its own. Route it into Make, Zapier, n8n, Pabbly or your own endpoint: Make has a Create a Database Item module, and Zapier offers Create Page and Create Data Source Item. Webhooks need a paid plan — see pricing.
Related pages
Other sources the assistant can draw on, and other tools that carry the same four events.
Put the writing to work
Bring across one Notion database and the ten pages people actually ask about. The free plan includes 100 messages a month, which is enough to find out whether your documentation answers real questions.
Get Started Free