Published November 4, 20265 min
Software to Manage Customer Feedback in SaaS
Give Trial Users a Different Doc Set Than Customers
TL;DR
When your AI agent pulls from one shared doc set, it gives trial users billing and advanced-feature answers they can't act on, and buries the activation steps they actually need. Splitting your knowledge base by audience fixes deflection quality and removes a silent conversion killer.
The problem isn't your AI — it's what you're feeding it
When a trial user asks your AI agent "how do I connect my first integration?", they should get a tight, step-by-step activation answer with no noise. Instead, they often get a response that mixes in upgrade prompts, enterprise SSO notes, and billing FAQ — because your agent is drawing from a single doc set built for everyone.
That's not an AI problem. That's an information architecture problem.
Paying customers and trial users are at completely different stages. Their questions differ, their permissions differ, and the cost of a wrong or confusing answer differs dramatically. A paying customer confused about an invoice is mildly annoyed. A trial user who can't find the activation step in a wall of advanced-feature docs quietly churns without filing a ticket.
What a shared doc set actually does to response quality
Chattering's agent cites sources when it answers a question. That's useful — but only if the source is appropriate for the person reading it. When a trial user gets a citation pointing to your enterprise admin guide or a help article that begins "After upgrading to the Pro plan...", two things happen:
- The user reads an answer that assumes capabilities they don't have yet.
- Trust in the agent drops, because the answer feels wrong even if it's technically accurate.
On the paying-customer side, the reverse problem shows up. When a paying customer asks a nuanced question about a workflow they've been using for months, the agent may surface trial-focused onboarding articles that talk down to them. That's a different kind of friction, but it compounds over time into "your support bot is useless."
How to structure two doc sets without doubling your maintenance work
The goal isn't to write every article twice. It's to be deliberate about what belongs in each set.
Trial doc set — keep it narrow and activation-focused:
- Getting-started guides that assume zero prior setup
- Feature walkthroughs limited to what's available in trial
- FAQ that answers "what can I actually do right now?"
- Clear, low-friction paths to your first "aha" moment
Customer doc set — the full library, plus:
- Billing, invoicing, and plan management
- Advanced configurations and integrations
- API and webhook docs
- Anything that requires a paid feature to be meaningful
The maintenance shortcut: write your canonical articles once, then decide which set they belong in. Most articles belong in one, not both. The small overlap — password resets, basic account settings — can live in both without meaningful duplication.
In Chattering, you assign a doc set per agent configuration. Your trial-facing agent on your marketing site or in-app trial experience pulls from the trial set. Your customer-facing agent in your authenticated dashboard pulls from the customer set. One platform, two scoped knowledge bases.
Where this pays off in real support operations
Deflection rates mean different things for each audience. For trial users, a well-deflected question is one where the agent answered correctly and kept momentum toward activation. A bad deflection — technically answered but wrong for the context — breaks that momentum invisibly. You won't see it in your ticket volume; you'll see it in your trial-to-paid conversion rate weeks later.
For paying customers, deflection quality shows up in escalation rate. If your agent keeps surfacing trial-era content to customers who've been on the platform for six months, they escalate — not because the question was hard, but because the answer felt irrelevant.
Say your team handles 600 customer tickets and 200 trial tickets per month. Even if the AI deflects at a reasonable rate overall, a blended doc set means the deflection quality is mediocre for both groups. Splitting the sets typically tightens relevance enough that you see fewer "the bot didn't help me" escalations from each segment separately.
The handoff context also gets cleaner
When Chattering escalates a conversation to your shared inbox, it passes the full context: what the user asked, what the agent answered, which sources it cited. If your trial agent is scoped to trial docs, that handoff tells your team immediately: this is a trial user, the agent answered from trial content, and here's the gap. Your human knows to stay in trial-appropriate territory.
With a blended doc set, that signal disappears. The handoff might show a trial user who got an enterprise answer, and your team has to untangle what actually happened before they can help.
Start with the questions, not the docs
Before you split anything, pull the last 30 days of trial-user conversations from your agent. Look at which answers included sources that assumed a paid or advanced context. That list tells you exactly which articles to move out of the trial set first.
Do the same for paying customers: find the onboarding articles that keep surfacing in month-three conversations. Those belong in trial-only.
Two scoped doc sets, properly maintained, make your AI agent feel like it actually knows who it's talking to — because it does.
Frequently asked questions
Can't I just use a single doc set and tag articles by audience instead?
Tagging helps you organize, but Chattering's agent retrieves based on relevance to the question, not tags — so a trial user can still get a tagged-for-customers article if it scores well. Separate doc sets enforce the boundary at the retrieval level, not just the editorial level.
What happens when a trial user asks about a feature they'd get after upgrading?
Your trial doc set can include a lightweight upgrade-path article that explains what's available on paid plans without going deep on configuration — that's the right answer for a trial user, and it's a conversion opportunity, not a wall.
How do we keep two doc sets from drifting out of sync when we ship new features?
Treat the customer doc set as your source of truth and the trial set as a curated subset — when you publish a new customer article, decide at that moment whether it's relevant pre-conversion, and add a scoped version to the trial set if so.
