Define the service you are handing over.
Document the client’s website, intended visitor questions, public information sources, and the follow-up channel. Decide whether the agency or client provides live chat coverage and who handles the offline queue.
Separate the agreed commercial service from product configuration. Removing attribution, editing an accent or serving a client’s help centre from their own domain does not establish a reseller contract or a response-time commitment. Agree those in writing.
Use project boundaries from the beginning.
Create the client project within the agency workspace, then add the client’s sites to that project. Keep origins and names unambiguous so someone copying an installation snippet can identify its destination.
Invite client viewers with a specific project scope. Grant content contribution only where appropriate. Agency members who need broader operational access should receive it deliberately rather than sharing a staff login.
| Responsibility | Record |
|---|---|
| Website access | Who can publish the snippet and complete DNS or file verification. |
| Knowledge approval | Who confirms business details and approves saved answers. |
| Live chat coverage | Which eligible specialists cover the site and who checks offline requests. |
| Enquiry handling | Who reviews the inbox and completes external follow-up. |
| Configuration | Who may change branding, behavior, live chat, and installation settings. |
| Commercial administration | Who can request plan, model, or allowance changes. |
Make the business approve the facts.
Ask the client to review opening hours, service areas, contact routes, prices, and relevant conditions against its current website. Keep an explicit list of questions the assistant should leave to a person.
A shared design or similar business type does not make two clients’ information interchangeable. Test the same plausible question against each site when their policies differ, and confirm that answers come from the correct source.
Use a pilot and an acceptance record.
Install on the intended published site and run a repeatable test set: known information, missing information, a request for a human, and contact collection using details your team controls. When live chat is enabled, test with a specialist online and offline and confirm the queue belongs to the correct client site.
Record the result and any outstanding issues. A demo is useful for initial evaluation, but it does not replace ownership verification, full source review, or testing the client’s actual production layout.
Example acceptance record
Client project · published origin · installed public site key · approved source set · tested questions · known limitations · responsible owner · date reviewed. Keep credentials out of this record.
Give ongoing review a predictable place.
Set a routine for reviewing conversations, knowledge gaps, and lead follow-up. Make one person responsible for checking whether source changes require new approved wording or a retest.
Review usage before adding another site or expanding a crawl. Standard plans and custom allowances should be discussed with the administrator who manages the workspace, especially when a new client has substantially different content or traffic.
Recheck access when the relationship changes.
When a client contact leaves or an agency member changes responsibility, update membership and project scope. Keep an active owner responsible for the workspace instead of depending on an account nobody can maintain.
For a redesign or domain move, revisit the installation point, allowed origin, verification, and branding. Treat an ownership transfer or offboarding as an explicit administrative process; do not assume removing a script deletes the stored workspace records.
Document whether each client team will use Ask Sairo or a connected AI application. Project permissions apply to both. Start external connections with the smallest useful website scope, and reconnect when a member’s project or site access changes.