Support Chat Administration
Audience: System Admin, Org Admin Related: Support Chat · AI in Blackcap · Data Retention and Purge · Support Requests
Support Chat is the support_chat AI use case. It supersedes the older disabled support_assistance placeholder use case, which is removed by migration. It uses the same provider-independent AI configuration architecture as other Blackcap AI features, while keeping human Support Request as the escalation path.
AI Configuration
A System Admin configures Support Chat in Configuration → Platform → AI. The quality profile controls:
- provider connection and compatible model;
- maximum input characters and output tokens;
- bounded chat-history window;
- documentation result count and total retrieved characters;
- maximum Support Chat turns;
- provider timeout;
- reasoning/thinking level where supported.
OpenAI and Gemini are both supported through the shared adapter layer. The final provider/model is a platform choice; Blackcap does not hard-code a benchmark winner.
AI Seed policy
Support Chat is usage tracked / no AI Seed charge in the initial release. A Support Chat profile always charges 0 AI Seeds, does not reserve a balance, and is not blocked by a user or organization's AI Seed balance. Provider token usage, latency, model, connection, and estimated provider cost are still recorded.
The profile data model retains the normal price field so a future release can introduce Support Chat AI Seed pricing without redesigning the feature.
AI Usage and transcript access
Support Chat appears as its own use case in Administration → AI Usage. AI Usage uses a right-anchored Actions column for row actions. Support Chat rows show the 🛟 View support chat action there while the transcript is retained. This keeps the column extensible for future AI Usage actions. After purge the action is disabled with Chat history has been purged; the usage row remains.
System Admins can view transcript history across their authorized platform scope. Org Admins with AI Usage permission can view Support Chat history only for organizations they administer. Cross-organization transcript IDs are rejected. Normal users do not gain access to the AI Usage page; their own active conversation remains available through Get Help.
System Admin provider diagnostics include input/output tokens, cached-input tokens when available, reasoning/thinking tokens when available, latency, and an estimated provider cost based on the versioned pricing snapshot. Estimated cost is operational guidance rather than invoice-accurate billing.
Retention and Data Cleanup
The Support Chat use-case retention setting defaults to 7 days and is labeled Support Chat History Retention. Terminal sessions receive a purge timestamp based on that retention. Active, waiting-for-user, waiting-for-AI, and escalation-offered sessions are protected.
Administration → Data Cleanup → Support Chat History shows terminal session metadata and message/source counts without revealing transcript content. Authorized users can preview and delete terminal sessions early. Cleanup deletes message/source history, clears retained support-context snapshots, and leaves a small purged session shell so AI Usage correlation can report that the transcript expired.
Human escalation
Support Request configuration remains independent. If a user escalates from Support Chat, the server verifies session ownership and Active Organization before copying the visible conversation and trusted documentation sources into the support-team email. The browser does not submit an arbitrary transcript.
The Support Request itself remains the authoritative human-support record and can outlive the seven-day Support Chat transcript retention according to its existing retention behavior.
Privacy and diagnostics
Support Chat reuses the existing Support Context collector, then applies a stricter AI-safe allowlist before sending context to an external provider. Page URLs sent to AI omit query strings and fragments. Field values are not included; only safe labels/types/names are supplied. Common credential-like values in error text are redacted.
Operational logs may identify session/message IDs, organization, provider/model, duration, token counts, retrieval duration, source count, and outcome. They should not log full transcripts, documentation chunks, credentials, or hidden prompts.
For structured-output failures, Blackcap records safe provider diagnostics such as response/finish status, incomplete reason, output character count, and JSON parse line/column when available. A max_output_tokens incomplete response is reported separately from malformed JSON so an administrator can distinguish an output-budget problem from a provider-formatting problem without logging the response text.