Frequently Asked Questions

RTD is a website conversation and business-operation product that brings Voice, Chat, approved company information, visitor intent, lead creation, Human Inbox continuation, transcripts, recordings, website deployment, and operating controls into one connected workspace. The website Agent responds from an approved business profile and remains connected to the Voice Dashboard, where the business can review activity, outcomes, usage, domains, publication status, and account controls.

RTD Studio is where the business profile is prepared, reviewed, approved, and published. It defines what the Agent is permitted to communicate about the company, its services, processes, policies, routes, and business information.

The Voice Dashboard is the operating workspace used after setup. It shows live and previous conversations, leads, Human Inbox cases, transcripts, recordings, Domain Agents, Website Audit results, usage, credits, Support Messages, team access, and settings.

The business-facing experience is built around the approved RTD profile and the information authorized for that Domain Agent. The purpose is to keep responses aligned with the company’s approved services, terminology, policies, processes, and visitor routes.

Changes to important business information should be reviewed and published through RTD Studio so the live Agent continues to reflect the approved company position.

Yes. A Domain Agent can provide Voice, Chat, or both, depending on the selected plan, published configuration, website experience, and enabled channels.

Both channels remain connected to the same approved business profile and operating workspace, allowing the team to review visitor intent, conversation context, actions, outcomes, and usage without separating the business record.

The interaction can continue through Human Inbox when the request is sensitive, uncertain, qualified, account-specific, or requires an authorized company officer. The officer receives the available conversation context, including visitor intent, previous messages, the Agent’s summary, routing destination, and relevant contact details.

The case can then be accepted, assigned, replied to, noted internally, resolved, closed, or returned to the Agent.

When a visitor expresses qualified intent and provides appropriate contact details or permission, RTD can create a visible lead record connected to the original conversation. The lead can contain contact information, project or service interest, qualification answers, conversation context, source channel, Domain Agent, assignment, status, notes, and follow-up history.

This allows the business to move from conversation to accountable sales work.

A Domain Agent is the approved RTD operation assigned to a specific website or domain. It connects that website to its published profile, enabled channels, language coverage, deployment method, connection status, usage, and recent activity.

Businesses operating multiple approved websites can manage those Agents separately while keeping them inside the same protected workspace and shared account structure.

RTD can be deployed as a Premium iframe, Floating Agent, Button Agent, JavaScript SDK integration, or protected Hosted Agent page. These methods give the website team control over how and where the visitor experience appears.

A business can also use Dashboard Platform Settings for supported managed connections. The selected route remains tied to the approved Domain Agent and its publication controls.

Deploying means placing the Agent through a supplied website format such as an iframe, floating launcher, existing button, SDK, or hosted destination. Connecting means authorizing a supported website platform through Dashboard Platform Settings.

That route can handle platform authorization, configuration, verification, connection status, and managed installation from the protected workspace.

The product experience presented here supports managed connection routes for WordPress, Shopify, Wix, Squarespace, Webflow, and Google Tag Manager. The available authorization and installation steps can differ by platform.

Connection status, domain verification, selected Domain Agent, deployment format, and publication readiness remain visible through Dashboard Platform Settings.

Eligible Voice, Chat, and Human Inbox activity uses credits from the workspace’s shared prepaid wallet. The Dashboard shows the available balance, usage by channel, monthly credit delivery, top-ups, transaction history, and estimated remaining activity.

Actual consumption depends on the active product channel and the applicable plan rate. The pricing and usage areas should be used for the current allowance, included features, and credit terms.

Conversation transcripts remain connected to the relevant conversation record when available under the product operation. Audio recordings are separate and appear only when recording is enabled for the plan, Domain Agent, and applicable conversation.

The business should configure recording and retention according to its operational requirements, customer communications, applicable permissions, and account controls.

Website Audit provides a structured view of website readiness, visible business risks, category scores, findings, supporting evidence, affected pages, recommendations, and audit history. It helps the business understand whether the website clearly supports visitor pathways, company positioning, trust, support, conversion, and the wider RTD operation.

It does not automatically replace business review or implementation decisions.

The workspace is designed to keep Agent status, profile version, domain state, connection, installation, and publication controls visible after launch. An authorized user can review the relevant configuration, update approved business information through RTD Studio, verify the website route, and publish the appropriate version.

Availability can also be controlled when the business does not want the Agent accepting new conversations.

The current RTD Dashboard guide describes one universal rtd-agent.js loader. The server-side Site ID, verified origin, plan entitlement, selected model, published profile, wallet, recording policy, and feature state determine how that loader behaves.

What this step does: Confirms that this setup belongs to you and connects it to the correct website. What to enter The activation code from your WebsDocs email.

The same email address used for the purchase or approval. Your main website address, for example https://company.com .

Helpful notes Use the real public website whenever possible. For local testing, enter the exact localhost address and port you will use.

The first approved website becomes the primary Agent domain. Next: WebsDocs sends a short verification code to the registered email.

What this step does: Confirms that the person completing setup can access the registered email account. What to do Select Send verification code .

Open the email from WebsDocs. Enter the 6-digit code in Studio.

Helpful notes The code is temporary and expires after a short time. Check the spam or junk folder when the message does not arrive.

Never share the activation code or verification code with another person. Next: Create the password used to sign in to the Voice Dashboard.

What this step does: Creates the owner login for the Voice Dashboard. Password guidance Use at least 10 characters.

Include at least one letter and one number. Use a password that is not used on another website.

Do not use your activation code or email verification code as the password. The password is protected before storage.

WebsDocs does not return the original password after setup. Next: Add the public business information visitors should see and hear.

What this step does: Tells the Agent which company it represents. What to enter Company name: the public name customers recognize.

Agent name: the name visitors will see and hear. Industry and business type: a simple description of your work.

Tagline: one short sentence about your value. Business summary: what you do, who you help, and what makes your service useful.

Write for a customer, not for an internal technical team. Use only information approved for public use.

What this step does: Gives visitors accurate ways to contact the company and understand when help is available. Recommended information Public email and phone number.

Business hours and timezone. Service areas or locations.

Contact, support, and booking pages. A realistic response-time message.

Only enter contact details that customers are allowed to use.

What this step does: Controls the opening greeting, voice, tone, and length of spoken answers. Simple setup advice Use a short greeting that says who the Agent represents.

Choose a warm, clear, and professional style. Keep spoken answers brief so visitors can respond naturally.

Use the fallback message when the Agent does not have approved information. The Agent should explain approved information, not make legal, financial, or custom commercial promises.

What this step does: Makes the hosted page and website widget match your company. Images Company logo: used beside the company name and inside supported Agent views.

Banner: shown as a clear, wide image on the hosted Agent page. Agent avatar: optional image for the assistant.

The RTD default avatar is used when empty. Colors and position Choose readable colors with good contrast.

Select bottom-left or bottom-right for the website launcher. Use the preview to check the greeting, avatar, and panel appearance.

Images are uploaded securely when the final workspace is created. For a sharp full-width banner, use a wide, high-resolution image.

What this step does: Gives the Agent a clear list of services it is allowed to explain. For each service Use the public service name.

Add a short, customer-friendly description. Explain who the service is for and the usual next step.

Do not add private internal services, unapproved claims, or details that change frequently unless your team will keep them updated.

What this step does: Lets the Agent explain approved products, packages, or offers. Safe commercial wording Enter only prices that are already public and approved.

Say “starting from” when the final price depends on customer needs. Explain that custom quotes require a team member when appropriate.

Do not allow the Agent to promise discounts, refunds, or special terms.

What this step does: Defines the approved information the Agent may rely on. What to include Important public website pages.

Short notes about services, policies, and customer questions. Priority topics the Agent should explain first.

What to exclude Admin pages, private portals, draft pages, and internal documents. Outdated information or claims the company has not approved.

When information is missing, the Agent should say so and offer a human contact option.

What this step does: Helps the Agent answer frequent customer questions consistently. Good FAQ examples What services do you provide?

Which locations do you serve? How can I request a quote or booking?

When will a team member reply? Keep each answer short, accurate, and easy to understand.

Avoid copying long website pages into one answer.

What this step does: Helps the Agent identify visitors who may want a quote, booking, consultation, or follow-up. Useful questions Which service are you interested in?

What date or timeframe are you considering? Which location or route is involved?

How should the team contact you? Ask only necessary questions.

Do not pressure visitors or collect sensitive information that the business does not need.

What this step does: Tells the Agent when and where to send a visitor who needs a person. Send to a person when The visitor asks for a custom quote, exception, refund, or legal commitment.

The question is urgent, sensitive, or outside approved information. The visitor specifically asks to speak with the team.

Choose the route Contact page for general enquiries. Support page for existing-customer help.

Booking page for appointments or consultations. Human Inbox when the plan and settings allow it.

What this step does: Selects the languages the Agent may use with visitors. Select only languages your business is comfortable supporting.

Use automatic detection when visitors may start in different languages. Use a fixed primary language when consistent communication is more important.

The number of languages available depends on the active plan.

What this step does: Sets clear boundaries for safe customer conversations. Recommended rules Tell visitors that they are speaking with an AI Voice Agent.

Explain recording or transcription only when the feature is enabled. List topics that always require a person.

Prevent promises about legal outcomes, refunds, discounts, or special terms. Add the company’s public privacy direction.

Clear boundaries make the Agent more reliable and protect both the visitor and the business.

What this step does: Controls whether conversation text and audio may be kept for the Dashboard and follow-up. Transcripts: written conversation records.

Audio recordings: actual voice recordings, available only when the plan and policy allow them. Choose settings that match your privacy notice, customer expectations, and internal retention policy.

What this step does: Shows the exact information that will be submitted for the primary website. Check before continuing Company name, summary, and public contact details are correct.

Greeting and voice style sound natural. Services, offers, and FAQs are approved.

Human handoff and safety rules are complete. Branding previews are correct.

Edit anything that is unclear or incorrect before requesting publication verification.

What this step does: Creates optional Agent versions for other approved websites under the same workspace. Each domain receives its own Domain ID, profile, hosted page, and installation code.

All domains share the same plan allowance and wallet. You may skip this step and add more domains later in the Dashboard.

Add another domain only when it genuinely needs its own website identity or tailored customer information.

