Meet Aisha, Head of People Operations at a 140-person SaaS
Aisha runs People Operations at a remote-first B2B SaaS company with 140 employees spread across 11 countries. The company handbook lives in Notion across roughly 800 pages, accumulated over four years by every department: People Ops, Finance, IT, Engineering onboarding, security, parental leave, the office-stipend policy, the home-office reimbursement form, the visa support process, the equity refresh schedule, the performance-review rubric, and so on.
The handbook is good. The problem is that it's too big to navigate. New hires open Notion on Day 1, see a sidebar with 23 top-level pages and another 60 nested under "People Operations", and immediately give up and ask in Slack instead. Tenured employees do the same when they need to find something they haven't touched in six months.
Aisha's People Ops team of three gets roughly 12 questions per week in the #ops-help channel that are answered verbatim in the handbook. The same questions repeat. "How many PTO days do I have left?" "What's the expense limit for client dinners?" "How do I request parental leave?" "How do I reset my Okta password?" "When does the next equity refresh happen?" "Is Friday a company holiday in India?" Across a quarter that's roughly 150 questions, of which maybe 130 are already documented and 20 are genuinely new edge cases.
The goal is not to fire the People Ops team. The goal is to give them their Friday afternoons back, and to give new hires a faster path to the answer than waiting four hours for a Slack response.
The before-state: same 30 questions, every quarter
Before deploying any kind of chatbot, the typical pattern looks like this. A new hire joins on Monday. By Wednesday they have a list of process questions. They open the handbook, search "PTO", get 14 results across various pages, can't tell which is current, and ask in #ops-help. Someone on Aisha's team links the right page, the new hire reads it, the conversation moves on.
Multiply that by 5 new hires per month, plus the existing employees rediscovering policies, and the People Ops team spends roughly 6 hours per week answering questions that already have authoritative answers in the wiki. The wiki is not the problem. The discoverability of the wiki is the problem.
The 30 questions that show up over and over, by rough frequency, look like this. PTO balance and how to request it. Expense reimbursement limits by category (meals, travel, client entertainment, home office). Parental leave eligibility and process. The remote-work stipend rules. The home-office equipment policy. The IT password reset and 2FA enrollment process. The Okta and SSO enrollment for new tools. The onboarding checklist for the first 30 days. The training-budget reimbursement policy. The conference-attendance approval flow. The performance-review schedule and rubric. The equity refresh cadence. The bonus structure and timing. The promotion process. The 1:1 cadence expectations. The team handbook search across departments. The travel booking tool and per-diem rates. The vacation blackout dates for the year. The company holidays by country. The sick leave policy and notification process. The bereavement leave policy. The jury duty process. The visa support and immigration policy. The relocation policy. The parental leave handoff process. The medical insurance election windows. The 401k or local-equivalent retirement contribution and matching rules. The wellness stipend rules. The learning and development budget. The internal job posting and transfer process.
If your wiki answers more than 25 of those questions and your team still gets asked them in Slack, you have the same problem Aisha has. The bot's job is to answer those 30 questions, and to honestly say "I don't know, ask in #ops-help" for the 20 genuine edge cases.
The architectural honesty: how do you get internal content into ChatRaj
This is the part most use-case pages would skip. ChatRaj is built for public content. The crawler reads public URLs and indexes whatever HTML it can fetch. That works beautifully for marketing sites, blog posts, product documentation, and help centers. For an internal wiki it introduces a real constraint: the crawler cannot log in to your private Notion workspace and fetch authenticated pages.
There are three honest workarounds, each with tradeoffs you should know up front.
The first option is to publish the handbook to a public URL on an internal subdomain. Many Notion workspaces can be configured to publish pages publicly, and the resulting URLs are crawlable by any HTTP client including ChatRaj. The pages are public in the sense that anyone with the URL can read them. You can layer network-level access control (an IP allowlist, a Cloudflare Access policy, a reverse proxy that whitelists the ChatRaj crawler's IP range) to limit human discovery, but the bot's pipeline still reads the pages as plain HTTP responses. This works well if your handbook content is not highly sensitive and your security team is comfortable with "public URL plus obscurity".
The second option is to use Notion's public-share feature with link-only access. Notion lets you publish a page to a shareable URL without indexing it in search engines. The link is not guessable, the page is not crawled by Google, but the URL is fetchable by anyone who has it (including ChatRaj). The advantage is that your handbook stays inside Notion and you don't have to spin up an internal subdomain. The disadvantage is that anyone who discovers the URL can read the content, so it's appropriate for handbooks that are sensitive-but-not-secret, not for content like security incident postmortems or legal contracts.
The third option is to skip the crawl entirely and upload internal documents as files directly to the ChatRaj dashboard. ChatRaj accepts PDF, Word, plain text, Markdown, CSV, XLSX, and HTML uploads. If you export the relevant handbook sections from Notion as PDFs or Markdown and upload them, the content never has to live at a public URL at all. The disadvantage is the freshness problem: when the handbook updates, you have to re-export and re-upload. Some teams accept this and put a quarterly refresh on the People Ops calendar. Others find it too high a maintenance burden and prefer one of the URL-based approaches.
None of these workarounds is dishonest, and none of them is perfect. The right choice depends on how sensitive your content is, how often it changes, and how much operator time you want to spend on refresh.
What Day 1 looks like vs Day 30
On Day 1 of the deployment, Aisha's team uploads a curated subset of the handbook to ChatRaj: the People Ops policies, the IT password reset guide, the onboarding checklist, the expense policy. Maybe 60 pages, exported from Notion as Markdown. The bot is embedded in an internal-only page (an internal-only subdomain that requires Okta SSO to reach, with ChatRaj's widget loaded on it). The team announces it in #general: "New self-serve bot for handbook questions. Try it. Tell us what it gets wrong."
On Day 2 through Day 7, the bot handles maybe 30 questions. The People Ops team reviews the conversation log in the ChatRaj dashboard, sees which questions the bot answered well, and which ones it punted on. The Unanswered tab surfaces the gaps. Some are real content gaps in the handbook (the bot couldn't answer because the answer isn't actually written down anywhere). Others are phrasing mismatches (the bot couldn't find "what's the per diem in Tokyo" because the handbook says "per-diem rates by city" and the page wasn't crawled because of an embed issue). Aisha fixes the gaps and resyncs.
By Day 30, the bot is handling the majority of incoming process questions in real time. The People Ops team's Slack workload has dropped by roughly 40-60% on routine questions (your mileage will vary based on how good your handbook is to begin with). New hires get same-second answers instead of four-hour waits. Tenured employees rediscover policies without bothering anyone. The People Ops team uses the freed Fridays for the actually-strategic work: comp benchmarking, manager training, the next round of policy updates.
The Unanswered tab becomes the most valuable surface in the dashboard. Every question the bot could not confidently answer is editorial backlog for the wiki: either the answer is missing, or the wiki page exists but isn't indexed, or the phrasing in the wiki doesn't match the phrasing employees use. All three are fixable.
Slack integration today vs the website embed approach
A common follow-up question: can the bot live inside Slack instead of inside a web widget? Today, the honest answer is that ChatRaj's primary deployment mode is a website widget loaded via a script tag. Slack channel integration is on our 2026 roadmap but is not shipped today.
The practical pattern teams use today is to embed the ChatRaj widget on an internal portal page (an Okta-protected URL on an internal subdomain) and link to that page from a Slack channel description or from #general. Employees who want to self-serve open the link, ask the bot, and get an answer. This is not as low-friction as "ask the bot directly inside Slack" but it works, and it requires no API integration on day one.
When the Slack channel integration ships, the migration path will be mechanical: same chatbot, same training sources, new delivery surface. Teams that deploy the widget today will not have to rebuild anything when Slack support arrives.
Where this honestly does not work
A few scenarios where deploying a chatbot over your internal wiki is the wrong call.
Highly sensitive content. If your handbook includes content that should be visible to specific people only (security incident postmortems, legal hold notices, individual compensation, M&A planning), do not put that content into any of the three workarounds. The whole approach assumes the content is at least "shareable across the company" sensitivity, not "need-to-know" sensitivity.
Regulated workflows. If your team operates under regulations that require audited access logs for every read of certain documents (some financial services and healthcare contexts), the public-URL workarounds will not satisfy your auditor. In those cases, the right answer is either an enterprise-grade internal-only chatbot product with proper authentication and audit logging, or a hybrid where ChatRaj handles only the non-regulated content and the regulated content stays out.
High-churn content. If your handbook updates daily and you cannot accept any indexing lag, the file-upload workaround becomes high-maintenance. The URL-based workarounds work better here because ChatRaj can recrawl on a schedule. Most People Ops handbooks update weekly or monthly, which is well within ChatRaj's refresh cadence.
Tiny teams with low question volume. If you are a 12-person company and you get one question per week, the bot is overkill. The deflection math only starts paying back somewhere in the 30-50 employee range. Below that, just keep answering in Slack.
Next step: try the free tier on a curated 20-page subset
The fastest way to know whether this works for your team is to upload a curated 20-page subset of your handbook (the PTO policy, the expense policy, the onboarding checklist, the IT password reset guide, and a few others) on ChatRaj's free tier, ask the bot the 30 questions your team gets repeatedly, and grade the answers. The free tier gives you 100 messages per month, no credit card, and no time limit on the evaluation. If the bot answers 25 of 30 correctly with reasonable citations, the deployment is worth pursuing. If it answers 15 of 30, your handbook probably has gaps the bot will help you find before you commit further.