This guide takes the reader assistant from a default setup to a production-ready configuration. It focuses on what readers experience directly and on the operati...
This guide takes the reader assistant from a default setup to a production-ready configuration. It focuses on what readers experience directly and on the operati...
This guide takes the reader assistant from a default setup to a production-ready configuration. It focuses on what readers experience directly and on the operational choices that affect answer quality, escalation behavior, and cost control.
Who this is for
- documentation leads launching the assistant on a published site
- support or product teams using the assistant to reduce repetitive questions
- admins who need a safe and predictable assistant configuration before broad rollout
What the assistant configuration controls
In Project settings → Assistant, Doxbrix groups the configuration into these areas:
- Availability & status
- Identity & greeting
- Answers & behavior
- Support handoff
- Safety & limits
- API Keys & Embed
Treat these as production controls, not just cosmetic options. Together, they define whether the assistant is visible, how it sounds, what it does when the docs are weak, and what happens when readers still need human help.
Step 1 — Decide where the assistant should run
Under Availability & status, review:
- Reader assistant
- Authoring assistant
- Automation tasks
- Assistant status
For a reader-facing launch:
- turn on Reader assistant
- leave Authoring assistant and Automation tasks aligned with your internal policy
- set Assistant status to Active only when the reader experience is ready
Use Maintenance when the assistant should stay configured but temporarily stop serving normal traffic.
Step 2 — Name and introduce the assistant clearly
Under Identity & greeting, set:
- Assistant name
- Welcome message
- Starter questions
Good guidance:
- use a name that feels native to the product experience
- make the welcome message explain what the assistant can help with
- make starter questions reflect real reader tasks, not internal jargon
Example starter questions are strongest when they mirror support demand:
- “How do I invite a teammate?”
- “Why can’t I access this project?”
- “How do I connect Git Sync?”
Step 3 — Choose the right engine and answer style
Under Answers & behavior, configure:
- Assistant engine
- Response length
- Fallback mode
- Fallback message
- Show citations
Choose the engine
Use:
- Spark when you want fast, lightweight responses for common questions
- Atlas when the assistant needs deeper reasoning for harder or multi-step questions
For most public documentation sites, start with Spark unless the content set is complex enough that readers regularly ask layered questions.
Choose the response length
- Brief is best for direct support-style answers
- Balanced is a strong default for most product documentation
- Detailed is best when questions often require explanation and context
Turn on citations unless you have a reason not to
Use Show citations for production launches whenever possible. Citations help readers trust the answer and help your team debug where the assistant is grounding its responses.
Step 4 — Decide what happens when the docs are not enough
Fallback mode is one of the most important settings in the assistant experience.
It controls how the assistant behaves when the documentation does not contain enough information.
The main choices are:
- answer with fallback behavior
- deflect only
- custom message
Use:
- a fuller fallback when the assistant should still try to help readers progress
- a more restrictive mode when accuracy is more important than conversational completeness
- a Fallback message when you want strict, branded guidance for low-confidence situations
Step 5 — Configure support handoff
Under Support handoff, review:
- Support email
- Show help button
- Help button label
- Help button action
- Help button URL
This area controls what the reader sees when the assistant cannot resolve the question directly.
Recommended pattern:
- turn on Show help button
- use a clear Help button label
- choose Email only if email is the actual support path you want readers to use
- choose URL when you already have a real ticket or support destination
The support handoff experience should feel like a continuation of the assistant, not a dead end.
Step 6 — Set usage and safety limits
Under Safety & limits, configure:
- Approval mode
- Monthly budget
- Rate limit per IP
For the reader assistant, these matter for cost control and abuse prevention.
Recommended defaults for a first launch:
- keep approval behavior conservative if assistant-generated follow-up actions can affect internal workflows
- set a Monthly budget if you need project-level spend visibility
- set a realistic Rate limit per IP to reduce misuse without blocking normal users
Step 7 — Test the assistant as a reader
Before enabling the assistant for broad use:
Verify that the assistant answers correctly and cites the expected pages.
Check whether the assistant stays grounded instead of becoming speculative.
Verify that fallback behavior and support handoff feel intentional and useful.
Confirm that the assistant widget and starter questions are readable in both contexts.
Step 8 — Review assistant performance after launch
After the assistant is live, monitor:
- whether readers are using it
- which pages generate the most assistant activity
- whether handoff volume is high
- whether low-confidence behavior reveals content gaps
Use those signals to improve both the assistant configuration and the documentation itself.