What this step does: Sends a second email code to confirm the exact reviewed setup before creation. Review the primary and any additional domain Agents.

Select Send publication code . Enter the code from the registered email.

Changing the reviewed information after verification requires a new publication code. This protects the owner from accidental or unauthorized changes.

What this step does: Sends the verified setup to WebsDocs for final creation. Before selecting Create Confirm that all information is approved for customer-facing use.

Confirm the website and domain Agents are correct. Confirm the branding images and colors are correct.

Confirm the handoff, privacy, and safety rules are complete. After successful creation, WebsDocs stores the profiles, creates the domain records and hosted pages, uploads branding, prepares installation packages, and links the workspace to its plan.

What this step means: WebsDocs successfully created the Voice workspace and its approved domain Agents. What you receive Dashboard access.

A hosted Agent page for each created domain. Floating, button, iframe, and platform installation options.

Site ID and Domain ID values for each website. A protected publication handover and agreement link.

The Agent is created, but the website installation and final controlled test still need to be completed.

What this step does: Connects the created Agent to the correct website. Choose an installation type Floating Agent: adds the standard launcher to the bottom corner of the website.

Button Agent: connects the Agent to your own “Talk to us” button. Hosted Agent: opens the complete branded Agent page on its own URL.

Premium iframe: places the full hosted Agent page inside a page on your website. Platform instructions: gives placement guidance for WordPress, Shopify, Wix, Squarespace, Webflow, Google Tag Manager, or plain HTML.

Important installation rule Use the installation code created for the selected domain. Every script must contain the matching Site ID and Domain ID .

Do not copy one domain’s code to a different website. Where to place the floating script Place it once on every page where the launcher should appear.

For normal HTML, place it before the closing tag. For a website builder, use the site-wide footer or body-end custom-code area.

Premium iframe Paste the complete iframe code into the page where the hosted Agent should appear. Keep allow="microphone" so voice can work.

The hosted page sends its height to the parent page so the iframe can resize automatically. The website must be one of the approved origins for that Domain ID.

Final test checklist Open the website in a private browser window. Confirm the correct company logo, banner, colors, and Agent name appear.

Open Chat and ask a question from the approved profile. Open Speak and allow microphone access.

Test the Human Inbox or handoff route. Check the Dashboard for the conversation and wallet usage.

Need help? Copy the exact error message or take a screenshot of the browser Console and Network tabs, then send it through Setup Support.

Use the Setup Support route with the activation/setup context, the exact step, visible error, and a screenshot that excludes passwords and OTPs. Do not create another workspace simply because one protected step is delayed.

Start with the wallet, selected model, live-session count, Human Inbox and retention policy. The overview uses runtime and D1 records; it does not invent a green status when data is missing.

Complete branding, a verified domain, approved services, FAQs, a prepaid wallet and the agreement record. The readiness score links operating work rather than acting as a cosmetic score.

The plan-limit meters show current resource counts against the active plan. Limits are enforced by the Dashboard worker, not by disabled browser buttons alone.

The company logo becomes the agent avatar. The brand name and primary label appear across the customer workspace and public voice experience.

PNG, JPEG and WebP assets are uploaded through the authenticated Dashboard worker into the branding R2 bucket. Sensitive uploads require fresh verification.

The browser provides intent. D1 entitlement, verified origins, wallet balance and the Realtime worker remain authoritative for every session.

Use concise, verifiable company facts. These are intended for the runtime instruction context, not unreviewed marketing claims.

Publish approved company facts to the Dashboard Worker. The Worker writes D1 first and synchronizes the runtime KV package so Chat and Speak use the updated profile.

Services, offers, FAQs and important links each have their own D1 table and plan limit. Use the tabs to keep the approved knowledge structured.

The left list shows the current approved records and the exact used-versus-limit meter. Remove stale records rather than adding contradictory versions.

Complete the fields in the right composer. The Dashboard worker rejects additions when the plan limit has been reached.

Enter the full HTTPS website URL. Setup begins without a bound client URL, so domain ownership is handled only after verified dashboard access.

A domain is not trusted merely because it was typed into the dashboard. Use the verification action and wait for a verified state before publishing the SDK.

Pro supports 1 domain, Business 3 and Enterprise 6. The server checks the entitlement before inserting another domain.

Normal and Advanced use the same subscription and universal SDK. The selected model changes the active-minute rate and applies to the next session.

The 7-day Pro trial is locked to Normal. The Dashboard worker rejects an Advanced selection even when browser controls are modified.

Add only the languages the business can actually support. The plan allows 2, 5 or 10 languages depending on entitlement.

Search by session ID, transcript content or visible metadata. Status filtering keeps active, completed and failed sessions separate.

A selected session combines transcript messages, runtime events, usage, recording and Human Inbox references when those records exist.

Transcript retention follows the plan. Audio and transcript policy are separate; a plan can retain text without recording audio.

Pro does not record audio. Business retains audio for 30 days and Enterprise for 90 days.

The recording policy badge reflects D1 entitlement.

The browser requests audio through the authenticated Dashboard worker. Direct R2 object keys and bucket credentials are never exposed.

Human Inbox keeps the verified visitor thread connected to the originating Chat or Speak session. Each case carries its status, priority, assignment and conversation lineage.

Accept the case before the visitor is told a person joined. Reply inside the protected widget thread, add internal notes, and keep the operational timeline complete.

Use Return to Agent when AI can continue the same conversation. Use Resolved after the requested work is complete, and Closed when no further response is expected.

Support Messages connects to the WebsDocs mail application through a Worker service binding. SMTP credentials are never sent to this page.

Select a message to display the protected thread and reply context. Inbox and Sent remain separate views.

The composer sends through the Dashboard worker using the active dashboard session and CSRF protection.

The selected 7-, 30-, or 90-day range is calculated by the Dashboard Worker from session, usage, handoff, and wallet records.

The outcome meter separates completed sessions, sessions with a human handoff, and unresolved sessions. It is an operational view, not a sales attribution claim.

The gauge estimates how much active runtime the current prepaid balance can support. Realtime performs the final admission and stop decisions.

Resource meters reveal where the workspace is approaching a configuration limit before a save is rejected.

Billing includes the complete time while a voice session is active: visitor speech, AI speech, pauses, model thinking and Worker operations.

Normal is $0.32 per active minute and Advanced is $0.75. There is no separate AI, routing, Worker or platform fee.

The usage table exposes session, model, quantity and charged credits so the dashboard can be reconciled with the wallet ledger.

The orbit shows available credits and health against the low-balance threshold. A zero usable balance prevents a new LLM session.

The same credit balance supports different active minutes because Advanced consumes weighted credits at the $0.75 rate.

The ledger lists grants, purchases, usage debits and adjustments. Setup owns the first grant and Realtime owns usage settlement.

Start with the plan, provider status, service state, renewal or end date, and any cancellation-at-period-end flag. These fields should tell the client whether service is active and what happens next.

Check the current period start and end, billing cadence, provider reference, renewal state, and plan name. Billing remains the authority for commercial status.

The action area should explain what the client can do now: open the billing portal, resume renewal, request cancellation, or request a plan change.

Plan changes, cancellation, reactivation, and billing-portal access require the authenticated dashboard session and may require fresh email verification.

Only invite people who should see transcripts, recordings, Human Inbox, support messages and billing information.

Pro supports 3 team members, Business 8 and Enterprise 20. Invitations and active members are reviewed together.

Inviting or removing a member requires fresh verification. The invitation link verifies the invited email, reuses an existing account password, or creates a password for a new account.

Dashboard access requires the registered email, one selected company workspace, the user password, and a fresh email verification code. A session is created only after both password and OTP succeed.

The password belongs to the email user identity. When that email can access several companies, each workspace appears once and the same password is used before the workspace-bound OTP check.

Forgot password verifies the registered email, issues a short-lived one-use reset authorization, replaces the user password, and revokes active dashboard sessions. The new password applies to every permitted company for that email.

TOTP provides an additional account security factor. The secret is encrypted in D1 and is shown only during setup.

Review active dashboard sessions and revoke any browser you no longer trust. Password changes and password recovery revoke other sessions automatically.

Password verification, OTP delivery, OTP verification, recovery, session revocation and sensitive changes remain visible in the account security timeline.

Every plan loads the same rtd-agent.js. Site ID, D1 entitlement, verified domain, selected model, published profile, and wallet determine the real behavior.

The customer website receives only the RTD SDK URL and Site ID. Plan, model, profile, wallet, recording, and feature policy remain server controlled.

The Hosted Agent URL is read from the published voice_hosted_pages record. It provides an immediate public Agent while the website connection is completed.

The loader injects Agent and button styles automatically. Copy the one-line button or use data-rtd-open-agent on an existing website button or link.

After publishing the loader, confirm the verified domain, wallet, Agent identity, Hosted Agent, and universal SDK checks in the installation panel.

Audit the client website or another public HTTP or HTTPS website. Local, private-network, and internal addresses are rejected before the Website Audit service is called.

Start with the overall score, audit state, scan time, tested URL, and the counts of critical issues, warnings, and passed checks. This is the client-facing answer before the technical detail.

Review SEO, performance, accessibility, security, mobile readiness, and other available category scores to identify the weakest business-impact area.

Critical issues and high-impact warnings should appear first with what is wrong, why it matters, the affected URL or asset, and the recommended fix.

Website suggestions should turn technical findings into practical next actions, including quick wins that can improve trust, discoverability, speed, accessibility, or conversion.

Use the technical section for headers, assets, connection checks, metadata, response details, and the evidence needed by a developer. It should support the summary rather than replace it.

Open a prior report to compare changes over time. Email delivery is optional and uses the verified account address.

Each workspace may start no more than 10 Website Audit scans in one hour. The remaining allowance is shown beside the form.

Start with whether an agreement is required, sent, viewed, signed, expired, or waiting for action. The status should make the client's next step obvious.

Review the agreement version, recipient or signatory, sent date, signed date, provider reference, and latest verified update from the Contracts service.

Use the agreement link to review or download the current contract when a verified URL is available. Never construct a contract URL from browser data.

Agreement status is important account information, but it does not silently suspend a paid agent. Any restriction remains an explicit server-side administrative action.

