Live Chat is AIUNIFY PROS SUITE’s RAG-powered support-agent workspace for creating an AI assistant that answers questions from a subscriber-controlled Knowledge Base.
The current interface identifies the workspace as:
Live Chat Support
and displays the badge:
RAG Powered
with the description:
“Train your AI assistant with your documents. Get accurate, grounded responses based only on your uploaded content.”
Live Chat currently provides subscriber-facing workflows for:
The operating concept is:
Add Business Knowledge → Index It → Test the AI → Embed the Support Widget
Navigate to:
Sidebar → Core Tools → Live Chat
The current route is:
/support-agent
and the Sidebar marks Live Chat as a New Core Tool.
PROS SUITE contains both:
/support-agent
Designed around:
/chat
Designed as the general PROS SUITE conversational AI workspace.
The Sidebar presents them as separate Core Tools.
AI Voice Agent is the dedicated voice interaction system.
Live Chat is currently a text/image-based RAG support interface.
Do not expect Live Chat to provide the microphone/voice-session workflow of AI Voice Agent.
Within this PROS SUITE manual, Live Chat means the RAG-powered support-agent builder at /support-agent.
It should not be confused with AIUNIFY’s separate Chat product/system. This chapter covers only the subscriber controls verified inside AIUNIFY PROS SUITE.
The interface prominently labels Live Chat:
RAG Powered.
RAG means the assistant is designed to answer by retrieving relevant information from indexed Knowledge Base content and using that information when producing its response.
For the subscriber, the practical model is:
Your Content
↓
Indexing
↓
Relevant Knowledge Retrieved
↓
AI Response
Unlike a general AI Chat tool, Live Chat is specifically designed around content you add.
The interface's own four-step explanation is:
The current Live Chat page contains several major areas:
Live Chat Support / RAG Powered
At the top of the workspace are four status Cards:
Documents displays the total number of currently loaded Knowledge Base document entries.
It is calculated from the current document list.
Indexed counts documents whose current status is:
completed.
These are represented in the document list using the visible label:
Indexed.
Processing counts Knowledge Base entries that are still being processed/indexed.
Errors counts document entries whose current status is:
error.
Use this as a quick indicator that one or more Knowledge Base entries require attention.
The primary content-management Card is titled:
Knowledge Base
with:
“Upload documents to train your support agent”.
Knowledge Base currently provides two tabs:
Upload a supported document.
Provide a website URL for indexing.
Select:
File Upload
to add a document from your device.
The upload area displays:
“Drop files here or click to upload”.
The current file selector accepts:
.pdf.docx.txtThe interface states:
“PDF, DOCX, or TXT • Max 10MB per file”.
The current Knowledge Base upload control does not establish support for:
as Knowledge Base document uploads.
Use PDF, DOCX, or TXT for the current verified workflow.
The visible interface states:
Max 10MB per file.
The backend upload handler is outside the sanitized source bundle, so this manual treats 10 MB as the current UI limit rather than independently auditing server enforcement.
The current file input does not use a multiple-file selection attribute, and the upload handler retrieves the first selected file.
For predictable operation:
Upload documents one at a time.
Useful support Knowledge Base content can include:
Only upload content that is appropriate for the assistant to use when answering users.
To add a document:
When an upload begins, Live Chat displays:
Uploading and indexing document...
The workflow therefore combines document submission with Knowledge Base indexing.
If the upload/index operation succeeds, Live Chat displays:
Document indexed successfully!
It then refreshes the document list.
If a document is still marked:
Processing
allow indexing to complete before relying on it for support answers.
For best results, test after the content is marked:
Indexed.
When the upload process reports a problem, the Knowledge Base area can display:
Upload Failed
followed by the current error.
The current upload workflow can also display:
Upload failed
when the operation is rejected.
Review the displayed error before retrying.
One source-defined error condition displays:
Database setup required.
The underlying UI may include technical setup wording, but ordinary subscribers should not attempt backend/database administration as part of this User Operations Manual.
If you encounter this error:
Contact the appropriate AIUNIFY support or system administrator.
Knowledge Base also provides:
URL Import.
Use this when the information you want indexed is available on a website.
Inside URL Import, the interface displays:
Train from URL
and:
“Enter a website URL to crawl and index its content”.
The URL field displays:
https://example.com/docs.
Before starting URL training, the current client checks that the value starts with:
http://https://Otherwise it displays:
“Please enter a valid URL starting with http:// or https://”.
After entering the URL, select:
Train.
During URL Import, Live Chat displays:
Scraping and indexing website...
When URL Import succeeds, Live Chat displays:
Website indexed successfully!
The URL field is cleared and the document/knowledge list is refreshed.
If the URL operation fails, the interface can display:
Import failed
and the returned Error.
The interface describes URL Import as crawling and indexing website content.
However, the actual document/API crawler implementation was excluded from the sanitized User Operations bundle.
Therefore, this manual does not claim a specific:
for URL Import.
Test the resulting Agent against the content you need.
Start with the most authoritative URL possible.
For example:
https://yourcompany.com/help
may be more useful for support than a broad marketing homepage if your help center contains the answers customers actually need.
Before importing a URL, confirm that its content:
Outdated website information can produce outdated support answers.
Below the upload/import controls is:
Your Documents.
This is the current Knowledge Base content list.
The heading displays:
[number] total.
If the Knowledge Base is empty, Live Chat displays:
No documents yet
and:
“Upload your first document to get started”.
Each document entry displays:
The current list formats creation dates in a form such as:
Aug 19, 2026.
A completed document displays:
Indexed
with a Check indicator.
An in-progress document displays:
Processing.
A failed document entry displays:
Error.
The Knowledge Base header contains a Refresh control that reruns the document retrieval process.
Use it if a Processing status appears unchanged after sufficient time.
Each document entry contains a Trash/Delete button.
Selecting it opens a confirmation dialog.
The dialog states:
Are you sure?
and:
“This action cannot be undone. This will permanently delete the document from your knowledge base.”
Select:
Cancel
to leave the document in the Knowledge Base.
Select:
Delete
to proceed with permanent removal.
When deletion succeeds, Live Chat displays:
Document deleted.
The document is then removed from the displayed list.
If deletion fails, the interface displays the returned Error or:
Delete failed.
A failed document deletion request can also display:
Network error.
Do not assume the document was deleted if an error appears.
Removing a Knowledge Base document is not just file cleanup.
Because Live Chat is designed to answer from indexed Knowledge, removing a source can affect what information remains available to future Chat responses.
Review dependencies before deleting important support content.
The current document list does not establish an:
control.
If source information changes, the safest current workflow is generally to remove outdated content and upload/import the updated source.
The current Live Chat source does not establish:
inside Your Documents.
The current Knowledge Base list does not provide a subscriber-facing search box for finding a document by Name or content.
The right-side testing Card is titled:
Test Your Agent.
Its description states:
“Launch the preview to test how your AI responds to questions based on your uploaded documents.”
Select:
Launch Preview.
This enables the floating Live Chat test widget.
The Preview uses the same ChatWidget component as the embedded experience.
In non-embedded mode, the widget initially appears as a floating teal Message button near the bottom-right of the screen.
Select that button to open the Chat window.
Once Preview has been enabled, the Test Your Agent button changes to:
Close Preview.
Use this to remove the Preview component from the Live Chat page.
These controls are slightly different.
Closes/minimizes the currently open non-embedded widget back to the floating Chat button.
Removes the Preview widget from the page.
The Test Your Agent Card displays:
These are descriptive product-interface labels for the support experience.
When opened, the widget displays:
Live Support.
Under Live Support, the Chat header displays:
Powered by [site name]
and falls back to:
AI Suite
if another site Name is not configured.
A new ChatWidget session begins with:
“Hello! I'm your Live Support Assistant. How can I help you today based on our documents?”
An embedded support-context version can additionally identify a Support Mode.
The Chat input displays:
Type your message...
To test the assistant:
The Chat input is inside a standard form.
Pressing:
Enter
submits the current message.
The interface does not establish a multiline text-area workflow for this Chat input.
The Send control uses a Send-arrow icon.
It is disabled when:
While waiting for the support response, Live Chat displays:
Assistant is thinking...
As new messages are added, the current Chat widget automatically scrolls toward the latest content.
User messages appear as teal message bubbles on the user side of the conversation.
Assistant replies appear using the AI-side message styling and are rendered through the PROS SUITE:
MarkdownRenderer.
This allows support answers to contain structured formatting where the response provides it.
The Live Support input also contains a Paperclip attachment control.
The current verified attachment type is:
image.
The Chat attachment input accepts:
image/*.
It does not establish Chat attachments for PDF, DOCX, ZIP, or other documents.
Those belong in the Knowledge Base upload workflow.
The current ChatWidget rejects images larger than:
5 MB.
If the image exceeds 5 MB, the exact current message is:
“Please upload an image smaller than 5MB.”
After selecting an image, a thumbnail Preview appears above the Chat input.
Select the small X on the image Preview to remove it before sending.
You can enter a question and attach an image before sending.
The Chat request includes both:
when present.
The current Send logic permits submission when:
However, adding a brief written question usually makes the intended support task clearer.
A useful workflow is:
Based on our support documentation, what should the customer do next?When an image is sent, the Chat bubble displays the shared image above the user's message.
For every submitted Chat message, the current widget sends:
to the RAG Chat service.
The current ChatWidget displays previous messages in the interface, but the request sent for each new answer contains only the current Prompt, optional support context, and optional image.
The current client request does not submit the visible previous message array with each new question.
Therefore:
Do not rely on source-verified conversational memory across previous Live Chat turns.
Instead of:
What about the second option?
prefer:
Regarding the annual Enterprise plan described in our pricing document, what does the second support option include?
This makes the question more self-contained.
Although prior messages are not source-verified as being sent back on every request, they remain visible to the user while the ChatWidget stays mounted.
This helps you visually compare questions and answers during testing.
The message list exists in the ChatWidget's current component state.
The source does not establish:
for Live Chat.
When the non-embedded Preview widget is merely minimized with its X, the component remains mounted.
Its current message state can therefore remain visible when reopened during that same mounted page session.
Selecting:
Close Preview
removes the ChatWidget component from the Live Chat page.
Launching a newly mounted Preview creates a new widget state beginning with its initial greeting.
Because no persistent Live Chat conversation-storage source is established, do not rely on the current visible test conversation surviving a page refresh.
The current widget does not contain a dedicated:
New Chat
control.
For testing a fresh session, Close Preview and relaunch it or reload as appropriate.
There is no source-verified:
control inside the current Live Support widget.
The Live Support widget does not currently establish a dedicated:
Copy Answer
control.
This differs from Browser Control and some other PROS SUITE workspaces.
The current Live Chat source does not provide:
for a Chat session.
The current ChatWidget does not establish:
controls.
If the Chat service returns an Error, the assistant places a message into the conversation formatted as:
Error: [error].
If the Chat request itself fails, the assistant displays:
“Sorry, I had trouble connecting to the support server.”
A successful technical response does not automatically mean the answer is correct.
For each important support category, test:
and compare the answer with the original indexed source.
The interface describes the support agent as:
Grounded
and says responses are based on indexed content.
However, the final wording is still AI-generated.
Verify high-impact answers before deploying them broadly to customers.
RAG quality depends heavily on source quality.
Avoid mixing:
unless you intentionally want all of them available.
If a product manual is replaced:
Do not move directly from upload to public deployment.
Use:
Test Your Agent → Launch Preview
first.
Test at least:
This helps reveal gaps.
Ask the Agent something that is deliberately not contained in your Knowledge Base.
This helps you understand how the deployed assistant behaves when it lacks supporting information.
Below Knowledge Base is:
Embed on Your Website
with:
“Add this script before </body>”.
Live Chat automatically builds an embed snippet using the current PROS SUITE origin.
Its structure is:
<script src="[PROS SUITE origin]/chat-widget-embed.js" data-site-url="[PROS SUITE origin]"></script>
The live page fills the actual origin automatically.
Use the code shown in your own Live Chat workspace.
Do not manually substitute domains unless your implementation specifically requires it.
Hover over the code block and select:
Copy.
After copying, Live Chat displays:
Embed code copied!
The interface instructs:
“Add this script before </body>”.
Conceptually:
Use your website's normal safe method for adding a script before its closing body tag.
If adding the widget manually to a production website:
The source contains a dedicated standalone ChatWidget page that renders the widget in:
embedded mode.
This is the browser-side presentation intended to support embedded Chat operation.
Unlike the floating internal Preview—which initially renders a button—the embedded=true version renders the full Chat panel directly.
When the embedded Chat's X is selected, it sends a browser message to its parent page requesting:
close-chat-widget.
The surrounding embed script is expected to determine how that parent interaction is handled.
The user-facing page references:
chat-widget-embed.js
but the sanitized manual source bundle does not contain that script's implementation.
Therefore, this manual can verify:
but not every implementation detail of the external loader script.
After deployment, test:
The middleware source explicitly treats:
/api/chat/rag
as an API path that does not require the normal authenticated session.
That is consistent with an externally used support Chat service.
However, the same middleware's current public page list does not explicitly include:
/chat-widget.
Because the external embed-loader implementation is also absent from the sanitized bundle, this manual cannot source-verify that an unauthenticated website visitor can always reach the standalone widget in the current deployment.
Therefore:
Test the embedded widget in a logged-out/private browser before considering deployment complete.
An owner can see a working widget while signed into PROS SUITE, yet a customer may visit the website without any PROS SUITE session.
Public deployment should therefore be verified using:
If the embedded widget unexpectedly redirects an external visitor to the AIUNIFY Login page, this is not a Knowledge Base problem.
It indicates a deployment/access-routing issue that should be corrected by the appropriate AIUNIFY technical administrator.
Subscribers should not attempt middleware/server changes through this User Operations workflow.
The standalone ChatWidget route can read an optional parameter named:
supportEmail.
That value is passed into the embedded ChatWidget.
If a supportEmail value exists, the initial greeting includes:
“(Support Mode: [supportEmail])”.
The current Chat request sends the optional supportEmail along with:
The in-dashboard Test Your Agent Preview renders:
<ChatWidget />
without a supportEmail value.
Therefore its greeting does not display Support Mode.
The current subscriber-visible embed code contains:
data-site-urlbut no visible supportEmail attribute.
Because the embed-loader script is outside the bundle, this manual does not invent how account-specific Knowledge Base routing is derived in the final external widget.
If multiple companies/users have separate Knowledge Bases, test that an external widget returns the correct organization's information.
This is especially important because the account-routing behavior of the omitted embed loader/RAG backend cannot be fully verified from this user-only bundle.
The generic PROS SUITE feature catalogue currently lists:
Live Chat — 10 Tokens.
The Live Chat client does not:
10 tokens per useThe actual /api/chat/rag implementation is outside the sanitized source bundle.
Therefore:
The generic 10-Token catalogue entry is not sufficient to prove the exact live per-message charge.
The shared PROS SUITE FeatureGuard source specifically classifies:
support-agent
as a:
basic tool
alongside Dashboard when evaluating Plan scope.
This creates an additional reason not to infer a simple 10-Tokens-per-message billing rule from the generic feature catalogue alone.
The current Live Chat page does not show:
inside the ChatWidget.
Use the normal PROS SUITE Monthly Tokens display for general account monitoring.
Because the server-side /api/chat/rag implementation was intentionally excluded from the User Operations bundle, this manual does not claim:
Those rules require server-side/current-account verification.
The Live Chat client sends:
but does not send the shared PROS SUITE selectedModel.
Therefore:
The source does not verify that changing the Header AI Model changes the RAG Live Chat Model.
The Live Chat page itself does not expose an:
AI Model
selector.
Model behavior appears to be handled by the RAG service rather than selected inside this subscriber workspace.
There is no Gemini/OpenAI/Anthropic/etc. provider-key field inside Live Chat.
Those general AI settings should not be confused with this support-agent Knowledge Base interface.
For subscriber operations, the Live Chat feature should be understood as:
RAG SUPPORT AGENT BUILDER
rather than merely:
a Chat box.
Its main value comes from controlling the Knowledge Base and deploying the trained support experience.
LIVE CHAT
↓
KNOWLEDGE BASE
↓
Choose:
FILE UPLOAD
or:
URL IMPORT
↓
Wait for:
INDEXED
↓
Review:
DOCUMENTS / INDEXED / PROCESSING / ERRORS
↓
TEST YOUR AGENT
↓
LAUNCH PREVIEW
↓
Ask representative customer questions
↓
Correct Knowledge Base gaps
↓
Retest
↓
EMBED ON YOUR WEBSITE
When support information changes:
ADD UPDATED SOURCE
↓
Wait for:
INDEXED
↓
Test updated question
↓
Verify correct answer
↓
Remove outdated conflicting source
↓
Retest
This reduces the risk of Knowledge Base contradictions.
Test:
What does the Professional Plan include?
Then compare the answer with the indexed pricing documentation.
A customer cannot complete Step 3 of the onboarding process. Based on our support manual, what should they check first?
What does our refund policy say about cancellations after 30 days?
Only deploy the answer if the correct policy source has been indexed.
Ask:
What is our office location in Tokyo?
when no such information exists in the Knowledge Base.
Observe how the assistant handles an unsupported question.
A support Agent performs better when its source content is:
A vague internal draft can produce vague support responses.
Names such as:
Enterprise_Onboarding_Guide_2026.pdf
are easier to manage than:
document-final-3.pdf.
The current interface displays the file Name directly in Your Documents.
Do not leave:
all active if they contain contradictory information.
Maintain one authoritative current version where practical.
Only add content appropriate for the support use case.
Do not casually upload:
to a Knowledge Base intended to support external users.
Before embedding publicly, test:
If customers may make decisions based on the answer, accuracy matters.
Because visible previous messages are not submitted as Chat history by the current client, phrase each important question so it can stand on its own.
Internal Preview proves the ChatWidget works while you are inside PROS SUITE.
It does not prove that an unauthenticated visitor can use the external widget.
Always test the actual website separately.
The non-embedded widget uses responsive sizing for smaller screens.
After embedding, test:
and verify that the widget does not cover important website controls.
Because the embedded widget communicates its Close request to the parent page, verify the final embed-loader behavior after deployment.
Knowledge Base modifications can change support behavior.
After:
important content, rerun representative questions.
Check:
The current file picker accepts only:
.pdf,.docx,.txt.
Convert unsupported content to an accepted format if appropriate.
Processing means the content is not yet in the completed Indexed state.
Use the Refresh control and wait for:
Indexed
before relying on it.
Review the displayed upload Error.
If it references system/database setup rather than your file, contact AIUNIFY support instead of attempting backend changes.
The URL must begin with:
http://
or:
https://.
The URL Import Train button is disabled while:
Possible user-level checks include:
Because crawl depth is not source-verified, do not assume every linked page was automatically indexed.
Check whether an outdated document or URL content remains in the Knowledge Base.
Remove obsolete sources after the replacement content is Indexed.
Look for:
Simplify the Knowledge Base so the authoritative information is clear.
Launch Preview first mounts the floating ChatWidget.
You may then need to select the floating teal Chat button in the lower-right corner to open it.
That is expected in the non-embedded Preview.
Use the page-level:
Close Preview
to fully remove the Preview.
Wait for the current request to complete.
The Send and Paperclip controls are disabled from starting another request while the current answer is loading.
The current request does not include the preceding messages.
Rewrite the follow-up as a complete question containing the necessary context.
The current Chat attachment limit is:
5 MB.
Use a smaller image.
PDF files belong in:
Knowledge Base → File Upload
The current Chat Paperclip accepts images, not PDFs.
If the widget displays:
“Sorry, I had trouble connecting to the support server.”
the Chat request itself could not complete.
Retry after confirming your connection and service availability.
This means the RAG service returned an Error payload.
Review the actual Error text before changing your Knowledge Base.
Use the exact code displayed under:
Embed on Your Website.
If the referenced script cannot load from the live PROS SUITE domain, the issue requires technical/deployment review rather than changing Knowledge Base content.
Test while logged out.
The source's current public-path configuration does not explicitly list /chat-widget, so a login redirect would be consistent with an access-routing problem that needs technical correction.
Test using:
This helps separate your authenticated PROS SUITE session from actual public visitor behavior.
If multiple support Knowledge Bases exist, verify the deployed widget is being routed to the correct account/support context.
The omitted embed-loader/backend source prevents this manual from guaranteeing the exact mapping mechanism.
Live Chat currently has no subscriber-facing Model selector.
Changing the general Header Model is not source-verified to affect Live Chat because its requests do not submit selectedModel.
Live Chat does not display a current per-message Token cost.
The generic catalogue contains 10 Tokens, but exact RAG-service billing is not established in this sanitized source.
Before embedding:
After embedding:
Periodically review:
The source verifies subscriber-facing capabilities for:
The supplied subscriber-facing source does not establish:
/chat-widget access in the current middlewareThese should not be described as active subscriber features unless a future release/source establishes them.
Several details deserve particular attention.
The product is explicitly designed around indexed subscriber Knowledge.
Subscribers can use:
The Chat itself accepts images up to 5 MB.
Each Chat request sends the current Prompt/image/support context but not the visible prior-message array.
Documents are loaded from the Knowledge Base service, while Chat messages exist only in the current widget state.
The embed feature is visible and the standalone widget exists, but /chat-widget is not explicitly listed as a public page in the current middleware source.
The current user workflow is:
LIVE CHAT SUPPORT
↓
KNOWLEDGE BASE
↓
Choose:
FILE UPLOAD
or:
URL IMPORT
↓
Content moves through:
PROCESSING
↓
INDEXED
↓
Review:
DOCUMENTS
INDEXED
PROCESSING
ERRORS
↓
TEST YOUR AGENT
↓
LAUNCH PREVIEW
↓
Click floating Chat button
↓
LIVE SUPPORT
↓
Ask:
TYPE YOUR MESSAGE...
or attach:
IMAGE
↓
ASSISTANT IS THINKING...
↓
Review grounded response
↓
Repeat testing
↓
EMBED ON YOUR WEBSITE
↓
COPY
↓
Add script before:
</body>
↓
Test website as a logged-out visitor
↓
Maintain Knowledge Base over time
AIUNIFY PROS SUITE Live Chat is a RAG-powered support-agent builder rather than simply another general-purpose Chat interface.
The workspace identifies itself as:
Live Chat Support
and tells subscribers:
“Train your AI assistant with your documents. Get accurate, grounded responses based only on your uploaded content.”
The Knowledge Base supports:
with the current file interface accepting:
and displaying:
“Max 10MB per file.”
Subscribers can monitor:
and manage individual Knowledge Base entries through the Your Documents list.
A completed document displays:
Indexed
while a failed entry displays:
Error. Documents can be permanently removed after the confirmation:
“This action cannot be undone. This will permanently delete the document from your knowledge base.”
To test the RAG assistant, use:
Test Your Agent → Launch Preview
and then open the floating Chat button. The widget identifies itself as:
Live Support
and begins with:
“Hello! I'm your Live Support Assistant. How can I help you today based on our documents?”
Users can submit:
and the assistant renders its response using Markdown.
An important current limitation is that each request sends the current Prompt, optional support context, and optional image—but not the visible previous Chat-message array. Accordingly, multi-turn contextual memory should not be assumed.
Live Chat also provides:
Embed on Your Website
and tells subscribers to add the generated script before:
</body>.
The source contains a standalone embedded ChatWidget and a public exception for the RAG API. However, the middleware's current public-page list does not explicitly include /chat-widget, and the external chat-widget-embed.js implementation was not part of the sanitized bundle. Therefore, the correct deployment practice is to test the widget while logged out before declaring it customer-ready.
Finally, although the generic feature catalogue lists Live Chat at 10 Tokens, the actual RAG endpoint's billing logic is outside the user-operations source, the Chat interface shows no per-message cost, and shared access logic treats support-agent as a basic Tool. The manual therefore does not claim a fixed 10-Token charge for every Live Chat message.
The recommended operating principle is:
Build a Clean Knowledge Base → Wait for Indexing → Test the Agent Thoroughly → Correct Knowledge Gaps → Embed the Widget → Test as an External Visitor → Maintain the Knowledge Base as Your Business Changes.