This guide sets up support escalation from your documentation site. It covers provider connection, activation, ticket routing, and how to make the support experi...
This guide sets up support escalation from your documentation site. It covers provider connection, activation, ticket routing, and how to make the support experi...
This guide sets up support escalation from your documentation site. It covers provider connection, activation, ticket routing, and how to make the support experience work cleanly alongside the assistant and contact flows.
Who this is for
- support teams using Doxbrix as part of a self-service support strategy
- documentation teams that want unresolved reader questions to become actionable tickets
- admins responsible for integrating a helpdesk with the docs experience
What the Support & Ticketing section does
In Project settings → Support & Ticketing, Doxbrix lets you:
- enable or disable support entry points on the docs site
- connect one or more support systems
- choose the active connection
- control whether readers can create tickets from the contact form
- control whether the assistant can escalate or draft tickets
- map categories or routing values where the provider supports them
The section is designed so documentation does not just stop at “contact support.” It creates a real operational path when self-service is not enough.
Supported provider types
The product code shows support for several provider classes, including helpdesk platforms, webhook-based routing, and email-based fallback.
Use a full helpdesk integration when:
- you already run a ticket platform
- you need status, ownership, and routing in the support system
- you want assistant escalations to land in an operational queue
Use webhook or email fallback only when you do not yet have a more structured integration path.
Step 1 — Turn on Support & Ticketing
Open Project settings, then go to Support & Ticketing.
At the top of the section, turn on Support & Ticketing so the documentation site and assistant can use the configured support flow.
When this master switch is off:
- the contact support page and related buttons are hidden
- the assistant cannot escalate or create tickets
- existing connections remain configured but inactive
Step 2 — Choose the provider you actually operate
In the provider gallery, select the support system your team already works in. The form generated by Doxbrix changes based on the provider, so only configure one you intend to maintain.
When choosing, ask:
- is this where agents already work?
- can this system handle the volume the docs site may create?
- does the team know how to triage tickets created from docs and assistant flows?
Step 3 — Create the connection
Click the provider in the gallery so Doxbrix loads the correct connector form.
Give the connection a clear operational name, especially if you expect to have more than one configured later.
Complete the provider-specific form fields. Doxbrix marks required values and blocks incomplete setup.
Save the connection through the connection action in the support setup flow.
After creation, the connection appears in the project-level list of configured support targets.
Step 4 — Activate the connection and define its role
Once the provider is connected, review:
- whether it should be the active support target
- whether it should allow form-created tickets
- whether it should allow assistant-created tickets
Use this deliberately. Some teams want the contact form enabled before they let the assistant generate escalations automatically.
Step 5 — Configure categories or routing
Where the provider supports routing fields, use categories or routing values to keep docs-generated tickets from mixing invisibly into general support queues.
Good routing patterns include:
- a separate documentation queue
- a dedicated “knowledge gap” or “self-service escalation” tag
- categories for account, billing, integration, or authentication issues
This is important because documentation-driven tickets often behave differently from normal inbound tickets. They may indicate missing articles, weak onboarding, or assistant coverage gaps rather than one-off product bugs.
Step 6 — Connect support to the assistant experience
If you are also using the reader assistant:
- confirm that Support & Ticketing is enabled
- confirm the assistant’s help button path is aligned with the support configuration
- make sure assistant escalations land in the same support system you intend the team to monitor
This prevents a broken experience where the assistant promises escalation but the docs project does not actually have a working ticket path.
Step 7 — Test the escalation flow
Run a full support test before launch:
Submit a reader-style support request and confirm it arrives in the support system with the expected routing and metadata.
Trigger an unresolved assistant question and verify that the handoff creates or routes the ticket correctly.
Confirm that support agents can tell the request came from documentation and have enough context to act without asking the reader to restate the issue.
Step 8 — Use support tickets to improve the docs
Once the integration is live, do not treat docs-generated tickets as pure support throughput. Treat them as documentation signals.
Look for:
- repeated tickets from the same page or flow
- assistant escalations around the same topic
- routing categories that spike after releases
- questions that clearly indicate missing or confusing content
That feedback should feed directly into your docs improvement process.