Start with total leads, new records, follow-ups due, qualified opportunities, and unresolved customer work. These metrics summarize operational demand rather than replacing the underlying records.

Use the pipeline to see how records move from new inquiry through qualification, follow-up, conversion, or closure. Investigate stages with unusually high volume or long dwell time.

The CRM trend chart shows whether lead and follow-up activity is rising or falling across the selected period. Use it with the lead table, not as a standalone conclusion.

The action panel should surface overdue follow-ups, unassigned records, high-intent leads, and other items that need a person now.

Use stage, intent, assignment, source, and follow-up filters to narrow the records that need attention. Keep the filter state visible so the result is understandable.

The lead metrics summarize total records, new leads, qualified leads, due follow-ups, and conversion signals for the current workspace.

Each row should expose identity, source, intent, stage, owner, latest activity, and next follow-up. Sensitive contact data remains protected by the authenticated dashboard.

The activity timeline combines security events with important dashboard and runtime activity while keeping secrets and full private contacts out of the response.

Use Refresh when reviewing a login, domain, model, team or subscription change so the latest D1 records are visible.

No. The visible conversation is only one part of RTC.

The service combines a business-aware website Agent with an authenticated operating dashboard, approved business knowledge, verified website origins, Human Handoff, Direct RTC Messages, Website Health, conversation visibility, profile controls, billing-connected RTC Credits, and publication history. RTC is designed to help visitors understand the business and move toward an approved next step.

That can include a service page, contact route, booking direction, quote path, support route, checkout, lead signal, or transfer to the company team. The important distinction is that RTC does not disappear after a widget is installed.

The business can continue controlling the profile, domains, operating mode, appearance, handoff cases, usage, reports, and account activity.

RTC can use the structured business profile and approved public knowledge connected to the published site. This may include the business name, summary, services, offers, public pricing guidance, locations, hours, contact details, FAQs, policies, important pages, service routes, aliases, support instructions, and fallback behavior.

Approved website context helps the Agent stay aligned with the real public business environment. The company can identify important pages such as services, pricing, contact, FAQ, booking, support, or policy routes and keep those paths connected to the RTC profile.

The business remains responsible for keeping published information current. When services, prices, policies, contact details, or support rules change, the RTC profile should be updated so the Agent does not rely on retired information.

RTC does not automatically receive unrestricted access to private customer records, invoices, payment accounts, passwords, databases, private files, or internal business systems. Public plan and billing rules can be explained when they are part of the approved knowledge, but private account facts require the correct protected route.

When a visitor asks for an account-specific refund, invoice, payment change, private order detail, or another protected action, RTC should explain the boundary instead of pretending it completed the request. The conversation can then move into Human Handoff for business-team review, or the verified RTC customer can use Direct RTC Messages to contact WebsDocs Billing, Support, Projects, or General operations from the dashboard.

Human Handoff connects the website visitor with the RTC customer’s team. When a conversation needs human authority, the Agent can stop trying to resolve the issue and create a handoff case with the relevant conversation context.

The visitor remains in the same website conversation experience while the business team sees the case inside the Human Handoff Inbox. An authorized team member can start handling the case, review why it was transferred, reply into the visitor widget, and mark the case resolved.

Handoff is especially useful for private billing questions, sensitive support issues, custom commercial decisions, complex project requirements, complaints, uncertainty, or any situation where a person should take responsibility.

Direct RTC Messages are the communication path between the verified RTC customer and WebsDocs. They are different from Human Handoff, which connects the business team with its own website visitor.

From the protected RTC dashboard, the customer can route a message to Support, Billing, Projects or Maintenance, or General operations. The message remains attached to the authenticated RTC account identity rather than relying on a separate anonymous mailbox session.

The customer can review incoming replies and sent history inside RTC. This keeps operational communication closer to the relevant site, plan, profile, billing, support, or maintenance context.

RTC Website Health is primarily a public website structure and business-readiness assessment. It reviews signals that affect how clearly the website presents the business and whether visitors can find useful contact, support, trust, lead, Agent, and ecommerce paths.

Checks may cover business identity, service clarity, headings, links, images, forms, calls to action, contact details, About and policy routes, accessibility hints, response information, public security headers, performance structure, lead readiness, support readiness, RTC Agent readiness, and ecommerce readiness where relevant. It is not a penetration test, legal-compliance certification, complete private-system audit, or replacement for specialized Lighthouse and technical SEO platforms.

The useful RTC difference is the workflow: scan the approved site, review priorities, receive the report, compare history, and request WebsDocs maintenance.

With the required business information prepared, the guided setup can usually be completed in about five minutes. The activation path is designed to move from checkout through identity verification, business setup, final confirmation, publication, installation, and dashboard access.

The activation email normally arrives quickly, but WebsDocs should not promise an exact inbox-delivery second. Spam filtering, email-provider delays, incorrect customer details, OTP delivery, payment review, or website-origin conflicts can affect timing.

The fastest setup happens when the customer already has the business summary, services, FAQs, policies, locations, hours, contact routes, important website pages, and preferred Agent presentation ready.

Prepare the public business name, short summary, primary market, services, offers, service areas or locations, business hours, contact details, preferred visitor next steps, and approved website address. Strong RTC setup also includes frequently asked questions, privacy and commercial policies, payment or refund guidance where applicable, support boundaries, booking or quote paths, important website pages, Human Handoff instructions, and fallback behavior for uncertain questions.

The information should describe what the business actually provides now. Avoid loading the profile with retired services, unapproved guarantees, private customer details, or internal information that should not be used in public visitor conversations.

After successful activation, RTC creates the published site relationship and provides an installation package connected to the RTC Site ID and approved website origin. The customer can place the provided loader on the approved website according to the installation instructions.

The publication receipt can also provide access to the hosted Agent path and the protected RTC dashboard. The dashboard is where the customer manages the profile, appearance, domains, conversations, Human Handoff, Messages, Website Health, credits, billing information, and activity.

The site ID should not be copied to unrelated domains. Approved-origin controls help prevent the published Agent from being reused outside the websites authorized for the active RTC account.

Yes, within the active plan allowance. The customer can manage approved domains from the protected RTC Control Center, but adding or removing an origin is treated as a protected account change.

The domain change must pass verified-account identity confirmation before it is applied to the draft. The customer then publishes the change so the approved-site relationship and live operating record remain traceable.

Removing a domain can affect an existing installation. The customer should confirm that the Agent is no longer needed on that website and review any related operational consequences before publishing the removal.

Yes. The protected RTC Control Center allows the customer to maintain the published business profile after activation.

This includes business identity, public summary, services, offers, locations, hours, contact routes, FAQs, policies, important pages, appearance, and operating mode. Changes should be reviewed before publication because the live Agent may use the updated information when guiding visitors.

A draft and published state helps distinguish edits being prepared from the profile currently connected to the live RTC site. Frequent updates are especially important when pricing guidance, services, policies, hours, locations, contact details, or support instructions change.

RTC should not convert uncertainty into a confident invention. When the approved profile does not contain the required fact, the Agent can explain the limitation, ask a useful clarifying question, guide the visitor to an approved public route, or offer Human Handoff.

Sensitive requests may include private billing, legal decisions, complaints, account access, payment execution, confidential information, high-value custom commitments, or anything requiring a responsible person to review the facts. Runtime conditions can also lead to a limited, routed, or blocked result.

Unauthorized origins, disallowed modes, an empty wallet, or abuse patterns should not continue as normal billable generation.

RTC is designed for protected customer and team operation rather than one invisible browser-only session. Authorized team access can support Human Handoff handling, operational review, profile work, messages, reports, and account activity according to the available team-member pipeline.

The dashboard can show active sessions and traceable events such as profile publication, domain identity verification, Human Handoff actions, Direct RTC Messages, Website Health reports, and other account operations. Records are not promised as unlimited permanent storage.

Conversation, message, report, session, and activity retention follows the active plan, product rules, and applicable service conditions.

No. Public answers can explain approved public billing rules, but private invoice, account, payment, refund, or customer-specific facts belong to protected routes or human review.

RTC Setup Studio turns approved business information into the public knowledge, appearance, website connection, dashboard identity, and operating rules for your Real-Time Chat Agent. At the end, you receive one permanent Site ID, a protected client dashboard, a published RTC Agent, installation code, a hosted Agent link, and a verified publication receipt.

Match the activation code, registered email, and approved website to the record issued by WebsDocs. A successful validation opens the setup session and loads the real plan, company, website, and limits from the server.

Confirm that you control the registered client email before creating permanent dashboard access. A successful code confirms email ownership for this protected setup session.

Create the permanent password for the verified RTC client workspace. The password is securely hashed by the server and linked to the verified account after publication.

Review the actual server-provided plan, allowed domains, profile limits, model modes, and dashboard login allowance before building the profile. You understand what this account can publish and which controls will remain available after activation.

Describe who the business is using factual, public, structured information that the Agent may safely repeat. The Agent receives a clear company identity instead of guessing from a website or one large biography.

Tell visitors how, when, and where they may contact or visit the business. The Agent can provide approved contact, booking, quote, support, location, service-area, and operating-hours information.

Create one structured record for each real service customers may ask about. The Agent can explain services consistently, including who they suit, how they are delivered, availability, safe price wording, and the official page.

Add real packages, products, subscriptions, promotions, or other public options a customer can evaluate or purchase. The Agent can distinguish between general services and specific customer-facing offers.

Define what the Agent may say about prices and when a human must confirm a quote. The Agent avoids inventing prices, treating estimates as promises, or giving an unauthorized commercial commitment.

Teach the Agent how to answer the real questions customers ask repeatedly. Visitors receive consistent, approved answers without forcing the Agent to infer from unrelated text.

Explain the Agent's public behavior, privacy wording, blocked topics, and situations that require human authority. The Agent knows when it may answer, when it must limit the answer, and when it must stop and route to a person.

Define when the Agent should request human help, where the request goes, and what the visitor is told. Visitors have a clear route to an authorized person instead of being trapped in an automated conversation.

Provide the visual identity for the client workspace and the public RTC Agent. The dashboard can display the company logo while the Agent may use a separate avatar.

Default RTC assets remain available when no custom image is uploaded.

Choose how the Agent identifies itself and appears on the approved website. Visitors see a consistent Agent name, greeting, tone, accent color, company logo preference, and launcher position.

