What you need#
You need access to the email used for your Reesponder account, an active plan or a valid access grant, and owner or admin access to the workspace. You also need permission to publish changes to the customer-facing website. Keep your public website address separate from its administration address: Reesponder connects to the domain visitors actually use.
All plans use the same underlying AI intelligence. Core supports one website; Business and Scale support multiple websites. Start with the plan comparison if you have not activated access yet.
Connect the customer-facing domain#
- Sign in at app.reesponder.com and open Websites.
- Under Connect a domain, enter a Website name and Domain, such as
example.com. - Select Start automatic setup. Reesponder queues a website crawl automatically.
- Open the new website to follow its installation and Knowledge status.
If you use several workspaces, check the workspace selector before adding the domain. Each website, its sources and its conversations belong to that workspace.
Check the information behind the answers#
Open the website's Knowledge tab. Wait for the crawl to complete, then inspect the website source and its documents. A processed page count tells you how much usable content was collected; it does not prove that every product, policy or contact detail was captured.
Add missing verified facts through Add entry. Use website scope for information specific to that business or domain. Use shared workspace Knowledge only when a fact genuinely applies to every website in the workspace.
Publish and verify the installation#
Open Installation and follow the method shown for the website. A manual website uses the generated snippet in a shared template before the closing </body> tag. Shopify storefronts use their theme snippet. WordPress websites can use the downloadable plugin and workspace connection flow.
Publish the change, clear the website's page cache if necessary, and open the public website. Reesponder marks the installation as detected after a valid widget check from the configured domain. Saving code in an editor alone does not verify installation. The illustrated installation guide shows the complete flow.
Use preview and live checks for different questions#
Use Private test during source preparation to review answer quality without consuming customer conversations. Its five-question preview uses the site's current Knowledge. Choose questions that test the business facts and nearby exceptions rather than relying on a successful greeting.
Then use the actual public widget for page relevance, appearance and any configured handoff or connected operation. Keep those launch claims separate: a correct preview policy answer does not establish installation or private-record authorisation. The release checks below provide a practical acceptance record across the relevant surfaces.
Worked first release: public answers before live orders#
A small retailer has approved delivery and returns pages but has not completed its order-system integration. The first release connects the public storefront, reviews those collected policies and tests the normal rule and its exceptions. A named content owner handles policy changes. The website's ordinary contact details remain available for private order questions.
An order-status question receives the real tracking or contact route that the business supports; it does not claim a live order lookup exists. Later, the business can configure an authorised Action, test ownership boundaries and add that capability deliberately. The useful first release has a clear purpose and truthful limits, so the unfinished integration does not need to block every public-policy answer.
Record who owns the customer-facing release#
Before launch, record the connected domain, source maintainer, installation maintainer and the business contact responsible for questions that need a person. Confirm that these people know which workspace contains the website. A second workspace or a similarly named domain can otherwise make later edits reach the wrong site.
Keep an explicit list of the capabilities you have configured and the ones you have deferred. The acceptance test below checks the release you are making, while this ownership note explains who will keep it working. Do not record passwords, private preview tokens or customer records in the launch note.
Decide what your first release should actually do#
Begin with the questions your business can answer reliably today. A small shop might choose delivery destinations, return conditions and product care. A service business might choose opening hours, appointment preparation and the correct enquiry route. Write down the public source for each answer before you connect the website. If two pages disagree, resolve the business policy first; a successful crawl cannot decide which promise the business intends to honour.
Separate explanation from live operations. Saying how order tracking works can come from a policy page. Reporting the current state of a particular order needs an authorized live lookup. Submitting a support request needs the correct enabled workflow, and changing a connected record needs an eligible write Action with customer confirmation. Installing the chat does not connect these systems automatically. It is reasonable to launch useful public answers first while your team finishes the private integration.
Assign an owner to the release. That person should know which domain is being installed, which Knowledge applies to it, who maintains the information and who receives a human request where that feature is enabled. Keep a short launch sheet with these decisions. It will be useful when you change a theme, publish a new returns policy or add a second website. An assistant maintained by nobody can keep repeating a formerly correct policy long after the business has changed it.
Run a small but realistic acceptance test#
Use questions a visitor would naturally ask, rather than copying the headings of your policies. For delivery, try a destination and a timing constraint. For returns, try an unopened item, an exception and a request outside the published policy. For a product, try a fact present on the page and a fact your business does not provide. Record the expected source and outcome alongside the actual answer. A fluent reply is not a substitute for factual agreement with your business.
Use Private test while editing Knowledge, then repeat representative questions in the installed public widget. The private preview does not prove current-page behaviour, customer context, connected Action execution or the handoff form. Those depend on the live integration. Test a second important route as well as the homepage, and open the site on a phone. Confirm that the launcher is reachable and that the conversation does not obstruct an essential page control.
Keep test inputs synthetic or use your own authorized details. A private order test should include an ownership mismatch as well as a successful owner lookup. A write test should include cancellation before confirmation. A handoff test should use a mailbox your team can monitor. These are different checks and should have separate pass/fail notes. If a feature is not yet configured, document it as unavailable instead of assuming that a good public-policy answer proves the whole release is ready.
What to monitor after publication#
After the first real conversations, review what customers actually ask. Look for missing information, contradictory policies and questions that need a connected system. Add verified facts to Knowledge; do not paste a customer suggestion into the library as if it were an approved business policy. Repeated unanswered questions can tell you what to write next, but someone at your business still has to decide the correct answer.
Watch the active usage period in Overview and Billing. All websites in a workspace share its available conversation units. Opening the launcher is different from creating a billable conversation, and a long thread can consume additional answer groups. Review automatic top-ups before a traffic campaign so the payment behaviour matches your business decision. The current Pricing page and Billing view are better budgeting references than the number of chat bubbles on one test page.
Treat changes as small releases. After editing a fact, test the affected answer. After changing a theme, revisit installation detection. After adjusting an Action, save and test its current revision before enabling it again. After shortening retention, check the stored-until date on a new conversation rather than assuming every older record was rewritten. Keep the launch sheet current and include the date of your last check. This makes a later support investigation specific: the team can identify which configuration changed and which part of the experience was last known to work.
Need help with this?
Tell us which website, guide and step you are working on. Keep passwords and private customer details out of the message.