I am manually building AI support bots for 5 founders this month (to prove self-serve AI is a trap)
Last week, I posted about why Customer Support pros hate standard AI bots. The biggest takeaway? The bots are only as good as the raw documents they read.
When a founder signs up for an AI support tool, connects their messy Notion workspace, and sees the bot hallucinate on day one, they churn. Self-serve onboarding is fundamentally broken for AI if the underlying docs are outdated.
So, for FAQ Hub’s initial rollout, I am doing the exact opposite: I am doing the heavy lifting myself.
I am taking on 5 SaaS companies this month to do full concierge onboarding for free.
You give me your target URL or docs.
I will manually ingest them, clean up the CMS mapping, and set up the verification judge.
I will hand you a fully configured widget, Cmd+K modal, and fallback ticketing system that actually gives correct answers based on your approved content.
We run it for 30 days to measure actual ticket deflection.
Because I am doing the data cleanup and implementation manually to ensure zero hallucinations, I strictly only have the bandwidth to take on 5 companies for this cohort.
If you want to see what strict, CMS-verified AI support looks like on your own site without doing the setup work, let me know below or shoot me a DM.
For the other founders here: did you start with concierge onboarding in your early days, or did you force self-serve from day one?
Concierge onboarding is a strong wedge when the failure mode is data quality, not UI complexity. I’d turn each of the five implementations into a preflight checklist and a failure taxonomy (stale docs, permissions, live-state questions, missing sources), then measure setup hours, first-answer accuracy, and time-to-correct rather than just ticket deflection. The handoff to self-serve can be staged: keep a human gate for source verification, but automate the repeatable cleanup and mapping steps once they pass the checklist. Your 30-day cohort should tell you which work is productizable and which is the moat.
The 5-company test should reveal a lot.
I’d be curious which part of the concierge setup is hardest to automate afterward: document cleanup, CMS mapping, or verification.
I'll keep you posted.
The part I would add: docs are only half the knowledge base. A lot of the tickets that make support bots look stupid are about live state - where is my order, is my account still active, did that payment go through - and no amount of cleaning the Notion workspace fixes those, because the answer is not in a document at all. Those questions need the bot wired to a live source it can actually query, with an explicit "I could not verify this right now" fallback instead of a confident guess.
I build in that world (a small API that turns a carrier's public tracking page into JSON), and the thing that surprised me is how often the source itself is unreliable - the fetch times out or the page changes shape. If the bot cannot distinguish "verified, here it is" from "could not check," it will hallucinate exactly at the moment the customer is most anxious. Worth carving out during your five manual builds: which questions are docs and which are live lookups, because the second bucket is where self-serve really falls apart.
That is a massive blind spot for most bots. Static docs are only part of the puzzle. When someone asks about live account state, billing status, or an active order, pointing them to a help article is completely useless.
The point about API unreliability is so true. External data sources drop, time out, or change structures all the time. If the bot doesn't have an explicit safe state for a failed lookup, it panics and makes something up right when the user is most stressed.
This is exactly why doing these manual builds is so valuable. It forces you to map out where static documentation ends and live system queries begin, long before you try to scale.
Are you building that tracking API as a standalone microservice, or integrating it directly into customer-facing workflows?
Concierge vs self-serve is measurement precision vs scaling. You're choosing to sacrifice throughput to get the measurement right first - zero hallucinations means verification actually works. Self-serve fails not because the tool is bad, but because the measurement layer is broken: messy source docs feed the LLM, and founders can't tell if wrong answers come from bad data or bad prompting. You're fixing the data layer before scaling, which means your 30-day measurement actually isolates ticket deflection instead of conflating it with onboarding quality. Most founders flip this: they launch self-serve, see low deflection, blame the AI, and churn before discovering their docs were the problem.
You nailed it. That line about conflating ticket deflection with onboarding quality is exactly what is happening across the board right now.
When founders just point a scraper at a messy Notion workspace, they are not really testing the AI. They are just exposing their own outdated docs. But of course, when the bot starts making things up, the founder blames the tool.
I learned this the hard way building support systems for the sports betting industry. The AI is completely useless if the underlying knowledge base isn't locked down tight.
By migrating these first few founders into the CMS myself and verifying the content, I can completely remove that bad data variable. Then they can actually see what pure ticket deflection looks like.
Are you building something in data or AI yourself? You have a really solid grasp on how to measure this stuff properly.