Confirm where the RTC Agent is permitted to run and add any additional origins allowed by the plan. The Agent loader accepts requests only from approved and verified website origins.

Choose an approved public capacity mode without exposing or depending on an internal provider model name. The Agent operates within the plan's permitted speed, reasoning, and credit multiplier profile.

Understand how the published RTC Agent will be placed on a website or shared after the permanent Site ID is created. After activation, the same authoritative Site ID is used in the floating widget, optional Ask AI button, hosted Agent link, email handover, receipt, and Dashboard Installation tab.

Understand the contract status, billing cadence, and 12-month service commitment connected to the RTC account. The agreement is created and emailed with publication, remains attached to the permanent account, and can later be viewed from the client dashboard and RTC administration.

Check the full structured profile and server-controlled setup before requesting the final publication code. A correct saved draft is ready for final verification without accidental omissions or unsupported claims.

Give fresh proof of email control and an explicit typed confirmation before the permanent RTC resources are created. One protected server operation creates or confirms the account, Site ID, agreement, entitlement, wallet, profile publication, installation package, handover messages, and verified receipt.

Collect the permanent identifiers and installation package produced by the completed server publication. The client has everything needed to install, share, test, and operate the published RTC Agent from the protected dashboard.

The setup interface can display the step list, but protected progression depends on the authoritative server state. Validation, email verification, password creation, profile save, agreement, and final publication each gate later actions.

This is the quickest place to understand whether your RTC Agent, customer activity, credits, billing and agreement are healthy before you make changes. Conversation, lead, handoff, checkout, usage, latency and failure figures come from the RTC runtime database.

Billing and agreement facts remain under their own authorities.

No. They use recorded RTC runtime and billing data.

Missing history is shown as missing history.

The previous matching period had no usable non-zero baseline, so a percentage would be misleading.

A recorded total for the selected period, compared with the immediately preceding period of the same length.

The earlier period has no usable baseline. The Dashboard deliberately avoids inventing a percentage.

Review the public identity and capabilities of the RTC Agent currently connected to this Site. This page renders the current RTC runtime and Paid-Control configuration.

No. Identity, profile publication and knowledge indexing are separate operations.

Check Profile publication, Knowledge Search and the verified domain before changing the model.

The model mode and published setup currently used for customer conversations.

The actions and answer types available to the Agent.

Use this area to understand visitor activity, lead quality and the customer journey without reading every transcript first. CRM totals are built from RTC conversations, leads, handoffs, checkout events and usage records for the selected Site.

Yes. The Dashboard de-duplicates the lead conversation in totals but keeps the separate operational records.

Use only approved business processes and your privacy obligations when handling visitor information.

A signal of commercial or support importance based on the recorded conversation.

Lead records grouped by their current follow-up status.

Open complete visitor and Agent transcripts with message order, time, page, intent and lead context. Transcript turns come from rtc_conversations and rtc_messages for the exact Site ID.

Check the selected Site and time range. A new Site may not have recorded conversations yet.

The Dashboard presents the recorded history; it should not rewrite the original conversation.

One visitor session recorded by the RTC runtime.

The main purpose detected from the conversation.

This is the human-support workspace for visitors who requested or required a person during an RTC conversation. Handoff operations are isolated from transcript history and use the protected RTC runtime routes.

No. Conversations are historical RTC transcripts; Handoff Inbox is the operational human-support lane.

Use Waiting visitor, then close according to your normal support policy.

The visitor or Agent requested a person.

A team member has seen the request.

Review visitors who showed sales, quotation, booking or support intent and manage the follow-up stage. Lead totals combine dedicated lead records, handoff-linked conversations and positively scored conversations without double counting the same conversation.

RTC records only information the visitor provided or that your approved workflow captured.

A handoff may be sales or support. Read the context before classifying it.

No follow-up has started.

A team member has begun follow-up.

See which website pages produce conversations, leads and pricing or checkout interest. Page statistics are grouped from recorded RTC conversations and checkout events for the active Site.

The runtime did not receive a usable page URL for that record.

No. Look at leads, intent and outcomes, not conversation volume alone.

The visitor page connected to the RTC activity.

A recorded pricing, quote, payment or checkout signal.

Use the verified mailbox to contact approved WebsDocs departments without exposing mail credentials in the browser. Messages pass through the protected Mail App service binding; browser code receives no provider credentials.

No. Mailbox data is isolated by the verified account and Site context.

Refresh the thread and confirm the mailbox service is available before opening a support ticket.

Messages delivered to the verified RTC customer mailbox.

Messages submitted from this RTC workspace.

Run a certified scan of a verified RTC website, read the evidence and keep a report history for maintenance decisions. The Dashboard authorises the account and Site; the Website Audit Worker remains the scanning authority.

Dashboard scans are limited to the verified RTC account context and approved domains.

No. It records evidence; maintenance is a separate project decision.

A measured summary of the checks performed by the scanner.

A stronger problem requiring attention.

This is the approved business information used to identify the company and prepare the Agent’s published knowledge source. Profile mutations pass through Paid-Control.

Knowledge indexing is a separate runtime operation.

The fresh-verification window is normally about ten minutes.

Use only claims the business can support. The Agent should not rely on invented or unverifiable information.

Saved profile content that is not yet the currently published version.

The approved profile version available to connected services.

Check what the live Agent can retrieve and deliberately update its index after approved profile changes. Search and indexing are performed by the connected RTC runtime and its vector knowledge authority.

No. You must deliberately start the Agent update.

Confirm the latest profile was published and the subsequent index job completed successfully.

A read-only check of the current Agent index.

A controlled update of the Agent’s searchable knowledge.

Manage the company logo and Agent avatar as two separate protected assets. Protected assets are stored through the RTC asset authority and served only from approved records.

The company and the Agent are different identities and should remain distinguishable.

Use the available asset controls or contact support when the current interface does not expose removal.

Identifies the business workspace and company presentation.

Identifies the assistant itself.

Control the website origins permitted to load or operate this RTC Site. Domain approval is enforced server-side and connected to the exact Site ID.

No. Origins normally use the scheme and hostname, not an individual page path.

The domain may still need verification, publication or installation checks.

The main website origin for the Site.

Ownership or approval checks completed.

Choose the permitted RTC operating mode and understand its capacity and credit multiplier. Model changes pass through the protected client authority and are recorded against the Site.

No. Model capacity and business knowledge are separate.

The account plan or current policy may not permit it.

Lower-cost, faster general operation.

Greater reasoning or response capacity at a higher rate.

Review measured model calls, tokens, credits, response time and charge records for the selected period. Usage comes from the RTC usage ledger; Billing remains the financial authority for wallet and payment records.

One conversation can contain several model calls, and mode multipliers can differ.

Use the recorded usage row and billing policy; the Dashboard should not assume a charge without authority data.

Text sent into the model for processing.

Text produced by the model.

Review the linked billing account, wallet, payment period, invoices and current financial standing. The Dashboard displays Billing Worker authority; it does not write payment state directly.

No. A paid 12-month commitment continues its contracted installments.

Yes. Recovery access is retained for payment, agreement and account records.

Billing is current.

A scheduled payment did not complete.

Manage plan changes, renewal preference, pauses and permitted recovery actions for the exact RTC subscription. Subscription requests are validated by the Dashboard and processed by the Billing Worker for the exact Site, Account and Subscription IDs.

With renewal off, service continues through the paid final period and then moves to recovery at the commitment end.

The Dashboard stays in the normal full view because the active commitment remains current.

Service remains available while billing is current.

The current commitment continues, but another term will not begin.

View the service agreement connected to this exact RTC account before signing and retrieve the signed record afterward. The Dashboard reconciles Paid-Control with WebsDocs Contracts and uses the newer, more complete authoritative status.

Yes. Use View & sign agreement to read the full document before completing it.

The Contract ID, signed agreement, payment history and audit record remain preserved.

The agreement exists and still requires the client’s signature or confirmation.

The agreement link was delivered.

Use the approved loader, Site ID and trigger details to place the RTC Agent on the verified website. The public loader identifies the Site; server-side bindings and secrets remain outside the browser.

Use your website’s shared template so the loader is included once per page.

The production origin may not be added, verified or published.

The public script that loads RTC.

The exact customer Site identity used by the runtime.

Invite authorised people, assign roles and remove access without sharing one password between staff members. Membership and role changes are recorded against the exact RTC account.

Yes. The login flow lets an authorised user choose the correct RTC account.

No. It removes that user’s account access; operational records remain with the RTC account.

Highest account responsibility and authority.

Operational account management without transferring ownership.

Protect the RTC account with verified contacts, Authenticator, fresh verification and active-session review. Sensitive actions require server-validated step-up assurance; browser code does not contain the verification secrets.

Sensitive changes use a shorter fresh-verification window to reduce account takeover risk.

Use the approved recovery route or contact support from the verified account.

A one-time code sent to the verified account email.

A rotating code generated by the client’s authenticator app.

Review important account, login, profile, billing and operational events with exact timestamps. Activity is assembled from protected account audit and connected service events.

The audit trail includes both client actions and protected service operations.

Operational and contractual retention rules may require records to remain available.

A recorded account or system action.

Whether the operation succeeded, failed or was blocked.

Contact WebsDocs when a connected authority is unavailable, a protected operation fails or the account requires human review. Support does not bypass Billing, Contracts or runtime authority; it investigates and repairs the connected record safely.

Use RTC Support-Messages for verified account matters and the public support ticket when you cannot access the Dashboard.

Site ID, date and time, page, action, visible error and whether refreshing changed the result.

General WebsDocs support route.

Verified communication linked to the RTC customer account.

No. AI visibility tools mainly monitor whether AI systems mention a business.

ASG gives AI buyers an official hosted place to read approved public facts, ask live questions, follow business routes, start A2A sessions, and submit handoff, quote, or checkout intent.

When the required information is ready, activation can move quickly through a copy-paste setup path: choose a membership or trial, receive setup access, complete the public profile, verify ownership, approve the facts, and publish the ASG Live Profile.

No. AI-facing routes are designed around approved public facts only.

They do not expose setup codes, OTPs, private dashboard records, payment data, internal notes, confidential client information, billing administration, or protected system controls.

