Register if new, or log in
Open the Owner Portal. New owners use Registration with owner name, email, mobile, password, business name, and first domain. Existing owners use Login with email and password.
Owner operations guide
Set up your website’s AI operating layer with confidence.
A clear owner guide for launching BoloSite safely: verify your account, approve knowledge, map actions and forms, install one script, test on mobile and desktop, then monitor usage from the portal.
Same existing websiteOne embed scriptApproved answers onlyVerified actions and formsBilling visibility
Launch control roomOwner workspace
Copy Script ReadyKnowledgeReady
ActionsVerified
DomainLive
Approved setup progress82%
Website facts approvedForms mapped and testedBilling visibility active
Quick start
Your complete launch checklist.
Complete these steps in order. Test each approved action before inviting real visitors.
Verify email and mobile
Dashboard access starts after both contacts are verified. Send the email OTP, confirm it, then save/send the mobile OTP and confirm it. This protects the owner account and future password recovery.
Review profile and security
Open the profile card from the sidebar. Check owner name, business name, email, mobile, account status, site ID, primary domain, and last login. Change password from the dedicated security form.
Add the website domain
Enter the exact production host. Only verified domains are added to the runtime allow-list.
Set the assistant identity
In Settings, choose the project name, assistant name, default language, and welcome notes. The current wake words “Hello” and “Hi” are admin-controlled.
Add website and sales knowledge
Paste content, upload a source file, or crawl an approved URL. Keep product, policy, price, contact, and support information clear and current.
Build the knowledge index
Save content and build RAG. Wait for completion before judging the assistant’s answers.
Review intents
Create or auto-build actions, then inspect the trigger phrases, action type, target, fallback, verification status, and enabled switch.
Map and verify forms
Confirm the form selector, field selectors, required fields, intent names, and submit action. Save only after the mapping matches the real website.
Install the embed script
Copy the generated script and place it just before the website’s closing </body> tag.
Test like a real visitor
Test wake, voice, text, information, navigation, unsupported requests, form corrections, and confirmation on desktop and mobile.
Know recovery and logout
If you forget the password, use the registered email and mobile, confirm both OTPs, then set a new password. Always log out on shared or owner-office devices.
Monitor and maintain
Review logs, current usage, wallet, payments, invoices, service status, and content changes after launch.
Before you configure
Three rules keep the experience useful and safe.
Knowledge must be approved
Add only information your business is comfortable presenting to visitors. Remove outdated offers, prices, and policies.
Actions must be verified
Do not enable an action because its name looks correct. Test the target selector, page, section, or URL on the live domain.
Visitors keep control
Provide text as an alternative to voice, ask visitors to review form data, and keep sensitive or destructive actions outside ordinary automation.
Account and security
Start with a verified owner account.
BoloSite uses the owner account as the control room for knowledge, actions, forms, billing, and launch code. Keep this account accurate and protected.
Registration for new owners
Use the Registration tab when the business is new to BoloSite.
- Enter owner name, email, mobile number, password, owner/business name, and first domain.
- Submit the form to create the owner profile and workspace.
- Continue to email and mobile verification before dashboard access.
Login for existing owners
Use the Login tab with the registered email and password.
- If both contacts are verified, the dashboard opens.
- If verification is incomplete, BoloSite asks for email and mobile OTP confirmation.
- If the password is forgotten, use the Forgot Password flow.
Email and mobile OTP
Both contacts are required because the account controls live website behavior and payments.
- Send email OTP and enter the 6-digit code.
- Save or confirm the mobile number, then send SMS OTP.
- After both are verified, login completes automatically.
| Security moment | What BoloSite checks | Good owner habit |
|---|---|---|
| OTP request | A fresh code is sent to the chosen verified target. Re-requesting too quickly can be blocked for a short cooldown. | Wait at least a minute before requesting again, and check spam/SMS delivery first. |
| OTP lifetime | Codes are time-limited and are meant for one verification flow. | Use the newest 6-digit code quickly. Do not share it with staff, vendors, or support chats. |
| Wrong code attempts | Repeated wrong attempts can require a new code. | If a code fails, request a new one instead of guessing. |
| Password reset | Reset needs the registered email, registered mobile, and both OTPs. | Keep both contact details updated in Profile so account recovery works when needed. |
What you can manage in Profile
Open the sidebar profile card to view the site ID, account status, primary domain, registration date, and last login. You can update owner name, business name, email, mobile, and password.
- Changing email or mobile needs the current password.
- Changed email or mobile becomes unverified until the new OTP is confirmed.
- New passwords must be set from the Change Password section.
- Password reset needs registered email, registered mobile, and both OTPs.
- Use Logout when working on a shared device.
It protects the person who controls the website AI.
Without verified contacts, a wrong email or mobile could block recovery, billing alerts, and sensitive profile changes.
Do not share portal login details.
Give portal access only to trusted business operators. Do not place the server admin token, payment secrets, or private credentials inside website code.
Domain and runtime safety
Let the assistant run only where it belongs.
In this portal, “verification” means the workspace is tied to approved domains and runtime credentials. It is not a pure visitor-IP lock.
Add the real hostname
Use the exact website host, such as example.com, www.example.com, or a staging host. Avoid unrelated page paths.
Verify the domain
Verified domains are written to the runtime allow-list. This helps prevent another website from simply reusing your owner script and token.
Install only after verification
Copy the embed script from the same workspace and place it on the verified domain. Test the assistant from that domain after deployment.
Remove unused domains
If a staging URL, old domain, or owner preview link is no longer needed, delete it from Domains so the allow-list stays tight.
Honest security note about the embed script
The loader reads the site ID and token, verifies runtime access, then cleans those data attributes from the original script tag. That is a useful hardening step, but browser-side code is never a private vault.
The real protection is layered: verified domains, site/token validation, server-side runtime checks, no admin credentials in public code, and removing unused domains quickly.
Full portal reference
What every owner-facing area controls.
Use Overview for the health check, then work through Domains, Content, Intents, Forms, Embed, and Settings.
Overview
A fast status board for the workspace.
- RAG chunk count shows indexed knowledge volume.
- Working intents shows usable approved actions.
- Verified domains confirms runtime access.
- Trial days left shows onboarding time.
Domains
Controls where the assistant is allowed to run.
- Add the hostname, without an unrelated page path.
- Check verification status before installing.
- Use separate entries for different hosts when required.
- Remove domains that no longer belong to the project.
Content and RAG
Supplies the facts used in answers.
- Website knowledge: pages, FAQs, policies, navigation.
- Sales knowledge: plans, objections, offers, qualification.
- Upload approved source files or crawl approved URLs.
- Save, build RAG, then retest representative questions.
Intent Builder
Controls approved website actions.
- Use two or three natural trigger phrases.
- Choose scroll, click, navigate, or the correct action type.
- Set a valid ID, selector, or URL target.
- Write a clear fallback and verify before enabling.
Forms
Maps conversational writing to visible website fields.
- Review form selector and submit action.
- Match every field name to a real CSS selector.
- Mark only genuinely required fields as required.
- Verify mappings and test correction plus confirmation.
Embed Code
Connects the approved workspace to the website.
- Copy the script from the correct workspace.
- Place it before the closing body tag.
- Deploy it only on a verified domain.
- Never publish server admin credentials in website code.
Billing and Payment
Shows the operational source of truth for costs.
- Review current usage, wallet, account status, and limit.
- Inspect the usage breakdown before adding funds.
- Track invoices and payment history.
- Use the portal and published pricing section for current rates.
Usage Logs
Helps you understand real visitor activity.
- Load recent activity when diagnosing behavior.
- Review time, action, visitor reference, and page.
- Use More and Show Less to move through results.
- Avoid treating logs as a place for unnecessary personal data.
Settings
Defines how the assistant introduces itself.
- Project name and assistant name.
- 14-language default language, including Hindi, Hinglish, Indian English, English, Bengali, Marathi, Gujarati, Tamil, Telugu, French, German, Russian, Japanese, and Mandarin Chinese.
- Language-specific welcome notes.
- Runtime base URL and private project notes.
Profile and Security
Keeps owner identity and account access current.
- Update owner and business information.
- Verify changed email or mobile details.
- Use the current password for sensitive profile changes.
- Change passwords from the dedicated security section.
Content and RAG
Teach BoloSite what it can trust.
Keep facts clean, approved, and current before expecting sharp answers from the assistant.
Website knowledge
Public information visitors ask for: services, products, support, policies, locations, FAQs, contact details, and page navigation.
Sales knowledge
Conversion context: plans, offers, objections, comparisons, demo rules, lead qualification, and approved sales language.
Why build RAG
Saving updates source text. Building RAG prepares searchable chunks so answers use the latest approved content instead of stale notes.
Paste manual content
Write clean text directly into Website knowledge or Sales knowledge, then click Save Content. This is best for curated policies, pricing notes, and sales scripts.
Upload a file
Choose a file, select Website or Sales, and click Upload. The portal stores it in the correct owner content area and queues a RAG rebuild.
Crawl a URL
Paste an approved HTTP/HTTPS page URL, choose Website or Sales, and click Crawl. Review the result, because crawled pages may contain menus, old text, or duplicate content.
| Small detail | How it works | Why owners should care |
|---|---|---|
| Readable source types | Text-like files such as TXT, Markdown, CSV, JSON, HTML, and HTM are readable for dashboard/RAG content. | Use clean text files when possible. PDFs/images should be converted into approved text first. |
| Upload size | The portal has an upload size limit controlled by the server, with an 8 MB default in this project. | Split huge documents into smaller focused files so answers stay precise. |
| Auto-build pages | The Auto build Pages field accepts 1 to 12 pages, with 6 as the default UI value. | Start small, review the generated intents/forms, then crawl more pages only when needed. |
| HTML auto-build | Uploaded HTML is parsed for readable text, selectors, links, buttons, and forms. | Use a current page export; old HTML can generate stale selectors. |
| Rebuild queue | Save, upload, crawl, and auto-build can start a background RAG rebuild. If one is already running, a second one may be queued/ignored until it finishes. | Wait for rebuild completion before judging answer quality. |
| Stale index behavior | If content changed but RAG has not rebuilt yet, the assistant may still use the previous index temporarily. | After important pricing/policy changes, manually click Build RAG and retest. |
Best practice: save, build, then retest
After any content change, click Save Content or complete Upload/Crawl, then use Build RAG if you need an immediate rebuild. Ask real visitor questions afterwards: pricing, contact, refunds, product fit, support steps, and anything that recently changed.
Do not keep old copied prices or expired offers in source text. The portal Billing area and published website pricing section should remain the source of truth for cost-related details.
Intent quality
Build actions from the visitor’s words to a tested target.
Write natural triggers
Example: “show pricing,” “open plans,” and “take me to pricing.”
Choose the correct behavior
Scroll to a section, click a control, or navigate only when that outcome is intended.
Use a real ID or selector
Copy it from the current website and test it at desktop and mobile sizes.
Verify, enable, and save
Keep generated or uncertain actions disabled until a human checks the result.
| Portal field | What it means | Owner check |
|---|---|---|
| Intents / aliases | Natural trigger names for the same action, separated by comma or new line. | Use exactly 2 to 3 aliases, such as pricing, show_pricing, open_plans. |
| Action | The approved behavior BoloSite can perform. | Choose from scroll, click, openModal, closeModal, callFunction, fillField, or navigate. |
| Target Type | How BoloSite finds the destination. | Use id, class, selector, function, or url according to the action. |
| Target | The real section ID, CSS selector, function name, or URL. | Copy it from the current website and test it. A wrong target can make a good command fail. |
| Fallback | Short visitor-friendly message if the target cannot be opened. | Write what happened and what the visitor can try next. |
| Status and On | Verification state and live switch. | Auto-built or edited intents stay off until saved, verified, and enabled. |
Start from URL or HTML file
Use Crawl + Build to generate likely intents and forms from a website URL or uploaded HTML file. Auto-built items are drafts: review names, action type, targets, confidence, and fallback before enabling.
Add missing actions yourself
If auto-build misses a section, modal, button, form, or page, click Add Intent. Choose the right action and target, then save and verify it before turning it on.
Match action to target type
Scroll/click/modal/fill actions use ID, class, or selector. Navigate uses URL. Call Function uses a function target that exists on the page.
Changed actions become unverified
When aliases, action type, target type, or target value changes, the intent should be treated as a new draft. Save it, verify again, then enable.
The safest intent workflow
Auto-build or add intent → review missing/incorrect actions → keep 2-3 aliases → choose action and target → save → verify → enable → test from the real website.
Built-in actions you do not need to recreate
BoloSite already understands common base controls such as scrolling up/down, going to the top or bottom, returning home, switching theme/light/dark mode, and choosing no action when the visitor only needs an answer.
scroll_downscroll_upgoto_topgoto_bottomhomego_homethemelight_modedark_modenone
Create custom intents only for business-specific actions: opening a pricing modal, jumping to a product section, starting a form, navigating to a policy page, or calling a verified page function.
Form operations
Map fields carefully, then test the conversation.
A form is ready only when BoloSite can open it, fill the right fields, change a value, and wait for visitor confirmation.
Verification checklist
- The form selector points to one visible form.
- Every field key maps to the intended input, select, radio, checkbox, or textarea.
- Required fields match the website’s real validation.
- The submit action points to the correct safe submission path.
- Passwords are never repeated in assistant response text.
- The visitor can update a field or cancel.
- The visitor reviews the form before confirming submission.
FORM MAPPING PREVIEW
Field nameemail
Selectorinput[name="email"]
RequiredYes
StatusMapped
Auto-detected or manual form
Auto-build can discover forms from a URL or HTML file. If the form is missing, click Add Form and name it clearly, such as contact_form or demo_form. Use Remove Form only when that website form should no longer be filled by BoloSite.
Add, remove, and require fields
Use Add Field for each real input the assistant may fill. Use Remove Field for fields that should not be collected conversationally. Mark only genuinely required website fields as required.
Match the real HTML
Form selector should point to the actual form. Field selectors should point to the exact input, select, checkbox, radio, or textarea. Wrong selectors create silent failures.
Save, verify, then test
Save Forms after editing. Verify one form or all forms, then test opening the form, filling values, correcting values, cancelling, reviewing, and confirmed submission.
| Form area | How owners should use it | Best practice |
|---|---|---|
| Form name | Stable internal name for the form flow. | Use simple lowercase names with underscores, such as contact_form. |
| Form intents | Voice/chat triggers that start form writing. | Keep 2 to 3 useful triggers. These are connected to Intent Builder and can affect the related form intent. |
| Field list | Allowed field names the writing engine may fill. | Use clear names like name, email, phone, message. |
| Required | Fields the visitor must provide before submit. | Match the website validation. Do not force optional fields unless the business needs them. |
| Field labels and aliases | Optional metadata can make field prompts friendlier and help BoloSite understand alternate names. | Add aliases for common visitor words, such as phone/mobile/WhatsApp, only when the field really matches. |
| Field options | Dropdown/radio style fields can carry allowed options when the schema has them. | Keep options current when the website choices change. |
| Sensitive fields | Password-type fields are treated as sensitive and should not be repeated back in assistant response text. | Avoid conversationally collecting sensitive fields unless the website flow truly requires it. |
| Advanced schema JSON | Manual correction area for exact form schema, selectors, required fields, and mappings. | Edit carefully only when the visual form cards need precise selector or field-name correction. |
Forms and intents are connected
When you save forms, BoloSite syncs related form intent records. A form becomes available to the writing flow only when its linked form intent is active, verified, and points to a usable form or field selector.
If you edit form triggers, selectors, or form structure, review the linked intent state in Intent Builder before launch.
The safest form workflow is: create or detect form → map fields → set required fields → save → verify → test correction and confirmation → launch.
Copy from the right workspace
Use Copy Script from the top bar or Embed section. The snippet contains the workspace loader, site ID, and runtime token for that owner.
Paste before </body>
Add the script near the end of the page, after normal website content. This lets the assistant load without requiring a full website rebuild.
Deploy and test on a verified domain
Open the live or staging domain, wake the assistant, try text chat, test approved actions, and confirm the runtime base URL is correct in Settings.
Embed token hygiene
Do not paste admin tokens, payment secrets, database credentials, or server environment values into the website. The public embed snippet is only for loading the assistant on approved domains.
Settings and assistant identity
Personalize the assistant without changing the locked safety parts.
Settings control how the assistant introduces itself, which language it prefers first, and which runtime URL the embed script uses.
| Setting | What it controls | Owner guidance |
|---|---|---|
| Project name | The workspace/display name for this website project. | Use the public business or website name visitors recognize. |
| Assistant name | The name used in the assistant experience. | Keep it short and friendly, such as “BoloSite AI” or the brand assistant name. |
| Wake word | The current wake words are locked by admin/runtime logic. | Owners can personalize welcome notes, but should keep “hello” or “hi” instructions visible. |
| Default language | Initial language preference for welcome and assistant behavior. | Choose from the 14 supported languages according to the expected visitor audience. |
| Welcome notes | Opening message in each supported language. Each note is limited in length. | Keep it direct: greet, explain how to start, and mention “hello/hi” or the mic button. |
| Placeholders | Runtime can replace helpful placeholders inside welcome text. | Use {wake_word}, {assistant_name}, or {project_name} when you want reusable wording. |
| Runtime base URL | The backend origin used by the loader script and generated embed code. | Change only when the BoloSite backend domain changes, then copy the new embed script. |
| Project notes | Private operational notes stored with the workspace. | Use for setup context. Do not store passwords, OTPs, payment secrets, or admin tokens. |
Save Settings refreshes runtime files
After saving, the portal regenerates the workspace output files used by the live assistant. Retest the welcome message and embed code after changing runtime URL or language.
Language can still adapt
The default language sets the starting preference, but visitor messages can still be handled in natural Hindi, English, or Hinglish when the runtime supports it.
Welcome note must teach activation
If the note forgets the wake instruction, the backend adds a safe “say hello/hi or tap mic” style instruction so visitors know how to start.
Billing and payment
Understand usage before it becomes an operational surprise.
The portal Billing & Payment section is the live source for current usage, wallet, account status, warnings, invoices, and payment history.
Current usage
Shows the running bill for the selected month and the usage breakdown.
- Base platform line item.
- Billable request count.
- Total current bill.
- Wallet auto-deducted amount.
- Net overage due if applicable.
Wallet balance
The wallet helps cover usage automatically when available.
- Use Add Funds to top up.
- Wallet changes appear after secure verification.
- Check alerts if balance or credit status needs attention.
Account status
Shows whether the workspace is active, trial, or payment-required.
- Trial days left appears during onboarding.
- Warnings explain usage or payment issues.
- Service state should be checked after payments.
| Payment step | What happens | Owner action |
|---|---|---|
| Add Funds | Enter the top-up amount and choose UPI/QR or bank transfer. | Use the amount needed for expected usage. Do not rely on old copied prices; check portal and website pricing. |
| UPI / QR with Razorpay | A secure checkout/QR can be created and server-verified. No UTR is needed for this path. | Open checkout or scan QR, then wait for automatic verification and wallet update. |
| Bank transfer | The order stays pending until a UTR/reference is submitted and verified manually/admin-side. | Complete the bank transfer, enter UTR, add an optional note, and wait for verification. |
| Payment status | Pending means waiting; Verified means wallet credited; Failed or Cancelled means create a new order if needed. | Use Check payment status or refresh Billing. Verified payment details can be opened from Payment History. |
| Invoices | Invoices show billing month, amount, and status. | Use invoices and payment history for reconciliation, not chat notes or screenshots alone. |
| Operational detail | What happens | What to do |
|---|---|---|
| Trial period | Usage is still tracked during trial, but billing restrictions are disabled while trial is active. | Use the trial to test realistic traffic and verify the expected monthly usage pattern. |
| Warning levels | The billing dashboard can warn around high credit usage, including warning and critical levels. | Top up wallet before visitors hit a payment-required state. |
| Payment required | If uncovered usage exceeds the allowed credit and wallet coverage, service can move to payment required. | Add funds or contact the administrator to restore service if needed. |
| Razorpay auto-check | Secure checkout/QR payments are checked automatically for a few minutes and can also be reconciled manually from the portal. | Wait for “Payment verified and wallet updated” before assuming the wallet is credited. |
| Closing payment view | A pending Razorpay payment link may be cancelled/expired when the payment view is closed. | If you close before paying, create a fresh payment order. |
| Bank UTR | Bank transfer requires a valid transaction reference and manual verification. | Enter the UTR/reference after payment, then wait for verified status. |
!
Admin controls are administrator-only
Wallet adjustment, manual payment verification, forced service restoration, invoice generation, and disputes require the server admin token. Ordinary owners should not request or store that token.
Logs and diagnostics
Use logs to improve the assistant after real visitors arrive.
Logs are for operational debugging and product improvement. They should not become a place to collect unnecessary personal data.
Load recent activity
Click Load Logs to see the latest runtime entries for this site ID. The table shows time, action/event, visitor reference, and page.
Use More and Show Less
The first load shows a small recent set, More loads additional entries, and Show Less returns to a compact view for quick diagnosis.
Look for patterns
Repeated “no answer,” unsupported actions, wrong pages, or repeated visitor wording usually means content, intent aliases, or selectors need improvement.
| What to inspect | Possible meaning | Best follow-up |
|---|---|---|
| Many similar questions | Visitors are asking for something your knowledge should answer directly. | Add a clean FAQ or policy block, rebuild RAG, and retest. |
| Actions not opening | The target ID, class, selector, function, or URL may be wrong after a website change. | Update the intent target, save, verify, enable, and test again. |
| Form flow stops | A required field, selector, field option, or submit action may be incomplete. | Open Forms, verify mapping, test correction, then verify the form intent. |
| Billing or service warnings | Usage may be near the monthly credit limit or payment may be required. | Open Billing, review warnings, add wallet funds, or contact admin if service restoration is needed. |
Behind the scenes
What the portal regenerates after you save changes.
Owners normally use the portal, not server files. Still, knowing what changes behind the scenes helps you understand why Save, Verify, Refresh, and Build RAG matter.
| Generated area | Purpose | Owner takeaway |
|---|---|---|
client_data.json | Workspace metadata, owner-visible config, domains, content references, intents, forms, uploads, billing snapshot fields. | Portal state is mirrored into owner workspace files after save/refresh. |
runtime_config.json | Runtime identity: assistant name, project name, language, welcome notes, status, enabled flag, domains, runtime URL. | Settings and domain/status changes affect what the live assistant loads. |
intents.json and executor.js | Approved actions and the browser-side behavior used to scroll, click, navigate, call functions, or open forms. | Wrong selectors or unverified intents lead to visitor-facing action failures. |
forms.json, agentConfig.js, and writting.py | Form schemas, active form mappings, field rules, and writing-mode instructions. | Forms only work well after schema, intent, field map, and submit flow are all verified. |
prompt.py | Owner-specific prompt rules and supported active intents used by the AI backend. | Only enabled/verified actions should be treated as available runtime actions. |
website_texts, sales_texts, rag_data.json, and rag_hash.txt | Approved knowledge sources, built RAG chunks, and the content hash used to detect stale indexes. | Content changes need a RAG rebuild before answer quality can be judged. |
Portal-first rule
Use the Owner Portal for normal edits. If a developer edits files directly, click Refresh in the portal afterward and test carefully, because the portal can sync safe editable files back into dashboard state.
Pre-launch test
Test the experience, not just the script.
Use a private or staging release first, then repeat critical tests on production.
Voice and wake
Test “Hello/Hi,” mic permission, listening colour, interruption, noisy-room fallback, sleep, and wake again.
Desktop + mobileText panel
Test double-click/tap, typed messages, mic off, history, close, answer playback, and regenerate.
Keyboard + touchKnowledge answers
Ask product, price, policy, support, and impossible questions. Confirm answers stay inside approved knowledge.
Expected + unknownNavigation actions
Test each enabled intent at multiple screen sizes and confirm the target is visible and correct.
Every enabled intentForm writing
Test field order, multi-field input, corrections, invalid values, cancel, review, and confirmed submit.
No surprise submitOperations
Refresh Overview, load logs, check usage, confirm account status, and verify billing visibility.
Portal source of truthAfter launch
Keep answers and actions healthy.
When should knowledge be updated?
Update it whenever pricing, plans, products, policies, contact details, support steps, or important website pages change. Rebuild RAG and retest afterwards.
What should be checked after a website redesign?
Recheck every action target and form selector. IDs, buttons, modal triggers, page paths, and field names often change during redesigns.
How should logs be used?
Look for repeated questions, unavailable actions, and confusing visitor language. Improve content and approved triggers without collecting unnecessary personal data.
Where should billing details be checked?
Use the Billing and Payment area for current usage, wallet, account status, invoices, and payment history. Use the published website pricing section for the current public model.
!
Admin Controls are not part of normal owner setup
Wallet adjustments, manual payment verification, forced service restoration, and manual invoice generation require a server admin token. Ordinary owners should not request, store, or expose that credential.
Useful next links
Go from the guide to the work.
Open Owner Portal
Configure the real workspace, domain, knowledge, actions, forms, and billing.
Open portal →Read the Visitor Guide
See the exact visitor experience, orb states, text controls, and writing flow.
Open visitor guide →Watch Owner Video
Follow the detailed portal and setup walkthrough.
Watch guide →Go to Website Guide
Review the website owner section and how BoloSite fits into an existing site.
Open website guide →View Pricing
Use the published pricing section and portal billing area as the current source of truth.
View pricing →Open Billing Section
Jump back to wallet, usage, invoices, payment status, and top-up instructions.
Read billing →Open Embed Section
Check script placement, verified-domain safety, runtime base URL, and token hygiene.
Read embed steps →Open Settings Section
Review assistant name, language, welcome notes, placeholders, runtime URL, and project notes.
Read settings →Open Logs Section
Learn how to diagnose repeated questions, failed actions, form issues, and billing warnings.
Read logs →Runtime Files
See what the portal regenerates behind the scenes after save, verify, refresh, and build RAG.
View files →About BoloSite
Review the product vision and benefits for visitors and website owners.
Explore the website →Ready to configure your workspace?
Open the portal, complete the checklist in order, and verify every visitor-facing action.