No. ASG is hosted as a separate AI-readable gateway.

Your website can remain focused on human visitors while ASG carries the approved public profile, discovery files, live Ask, A2A routes, and buyer-intent paths.

Yes, when the client enables that intent door. ASG can accept safe checkout, quote, or handoff intent.

The business still controls the final payment, contract, identity check, approval, and human review process.

The ASG Client Visibility Dashboard can show profile status, AI activity, visitor proof, known and unknown agents, live usage, credits, buyer requests, intent events, install resources, safety settings, subscription status, and support routes.

No. Static discovery routes remain open, but live LLM reasoning uses prepaid ASG AI Credits.

The wallet keeps usage controlled and allows the dashboard to warn, limit, pause, or route requests to fallback when the available balance becomes low.

Approved static routes can include the ASG Live Profile, Pulse, llms.txt, agent card, schema, sitemap, robots signals, public services, public pricing notes, policy, contact routes, FAQs, and approved profile facts.

Credits are used when ASG performs live LLM reasoning, answers a public Ask request, produces an A2A reply, retrieves deeper approved context, explains services or pricing, applies policy rules, or evaluates buyer-intent routing.

Normal websites are designed mainly for people and may contain outdated, repeated, promotional, or sensitive information. ASG gives AI systems a cleaner route with approved public facts, defined boundaries, structured endpoints, and monitored activity.

The business controls the approved public facts entered during setup, including services, offers, FAQs, public pricing notes, contact paths, policies, blocked topics, tone direction, and handoff rules. ASG is designed to answer from that approved layer.

ASG should refuse, limit, or safely redirect private, unsafe, unsupported, or sensitive requests. It should not expose private records, admin data, OTPs, setup codes, payment details, confidential files, or protected system logic.

Handoff intent moves the request toward human review. Quote intent signals that the buyer wants pricing or a proposal.

Checkout intent signals readiness to move toward a purchase route when the business has enabled that door.

Yes. The client can disable checkout intent, keep it review-only, route it to a quote path, or connect it to an approved checkout route.

ASG does not force payment execution.

ASG can record public-safe visitor signals such as declared agent name, route activity, known or unknown classification, Ask events, A2A sessions, and intent events. Some traffic may remain unknown and can be reviewed in the dashboard.

The profile can include business identity, approved description, services, offers, FAQs, public pricing notes, contact routes, market and language direction, policy boundaries, handoff rules, Pulse, discovery files, public Ask, A2A routes, and intent doors.

Prepare your public business name, website, email, services, offers, FAQs, pricing notes, contact links, support routes, handoff destination, blocked topics, public policies, language needs, and any safe facts you want AI systems to understand.

Yes. Standard profile structure guidance is included with active memberships.

Agency, bulk, compliance-heavy, white-label, or unusually complex implementations may require a Custom Quote.

Yes. ASG can host public business profiles for different markets.

Results improve when the profile contains clear services, public routes, regional notes, supported languages, market boundaries, and safe handoff instructions.

Multilingual behavior depends on the model, profile content, and setup rules. ASG can include language and market direction so visiting AI systems understand which languages and regions the business intends to support.

Both. Business Membership supports one serious public AI profile.

Enterprise supports deeper coverage, more domains, higher usage, more users, and stronger controls. Agency and Custom plans support multi-profile and white-label needs.

Not for the hosted ASG profile itself. A developer may help when you want root discovery files, custom website signals, advanced routes, special integrations, or a deeper connection between ASG and your own systems.

Yes. Services, offers, pricing notes, FAQs, contact routes, policy wording, handoff rules, markets, and language direction can be reviewed and updated as the business changes.

ASG can record declared identity, known and unknown traffic signals, and suspicious behavior for review. Identity claims alone are not treated as proof, so safe boundaries, rate controls, and activity evidence remain important.

Buyer AI needs structured public facts, official service routes, safe questions, machine-readable pricing and policy direction, action paths, and proof. ASG gives those agents one controlled place to read, ask, compare, and submit intent.

Start the 7-day Business trial if you want to test one ASG Live Profile with a payment method on file. Choose Enterprise for deeper profile coverage, more domains, higher usage, and stronger visibility controls.

Use Custom Quote for agency, bulk, white-label, or advanced routing needs.

Yes. The client can cancel before the trial expires to avoid the first subscription charge.

After cancellation, the public profile may be paused while approved setup data remains available for a limited reactivation period.

Yes. Active clients can purchase approved credit top-up packs when they need more live LLM capacity.

Top-ups are added to the ASG wallet after successful payment and are shown in dashboard credit records.

Static reads do not use credits. Failed provider calls, rejected abuse attempts, invalid requests, and blocked private-data requests should not consume successful-answer credits.

Live usage should be recorded only when billable LLM processing occurs.

The setup flow is designed to verify ownership and require approval of the public facts before publication. Clients remain responsible for the accuracy and authorization of the business information they submit.

A visiting agent can request an A2A session and receive approved scopes, allowed routes, denied private capabilities, session limits, and safe message endpoints. The handshake does not grant access to admin, payment, private-client, or database systems.

Custom pricing may apply to white-label portals, bulk profile creation, dedicated infrastructure, unusual compliance requirements, advanced identity checks, custom A2A routes, complex data migration, or direct integration with external business systems.

Review Watch is the ASG safety and quality report card. It summarizes suspicious behavior, blocked requests, repeated unknown patterns, claim-heavy questions, private-data attempts, admin-route attempts, and unusual activity around payment/action routes so the client can review meaningful pressure without treating every unknown visitor as dangerous.

No. Unknown means ASG does not yet have enough identity evidence to classify the source confidently.

Repeated suspicious behavior matters more than the label alone; use Review Watch and traffic patterns before escalating.

Confirm that this setup code belongs to the correct company before any private workspace or public profile is created. This tab loads the authoritative D1 setup record and shows the server-approved company, website, email, plan, credits, payment mode, expiry, and required next action.

Nothing is published at this stage. The company name and website shown here become identity anchors for later setup steps.

The setup code, verified email, payment state, internal setup status, and server records remain private.

Use the one-time email code to prove that the person completing setup controls the authorized business email. This first OTP protects the company record from being activated by the wrong person.

It also confirms the company name and website against the server-approved setup. No OTP or email verification detail becomes public.

The confirmed business name and website can later appear in the public profile. The email address, OTP value, send history, verification timestamps, and login-security evidence remain private.

Understand the server-issued membership, credits, approval or checkout state, and the next permitted action. The plan controls profile capacity, approved domains, team seats, analytics history, AI credits, and other entitlements.

Clients cannot raise their own limits in the browser. The public profile can later expose approved business information, not private payment or entitlement records.

Payment status, quote details, contract limits, internal approvals, billing identifiers, and credit administration remain private.

Reserve the stable ASG identity, create or confirm email-password access, and activate the client workspace without publishing the profile yet. This tab creates the permanent client slug, dashboard workspace, gateway and Pulse reservations, included credits, and the link between the verified email and this company profile.

The client slug, hosted gateway path, Pulse path, and later public profile routes can become public. The dashboard password, credential hashes, account links, setup session, billing records, and private dashboard remain private.

Create the concise public truth layer that AI systems use to understand the company. This tab supplies the business identity used by the hosted ASG profile, Pulse, llms.txt, company JSON, sample questions, and future buyer-agent interactions.

Business name, legal name when entered, website, industry, languages, summary, and brand story may appear in public ASG outputs. Internal company notes, credentials, customer records, staff-only procedures, private contracts, and unpublished strategy must not be entered.

Give AI systems and buyers safe, public routes to reach the business without exposing private contacts. This tab defines public email, phone, address, service area, location, timezone, and other approved contact details used for routing and trust.

Approved business email, phone, location, service area, and public contact details may appear in the profile and discovery routes. Personal mobile numbers, private home addresses, internal extensions, recovery contacts, and staff-only details remain private.

Add structured, approved services with clear outcomes, audiences, limits, and official action routes. Service entries help AI search and buyer agents answer what the business does without inventing capabilities from vague marketing text.

Approved service names, descriptions, categories, outcomes, and public URLs may be exposed through ASG routes. Internal delivery instructions, private rates, customer-specific terms, staff assignments, and confidential methods stay private.

Structure commerce-ready public offers without turning estimates or internal packages into binding promises. Offer entries give buyer agents clear names, descriptions, availability, official product links, and safe purchase or inquiry routes.

Offer titles, descriptions, availability, approved price wording, and action URLs can become public. Supplier costs, margins, unpublished discounts, private quotes, internal inventory notes, and customer-specific pricing remain private.

Tell ASG exactly when it may state a price, show a range, or route the buyer for a quote. Pricing rules reduce wrong AI promises by separating fixed public prices from estimates, variable work, regulated advice, taxes, and custom quotations.

Approved fixed prices, ranges, starting prices, pricing conditions, and quote instructions may become public. Internal cost calculations, margins, negotiated rates, customer invoices, discount authority, and billing records remain private.

Give ASG safe destinations for contact, booking, quotes, products, support, and checkout actions. Routes convert public discovery into official business actions while preventing AI from inventing forms, payment links, or support destinations.

Approved action URLs can appear in the profile, agent card, A2A replies, sample answers, and install pack. Admin panels, signed internal links, private payment sessions, staff tools, and authenticated customer portals remain private.

Add real customer questions and approved answers so routine requests can be answered consistently and at low cost. FAQ entries are the safest first answer source for common questions.

They help static ASG responses and reduce unnecessary live AI use. FAQ questions, answers, and topics may be published through the ASG profile and FAQ route.

Private cases, customer records, internal troubleshooting, legal strategy, account data, and confidential exceptions stay private.

Define what ASG may explain and what must remain private, restricted, uncertain, or human-reviewed. Boundaries protect the client and WebsDocs from data leakage, wrong promises, unsafe advice, and automated answers outside the approved public scope.

The public policy and high-level boundaries may be exposed so AI systems understand what ASG can and cannot answer. Internal enforcement logic, security controls, abuse evidence, private blocklists, credentials, and investigation details remain private.

Route high-risk, uncertain, private, regulated, or purchase-ready requests to an approved human channel. Handoff rules stop ASG from continuing when a person should review pricing, eligibility, complaints, private accounts, sensitive advice, or serious buyer intent.

Approved handoff instructions and public contact routes may be shown to buyers and AI agents. Internal escalation trees, staff schedules, private contacts, case notes, and investigation procedures remain private.

Prepare the public discovery links that show AI systems where the approved hosted business layer lives. The badge, Pulse link, profile JSON, llms.txt, agent card, sitemap, and related snippets connect the client website to WebsDocs-hosted ASG discovery.

The ASG badge and generated discovery URLs are designed to be public and machine-readable. Setup codes, dashboard credentials, internal API secrets, signed admin routes, and private files are never part of the install pack.

Inspect the complete public payload, plan usage, routes, boundaries, and install outputs before requesting final approval. This tab is the quality gate.

It combines the current profile into the exact draft that the server will retain and the final OTP will approve. Only the approved draft fields become public after final OTP and successful publication.

Draft history, setup status, operator actions, validation evidence, billing state, and credentials remain private.

Authorize the exact saved public profile and publish it through the protected server workflow. The final OTP is the owner's explicit approval of the current draft.

Publication creates or updates the hosted profile, Pulse, machine-readable routes, and dashboard handover links. The approved public profile, routes, FAQ, policies, Pulse, and discovery files become available after successful publication.

The OTP, email, approval evidence, setup session, credential data, billing records, and server logs remain private.

Verify the live ASG profile, Pulse, dashboard, discovery routes, badge, and install pack after publication. This final tab proves that the setup completed and gives the client and WebsDocs the permanent links needed for dashboard access, public discovery, support, and future maintenance.

The hosted profile, Pulse, public Ask, company JSON, FAQ, agent card, llms.txt, sitemap, badge, and approved action routes are public. Dashboard sessions, passwords, OTPs, setup records, billing, private files, support records, and admin operations remain private.

No. The setup guide treats Review as the quality gate and says to save the authoritative D1 draft before requesting final OTP.

The final OTP approves the exact saved draft, not unsaved browser changes.

Live Billing Core records for requests, plan changes, cancellations, renewals, and payments.

Review the agreement generated for this ASG workspace and follow its live completion status. The dashboard is checking the Contracts Worker for this company.

Reads, questions, visitors, requests, and ranked AI identities live together here.

Public Ask and A2A routes use only the approved ASG profile. Private dashboard, payment, OTP, and admin data remain blocked.

These buttons open the free static GET preview. Live POST answers remain credit-aware.

Gateway review, blocked claims, unknown traffic, and client-safe action status appear here.

Use these assets on the client website. Hosted ASG works before root install; root install strengthens ownership and discovery.

Use Copy to avoid broken snippets.

Business includes 1 owner, 2 administrators, and 5 regular users. Enterprise includes 1 owner, 5 administrators, and 20 regular users.

Pending invitations reserve a seat.

Owners may invite administrators, editors, or viewers. Administrators may invite editors and viewers.

Changing dashboard branding does not verify a domain, recompile the public profile, change the client slug, or touch billing. One fresh OTP/TOTP step-up covers both logo and banner changes for 15 minutes.

Normal business-domain verification is optional and never disables hosted ASG. A custom ASG hostname requires verification before routing to the same permanent client slug.

The client ID, client slug, billing site ID, Stripe customer, and subscription remain unchanged. Only the website, primary-domain reference, compiled profile URL, and Billing allowed origin are updated.

Scan any safe public website. ASG domain verification is not required.

Each ASG account receives 10 shared scans in a rolling two-hour window.

Live A2A, UCP, MCP, and seller-checkout status issued by the ASG gateway. No gateway secret is exposed in this browser.

Open or copy the canonical routes published by your gateway. Open this section to load protocol routes.

Choose any country. SMS is used where available; otherwise the code is sent to the verified ASG email.

Scan QR with Google Authenticator, Microsoft Authenticator, 1Password, or any TOTP app. Manual key and setup link are shown together.

The ASG Client Dashboard is the control room for a business AI Sales Gateway. It shows how AI agents, search systems, visitors, and buyer-style traffic interact with the client’s public AI-readable business profile.

It is not only a visitor counter. It helps the business understand which services are attracting attention, which questions are being asked, whether live AI answers are using credits, and whether anything needs review.

Read the dashboard in this order: first check the time window, then look at analytics, then registry, then LLM usage and credits, then review watch, and finally install/profile status. This gives a clean story: who came, what they wanted, what ASG answered, what it cost in credits, and what needs attention.

This section shows what is happening around the client’s AI Sales Gateway during the selected time window. It can include hosted gateway visits, Pulse opens, profile reads, live questions, A2A messages, lead signals, product/service interest, and the AI-readable pages that are getting the most attention.

Client action: if one service gets repeated interest, improve that service description, FAQ, pricing note, and call-to-action.

The registry groups visitors and AI traffic into useful identity buckets. Some systems are known providers, some are returning unknown visitors, and some are normal browser or crawler traffic.

Unknown does not automatically mean dangerous. It usually means ASG does not yet have enough repeat signals to classify the source confidently.

Client action: do not panic on unknowns. Watch repeat patterns.

If unknown traffic becomes heavy or strange, check Review Watch.

This section explains live answer usage. Static public discovery pages can be read without using live answer credits.

Credits are used when ASG has to generate a live answer, handle an A2A message, or process a deeper question using the client’s approved public business knowledge. Client action: if credits are being used quickly, check whether questions are useful buyer questions or noisy repeated traffic.

Review Watch is the safety and quality report card. It summarizes traffic that may need attention: suspicious behavior, blocked requests, repeated unknown patterns, claim-heavy questions, private-data attempts, admin-route attempts, or unusual activity around payment/action routes.

Client action: review the details, improve blocked-topic rules if needed, and escalate only when traffic is repeated or clearly abusive.

Credits control live ASG answer capacity. Public discovery pages such as Pulse, llms.txt, agent card, schema, and public profile routes remain open for AI discovery.

Credits are mainly for live answers, deeper Q&A, A2A messages, and buyer-style questions that need ASG to respond. Client action: use top-up when traffic is good and the business wants more answer capacity without upgrading the plan.

The profile is the approved public knowledge base for the business. ASG should only answer from this safe profile, approved FAQ, service descriptions, public contact rules, pricing notes, and allowed handoff routes.

Client action: update weak service descriptions before blaming traffic. AI can only sell clearly what the profile explains clearly.

ASG is designed around approved public knowledge. The client dashboard may show logs and records, but public AI routes must not expose private dashboard data, payment records, passwords, admin routes, database content, or confidential customer information.

Client action: keep public profile content useful, but never place secrets or private business records in public ASG fields.

Lead signals are not always a submitted form. In ASG, a lead signal can be repeated pricing interest, service comparison questions, booking-route checks, quote-route checks, action requests, or AI agents asking decision-style questions on behalf of a buyer.

Client action: when lead signals repeat, improve the matching service page and give a clear quote/contact path.

The selected time window changes the story. A small 24-hour window is good for testing.

A 7-day window is good for weekly review. A 30-day window is better for client reporting.

A 3-month window shows whether AI discovery is growing or fading. Client action: do not judge ASG only from one quiet day.

Use 7-day or 30-day view for better business reading.

Some dashboard and setup actions are protected by email OTP or profile-lock rules. This protects the client from accidental public profile changes and stops unauthorized updates to business identity, contact details, and publish status.

Client action: verify recovery mobile, enable authenticator if available, and keep the owner email correct.

Some panels depend on connected backend workers. If billing, checkout, email, event logging, setup, or dashboard data bindings are missing, a panel may show empty values even when the front-end is working.

Client action: if a panel is blank, first check binding health before editing front-end code.

Static discovery assets such as the public profile, Pulse, llms.txt, agent card, schema, and other approved routes can be read as public information. Live Ask, A2A, and deeper generated responses use the live answer path and can consume ASG credits.

No. Recovery methods, OTPs, authenticator secrets, dashboard sessions, and security evidence remain private.

Public ASG routes use approved business information only.

Business Automation is the managed WebsDocs workflow system for moving inquiries, support, billing, quote, ecommerce, service, and escalation requests into structured business actions rather than leaving every case inside a generic chat conversation.

RTC primarily owns the controlled customer conversation and website Agent experience. Business Automation handles the process after or around that conversation: structured workflow cases, routing, approved knowledge, business rules, dashboard visibility, support continuity, and human review.

The current product flow can provide an activation code, secure setup page, dashboard access, hosted support or workflow routes, website widget snippets, a local profile package, workflow coverage, usage visibility, billing context, and an approved support path.

The current product describes workflow lanes such as booking, technical questions, billing, quotes, ecommerce support, service inquiries, and human review. The actual enabled workflow coverage depends on the client's plan, configuration, and approved business process.

No. The product is presented as AI-powered automation from the beginning.

The goal is controlled AI support with business rules, workflow routing, dashboard records, and human review—not an invisible imitation of a person.

The client dashboard can expose workflow cases, setup links, snippets, usage capacity, billing status, prepaid balance, email logs, client activity, and support paths. The dashboard is the protected operating layer, while public workflow pages and widgets remain customer-facing.

When the company profile, services, policies, FAQs, workflow notes, and escalation rules are already prepared, the guided setup can move quickly. The product page describes a roughly five-minute guided entry path for prepared information, but actual activation can still depend on payment, verification, configuration, or client-side installation.

The current Business Automation product page describes plans with no setup fee and managed configuration. Current plan amounts and billing structure should still be taken from the active product checkout rather than copied permanently into this FAQ.

The current billing architecture uses the Industry credit system internally. Included and purchased capacity can be recorded as separate credit batches so the system can track source, amount, validity, remaining balance, and consumption history.

Included capacity can be issued for a first period, monthly renewal, or scheduled annual windows depending on the active commercial setup. Annual payment does not necessarily mean the entire year's included capacity is made permanently available on day one.

Commerce Checkout provides the active Business Automation top-up purchase lane, while AI Billing records the resulting purchased capacity. A top-up adds usage capacity to an existing service; it does not create a second subscription.

Eligible older capacity is consumed before newer capacity. The billing system orders eligible credit batches so earlier-expiring and older balances are used first within the applicable grant-type priority.

WebsDocs applies a one-year purchased-credit policy: purchased or top-up credits are valid for 365 days from the applicable grant or purchase date unless a signed commercial agreement expressly defines a different treatment.

Some routine workflow actions can be automated, but the product explicitly includes human review and escalation. Sensitive, uncertain, exception-based, private-account, regulated, or high-impact actions should move to the approved human route.

That is the internal billing and implementation name used by parts of the current backend. The public product name is Business Automation.

An Industry identifier in a billing or support record can still refer to the current Business Automation lane.

Approved business knowledge is information the business is willing and authorized to use in customer-facing operation: company identity, services, offers, public pricing guidance, FAQs, policies, hours, locations, official links, support routes, and other verified facts. Draft internal notes, unsupported claims, passwords, private customer records, and confidential commercial data do not belong in the public knowledge layer.

Multiple conflicting versions make the Agent less reliable. RTD and RTC guide clients to keep structured knowledge clear, remove stale entries, and save one approved record.

ASG setup likewise warns against duplicate services, offers, and FAQ entries.

No. RTC deliberately separates profile saving/publication from knowledge indexing.

After an approved profile change, use Knowledge Search to check the live index and start Feed Agent only when a real knowledge update needs to be indexed.

Confirm that the latest profile was published, then confirm that the subsequent indexing job completed successfully. Profile publication and vector/search indexing are separate operations, so one can be current while the other is still waiting.

No. The RTC guide warns against repeatedly re-indexing unchanged content because it consumes resources without improving the Agent.

Search first, confirm whether the approved knowledge is actually stale, and only then start an update.

No. Public profile fields are for approved business information.

Private customer records, invoices, credentials, private files, internal procedures, staff-only notes, and account-specific information should remain behind authenticated routes.

It should not turn uncertainty into a confident invention. The safe behavior is to explain the limitation, ask a useful clarifying question, point to an approved public route, or offer the relevant human handoff/support path.

Not unless the business has explicitly approved a public rule that authorizes that exact commitment. RTD Studio guidance specifically warns against allowing the Agent to promise discounts, refunds, legal commitments, or special terms.

Account-specific exceptions should go to a human.

Structured FAQs provide a safe first-answer layer for common questions. They reduce ambiguity, keep wording consistent, and—in ASG—can reduce unnecessary live AI usage by letting routine public questions be answered from approved static content.

Include real recurring questions about services, locations, eligibility, booking, quotes, support boundaries, public pricing guidance, response expectations, cancellations, and the correct next action. Keep answers specific enough to help but not so broad that they create unsupported guarantees.

Typing a domain into a dashboard does not make it trusted. Verification connects the approved website origin to the correct customer/site identity and helps prevent a public Agent loader from being copied to an unrelated website.

Use the product's requested form. RTC domain controls normally work with the scheme and hostname rather than an individual page path.

RTD Studio may ask for the full main website during activation and then creates domain-specific installation identity.

The production origin may not have been added, verified, published, or matched to the correct Site/Domain identity. Check the dashboard Domains area before changing the Agent model or rewriting the loader.

Use the website's shared template or site-wide custom-code area so the universal loader is included once per page where the Agent should be available. Do not duplicate the same loader several times on one page.

Only public installation values belong in browser code: the approved public loader/SDK URL, Site ID or Domain ID where required, and supported public trigger values. Worker secrets, admin tokens, private service URLs, passwords, and signed internal links must stay off the website.

No. RTD Studio explicitly instructs clients to use the installation code created for the selected domain.

The matching Site ID and Domain ID belong to that website's approved origin.

It is the WebsDocs-hosted public Agent route created for the approved domain. It provides an immediate way to test or use the complete Agent while the business completes website installation.

It is a WebsDocs-hosted public route connected to the published RTC Site. It can be used for direct testing and access while the website loader is being installed or diagnosed.

The floating Agent injects a standard launcher, the button Agent connects RTD to an existing website button or link, and the iframe embeds the complete hosted Agent inside a page. All must use the correct domain-specific installation identity.

Voice requires browser microphone access. RTD Studio's installation guide keeps microphone permission in the iframe configuration so the embedded hosted Agent can request voice input when the user chooses Speak.

No. ASG is hosted as a separate AI-readable gateway.

The business website can remain focused on human visitors while the install pack points AI/search systems toward the approved hosted profile, Pulse, llms.txt, agent card, schema, and related discovery routes.

It is the public discovery package containing approved assets such as Pulse, llms.txt, agent card, schema, public profile routes, and recommended snippets. It should contain only public business knowledge, never dashboard data, payment records, credentials, or admin information.

Human Handoff is the controlled transition from an AI conversation to an authorized person when the request requires human authority, sensitive review, a custom decision, or the visitor explicitly asks for a person. The goal is continuation with context rather than forcing the visitor to start over.

Both are protected human-continuation lanes, but they belong to different products. RTD Human Inbox preserves lineage from RTD Chat or Speak sessions.

RTC Handoff Inbox manages visitors who requested or required a person during an RTC conversation.

Yes. The RTD operating guide says to accept the case before the visitor is told that a person joined.

The team can then reply in the protected thread, add internal notes, and keep the operational timeline complete.

Return to Agent means AI can continue the same conversation. Resolved means the requested human work is complete.

Closed means no further response is expected. These states should reflect the real outcome rather than being used only to clear a queue.

No. Conversations is the recorded transcript/history lane.

Handoff Inbox is the operational human-support queue used when a visitor needs a person.

RTD Support Messages are the verified communication channel between the client workspace and WebsDocs. Inbox and Sent remain separate views, and messages are sent through the protected dashboard/service-binding path rather than exposing mail credentials in the browser.

RTC Messages are the verified account communication path between the RTC customer and WebsDocs. They are separate from Human Handoff, which connects the customer's team with its own website visitors.

Use Support for product/service problems, Billing for payment questions, Projects or Maintenance for website/project work, and General for other verified account communication. Keep the subject specific to the RTC account.

Yes. The current ASG dashboard has protected support bootstrap, inbox, sent, send, and reply routes.

The public AI profile does not expose those private messages.

Typical triggers include custom quotes, private account questions, refunds or exceptions, legal or regulated commitments, sensitive complaints, unsupported facts, high-value buyer intent, or an explicit request to speak with the team.

A credit is a product usage unit. The technical work represented by a credit can differ between RTD, RTC, ASG, and Business Automation, so balances should be interpreted inside the relevant product dashboard rather than compared as if every system performs the same work.

No. Each product has its own billing/usage authority and wallet or capacity model.

RTD credits belong to RTD. RTC credits belong to RTC.

ASG live-answer capacity belongs to ASG. Business Automation uses its own Industry credit path internally.

Purchased or top-up credits follow the WebsDocs one-year policy: they are valid for 365 days from the applicable grant or purchase date unless a signed commercial agreement explicitly defines a different treatment.

Eligible older capacity is used before newer capacity. In practice the billing system prioritizes the capacity that should be consumed first, including earlier-expiring and older eligible balances, before moving to newer credits.

Not necessarily. Included plan capacity and purchased top-up capacity can be stored as different grant types with product-specific priority.

The public principle is old eligible capacity first; the product billing authority still decides which eligible grant class is consumed before another.

Not automatically. Included capacity belongs to its plan/service period and can refresh or expire on monthly, quarterly, annual-window, or other product-specific schedules.

The 365-day rule applies to purchased/top-up credits.

Included credits are capacity provided by the active plan for an eligible service period. Top-up credits are separately purchased additional capacity.

They can appear in the same dashboard balance while remaining separate grant records behind the scenes.

Different RTD channels or voice modes can consume the shared RTD wallet differently. The dashboard estimates remaining runtime from the current wallet and active product configuration; the runtime makes the final admission and stop decisions.

One conversation can contain several measured AI calls, and the active operating mode can affect the applicable usage rate. Use Usage & charges to inspect the recorded calls rather than assuming one conversation equals one fixed credit.

Do not assume so. Use the actual usage row and billing record.

The RTC dashboard guide explicitly says the browser should not invent a charge when the authoritative usage/billing data does not show one.

Credits are mainly associated with live answer work such as Ask, deeper Q&A, A2A messages, and buyer-style questions requiring generated responses from approved business knowledge. Static public discovery assets can remain readable without requiring live answer generation.

A blocked or refused request should be checked against the recorded usage event. The FAQ should not promise a charge or no-charge result without the authoritative ASG usage record.

A credit ledger records movements such as grants, purchases, usage debits, adjustments, and other authorized changes. It is useful for reconciling the visible wallet with the events that changed it.

A summary balance can combine several eligible grant records. The ledger or credit-batch history is needed to see whether usage came from included capacity, a renewal grant, a purchased top-up, or another authorized adjustment.

The billing design uses payment references and idempotent grant handling so a verified purchase should not create duplicate capacity simply because a browser retries or reloads. If the payment is visible but the grant is not, support should reconcile the payment and grant records rather than manually duplicating it.

Use the current product pricing and checkout path. This FAQ and the Billing, Credits & Payments page explain the commercial rules but should not become a second hardcoded price catalog.

Checkout creates the payment session and verifies provider payment events. The relevant billing authority owns subscription state, recurring grants, top-up grant decisions, wallet/accounting, and the commercial lifecycle after payment.

No. Payment cadence and commitment duration are separate.

RTC is the clearest example: the monthly option is part of a 12-month service commitment paid in monthly installments.

RTC's current commercial model is an annual prepaid 12-month service term priced as the equivalent of 10 monthly payments. The exact current amount belongs to checkout; the FAQ should explain the structure rather than freeze a price.

Turning off renewal prevents another term from beginning after the current commitment. It does not erase the remaining contracted installments in the active paid term.

Yes when the trial is still in the eligible trial state and the current checkout terms allow cancellation before conversion. The paid commitment is different once paid service begins.

The result depends on the product. The account can move into past-due, grace, recovery, restricted, or review states.

Use the product dashboard/billing recovery route to see the actual status rather than inferring it from a due date alone.

Yes. The current RTC guide keeps recovery access for payment, agreement, and account records even when live service may be restricted.

No. Cancellation controls future subscription behavior.

Refund eligibility asks whether WebsDocs actually failed to provide the paid service for the payment being challenged.

A monthly subscription payment is eligible for refund review when WebsDocs was responsible for providing the paid service, did not provide it, and the failure was attributable to WebsDocs.

If WebsDocs has made the subscribed service active or available, the charge remains valid. Client-side delay, non-activation, non-use, internal postponement, or a decision not to launch does not turn an available service into WebsDocs non-delivery.

That decision can affect future renewal or cancellation, but it does not by itself make an already provided paid period refundable.

Support should identify the product, account, payment or invoice, billing period, provisioning/service state, and the claimed WebsDocs failure. The delivery record matters because 'unused' and 'not provided' are different states.

No universal automatic refund promise is created here. Top-ups, custom commercial payments, and payments under a separate signed agreement should be reviewed against their specific payment record, grant/usage state, and applicable terms.

The RTC dashboard guide keeps the Contract ID, signed agreement, payment history, and audit record preserved. Cancellation should not delete the commercial evidence.

No. A protected dashboard can submit an authorized request, but the billing service validates and applies the actual subscription change.

Browser-side code is not the commercial authority.

Read the period start/end, provider status, renewal state, plan, and next billing action together. A single badge can be incomplete without the associated dates and commercial record.

The sign-in chain uses more than a remembered password. The account email, selected workspace, password, and a fresh verification code help bind the session to the correct authorized user and company.

It is a recent identity check required before a sensitive change such as profile editing, domain changes, team membership changes, subscription actions, branding changes, or security updates. It reduces the risk of a stolen open session being used for high-impact changes.

Yes where the account permissions allow it. The identity password belongs to the email user, while the login flow then binds the session to the selected company/workspace and can require a workspace-specific OTP.

The recovery flow verifies the registered email, issues a short-lived one-use reset authorization, replaces the password, and revokes active dashboard sessions. The new password applies to permitted company workspaces for that email.

Yes. The RTC security guide includes Authenticator as an additional security factor.

Sensitive actions can still require fresh server-side verification.

Yes. The RTD Dashboard guide includes TOTP setup and active-session review.

The authenticator secret is protected server-side and is shown only during setup.

The current ASG dashboard script treats the authenticated portal session as a 12-hour session and shows a countdown/warning before it ends. When it expires, sign in again rather than trying to reuse the expired session.

The ASG Client Portal supports verified email recovery and a recovery mobile. A new mobile method does not become active until its OTP is verified; the system can fall back to the verified email where SMS is unavailable.

Do not share or enter it into an unexpected page. Review active sessions/security events where available and contact support from the verified account if you suspect unauthorized access.

No. The product guides explicitly tell clients not to send passwords, Authenticator codes, email OTPs, API keys, Worker secrets, or other login secrets to support.

No. Public Agent/gateway routes are separated from protected dashboard authentication.

ASG in particular states that public AI routes must not expose private dashboard data, payment records, passwords, admin routes, database content, or confidential customer information.

Branding and profile changes affect customer-facing identity. The dashboards use authenticated uploads and fresh verification so an open browser session cannot silently replace the company's logo, Agent avatar, website origin, or public business facts.

It scans a public website and returns structured evidence about website readiness, visible issues, warnings, category scores, contact/support paths, technical signals, and recommended improvements. It is an assessment, not an automatic website repair.

No. Start with the executive summary, then read critical issues, warnings, affected URLs/assets, evidence, and recommended fixes.

A score without evidence can hide the reason behind the result.

No. The RTD guide says local, private-network, and internal addresses are rejected before the Website Audit service is called.

Use a public HTTP or HTTPS website.

The current RTD Dashboard guide states a workspace may start no more than 10 Website Audit scans in one hour. The dashboard should show the remaining allowance beside the form.

RTC Dashboard scans are limited to the verified RTC account context and approved domains. Use the correct Site and verified website.

No. It records evidence and recommendations.

Maintenance or remediation is a separate project decision.

The ASG Client Portal guide describes Website Health as able to scan safe public websites without requiring normal ASG domain verification. The scan route still applies safety rules and account scan limits.

The current ASG dashboard page describes 10 shared scans in a rolling two-hour window for each ASG account. Use the dashboard's current remaining count as the final operational value.

History lets you compare before/after changes instead of treating one scan as permanent truth. It is especially useful after domain changes, maintenance, accessibility work, performance improvements, or Agent installation.

Send the report reference and the actual findings/evidence that matter. Avoid sending only a score.

The report should show what is wrong, why it matters, affected URLs/assets, and the recommended action.

Include the product, Site/account identity, exact date and time, page or dashboard area, action you attempted, visible error text, and whether one refresh changed the result. Add a screenshot only when it does not reveal passwords, OTPs, tokens, or private customer data.

A focused ticket keeps the account context, evidence, replies, and resolution easier to follow. Separate unrelated billing, domain, and Agent behavior problems unless one is clearly causing the others.

Usually no. Reopen or reply through the existing ticket when the same unresolved issue is still active so the history, references, attachments, and previous investigation stay together.

The payment record answers whether money was accepted. The subscription record answers what commercial state is active.

A wallet/grant record answers what capacity exists. A service/provisioning record helps establish whether the paid service was provided.

A grant adds approved capacity. A usage record measures and debits billable work.

Both can affect the visible wallet but represent opposite directions in the ledger.

Payment verification and credit granting are separate controlled events. Support should reconcile the payment reference and grant/ledger record rather than assuming the payment failed or manually creating a duplicate grant.

The same verified email can have access to several products or company workspaces. The Site/client identity tells support which authoritative subscription, domain, wallet, profile, and activity records to inspect.

No. Support investigates and repairs connected records; it should not replace the service that owns the authoritative payment, agreement, domain, profile, or usage state.

Check that you are using the installation package for the correct domain, the domain is verified, the Site ID and Domain ID match, the loader is placed once in the site-wide template, and the public website is using HTTPS. Then open the Hosted Agent to separate a website-installation problem from an Agent/service problem.

Confirm microphone permission, browser support, the correct embedded/hosted permissions, available RTD wallet capacity, the selected model entitlement, and the verified domain. If using an iframe, keep microphone permission enabled.

Request a new publication code and verify the newest code against the current reviewed payload. Do not try to publish with an expired authorization or an older OTP after resending.

No. The current Studio handles browser popup blocking by keeping the completed result and exposing an Open Published Handover action.

Use the saved handover rather than creating the workspace again.

No. Validate the activation against the correct setup code, registered email, and website.

A mismatch should be fixed before profile creation so the resulting workspace is not bound to the wrong business.

The server checks the active entitlement and domain count. Client-side controls cannot raise the plan limit.

Remove an obsolete domain, use the allowed plan capacity, or request the appropriate plan change.

Confirm the approved profile was successfully published to the Dashboard Worker and synchronized to the runtime package. Then refresh and test the Hosted Agent on the verified domain.

Audio and transcript policy are separate. Confirm the plan/recording entitlement, consent/recording policy, session status, and retention window.

A transcript can exist even when no audio recording was created.

Confirm the case is assigned or accepted, the dashboard session is still valid, and the selected case is not already resolved/closed. Refresh the Human Inbox data before opening a new ticket.

RTC Setup resumes from the server-known setup state. It checks whether publication is complete, the profile is saved, a password is ready, or email is verified and then chooses the next permitted step.

Complete the authoritative missing step instead of forcing navigation.

It closes the current unfinished Setup Studio session in the browser and begins a new activation flow. The setup code explicitly states that this does not delete a published RTC Agent, dashboard account, subscription, billing record, or completed publication.

The setup form compares the new password and confirmation before sending it. Enter the same approved password in both fields and keep the password private.

Enter the newest code before it expires and wait for the server verification response. If a resend occurred, use the newest code.

The next setup stage is opened by the verified server state, not merely by the presence of text in the OTP field.

Check Domains for the exact production origin, complete verification/publication, confirm the Site ID, and then inspect browser Console/Network requests. Localhost success does not prove the production origin is authorized.

Profile saving and knowledge indexing are separate. Confirm the published profile, then use Knowledge Search and deliberately run Feed Agent when the approved change needs to be indexed.

The account plan or current policy may not permit that operating mode. Browser changes cannot grant a mode that the server entitlement does not authorize.

Open Billing and Subscription. Check the actual payment status, grace/recovery state, current period, and required payment action.

A due date alone is not enough to diagnose recovery.

Refresh the Agreement area and use the repair action only when the agreement exists but the dashboard status is disconnected. Resend should deliver the existing agreement rather than silently create another contract.

No. The ASG setup guide explicitly warns against duplicate setups while payment confirmation or approval is processing.

Keep the same protected setup record and wait for or resolve the authoritative next action.

No. Use the newest OTP after a resend.

Both validation and final publication flows are designed around the current code/challenge state.

Profile-changing actions can require fresh OTP/TOTP verification. The lock is a safety boundary so an old dashboard session cannot silently change public business identity, contact details, or publication state.

Yes. The current dashboard has a limited/recovery mode in which live AI answers and profile changes can be paused while Billing, history, security, support, and reactivation remain available.

Some panels depend on separate backend workers or bindings such as Billing, Checkout, Email, Event Hub, Setup, or Website Audit. Check the panel's status and connected authority before rewriting front-end code.

Normal business-domain verification is separate from the hosted ASG identity. The hosted profile can remain available even when a normal domain is unverified; a custom ASG hostname has stricter verification requirements.

The current dashboard design keeps the client identity, client slug, billing site ID, payment customer, and subscription while updating the website/domain reference and related compiled/public origin records.

Check the top-up payment reference, grant history, available balance, and older eligible credits. A summary balance can combine multiple grants, and old eligible capacity is consumed before newer capacity.

No. If WebsDocs made the paid service active or available, client non-activation or non-use does not make the charge refundable.

Refund eligibility begins when the paid service was not provided because of a WebsDocs failure.

Not necessarily. RTD and other dashboards can keep the secure session active while one optional panel fails.

Retry or refresh the affected panel first; sign in again only when the session itself has expired or authentication is rejected.

Refresh the affected panel once, confirm the correct account/workspace, record the visible error and time, and check whether the underlying billing/domain/profile/support authority reports a specific state. Then send a focused support report with the Site/client identity.

Check the approved profile first. For RTC, also check Knowledge Search/indexing.

For RTD, confirm profile publication and the correct Domain Agent. For ASG, confirm the public profile/FAQ and publication status.

Fix the authoritative knowledge source before changing visual code.