White Label Chatbot Client Offboarding Runbook

TL;DR

• Build an asset-and-access register before changing the workspace, deployment, integrations, records, or credentials.
• Freeze nonessential changes and reconcile the register against the live deployment.
• Verify export, transfer, archive, deletion, and access-removal procedures before relying on them.
• Retire access, domains, integrations, and credentials in an order that preserves necessary evidence.
• Approve closure, extend a controlled transition, or pause when required evidence is missing.

The termination notice is signed, but the assistant still runs on the client’s domain, integrations still hold credentials, and nobody can explain what should happen to the source files or conversation records. A controlled exit treats the deployment as a collection of separable assets and access paths. Each needs an owner, custodian, disposition decision, supporting evidence, responsible operator, and final approval.

Key Takeaways

• Ownership and custody are separate facts. An agency may administer an asset without owning it, while client material may remain in an agency-managed account.
• Reversibility is the operating test. Every source, branded surface, credential, integration, record set, and report needs a documented separation or retirement path.
• A requested action is not automatically a supported procedure. Verify the authorized role, affected scope, prerequisites, expected result, and completion evidence.
• Taking the visible assistant offline is only one step. Domains, tokens, automations, retained records, and support expectations can remain active.
• Closure requires a decision record. Completed work, accepted exceptions, unresolved blockers, access removal, and cleanup evidence all need authorized signoff.

Build the asset-and-access register before making changes

The asset-and-access register is the central record for white label chatbot client offboarding. Create it before disabling the assistant, changing roles, disconnecting systems, rotating credentials, or deleting records. If the agency already maintains agency chatbot governance records, carry the relevant ownership, approval, and access entries into this one-time exit record.

Use these fields for every row:

Create separate rows for:

• The client workspace and each assigned user, seat, role, and assistant scope
• Approved pages, files, FAQs, policies, catalogs, and other knowledge sources
• Logos, colors, icons, names, interface copy, style rules, and related brand assets
• Domains, subdomains, DNS records, embeds, widgets, hosted pages, and API deployments
• CRM, help desk, email, calendar, ecommerce, automation, webhook, storage, and custom integrations
• Conversation records, transcripts, metadata, handoff states, outcomes, leads, and feedback
• Client reports, scheduled reports, activity records, and delivery documentation
• Passwords, API keys, bearer tokens, provider keys, SMTP credentials, and shared accounts
• Agency templates, reusable configuration patterns, operating checklists, and internal methods

Current possession is not proof of ownership. A client logo stored in an agency account may remain a client asset. A reusable configuration pattern applied across several accounts may be an agency method. Record each proposed classification, attach the agreement or approval supporting it, and refer disputed items for review.

InsertChat describes owner, admin, manager, and client roles, assistant-specific access, seat controls, and isolation by workspace or assistant in its Team Workspaces evidence. These controls help identify custody and access scope, but they do not settle contractual ownership. Recheck current role names, permission boundaries, client visibility, seat behavior, and removal procedures before execution.

Apply the same asset-level treatment to branded deployment surfaces. InsertChat describes widgets, embeds, full-page assistants, custom-domain deployments, in-app experiences, and APIs in its branding and launch-channel information. Verify the specific plan, configuration, domain procedure, and retirement steps. One row labeled “chatbot” will miss DNS records, website code, hosted links, branded assets, and connected endpoints that can survive after the assistant is disabled.

Follow an exit sequence that preserves evidence

The working order should preserve records before access disappears and stop new changes from obscuring the final state. Adjust the timing when authorization, security, the agreement, or qualified review requires a different order.

1. Record notice and authority. Confirm the termination date, transition period, agency exit owner, client approver, and people authorized to decide each disposition. Record agreed post-exit support, including its channel, scope, owner, and end date.

2. Freeze nonessential changes. Stop routine content updates, branding edits, configuration changes, new integrations, publishing changes, and access additions. Permit only recorded exit work, urgent risk corrections, and changes approved by the named authority.

3. Complete the final review. Reconcile the register against the live workspace, website code, domain settings, connected systems, credential manager, reports, and conversation records. Resolve missing assets before an irreversible action begins.

4. Record export or transfer decisions. State the desired result for each asset, then verify whether a current procedure supports it. Viewing a record, downloading a report, retrieving selected data through an API, or archiving an item does not establish a complete client export or account transfer process.

5. Remove access in the approved order. Immediate removal may be necessary when authorization has ended or exposure is suspected. A controlled transition may be suitable when the agreement permits limited access for review or handover. Narrow the scope, name the approver, set an expiry, and schedule confirmation of final removal.

6. Retire domains and integrations. Remove or replace embeds, hosted links, DNS records, custom domains, webhooks, scheduled jobs, connected inboxes, CRM routes, and notification paths. Test affected systems after each material change.

7. Rotate dedicated credentials. Rotate keys and passwords after dependent connections are removed. If a credential is shared across clients, replace it with client-specific credentials or document a migration plan first. Unmapped rotation can interrupt unrelated accounts.

8. Review retention and deletion decisions. Establish which records may be preserved, restricted, returned, or deleted, who can authorize the decision, and which product, privacy, contractual, and legal materials apply. Operational obsolescence alone is not sufficient authority to delete an asset.

9. Capture evidence and signoff. Record the operator, date, affected scope, result, and proof for every completed row. List accepted exceptions and blockers separately. The final decision must approve, extend, or pause the exit.

Partial exits are common. A client login may be removed while an agency token remains active in an integration. A widget may disappear while a webhook, custom domain, scheduled report, or shared inbox route remains connected. Treat every access path and deployment surface as a separate disposition decision.

Gate unsupported or irreversible product actions

Create a verification gate whenever the exit depends on export, transfer, archive, deletion, or access removal. The gate applies to one asset and one requested result. It prevents a desired outcome from being mistaken for a documented platform procedure.

Record:

• The asset and requested action
• The current documentation supporting the action
• The plan, workspace, interface, or API scope involved
• The role authorized to perform it
• Required approvals and prerequisites
• The expected format or resulting state
• Dependencies that may be affected
• Available recovery or correction options
• The evidence that will prove completion
• The person responsible for resolving a blocker

InsertChat describes conversation records that can be searched, filtered, archived, inspected, assigned outcomes, and retrieved programmatically. Those functions may support record management, but they do not prove a complete client-record export or workspace-transfer process. The product owner must check the current Conversation Inbox and API documentation for the exact role, scope, format, prerequisites, and result.

Security materials describe controls involving knowledge, conversation history, leads, feedback, account isolation, and assistant isolation. Before using a deletion control during an exit, verify the authorized role, affected asset, dependencies, resulting state, recovery behavior, and available completion evidence. Review the current Security and Privacy materials for the specific workspace and record category.

For example, a client may request all conversation records before an agency-managed workspace closes. The operator must define which records are included, who may authorize disclosure, whether personal or third-party information limits the scope, which procedure supports delivery, and what output the client will receive. If any condition remains unresolved, mark the action blocked and pause closure.

Assign a named product owner to recheck procedures immediately before execution. Reverification is also required after changes to roles, domains, conversation tools, APIs, privacy controls, plans, or account-management procedures. Contact InsertChat when the current documentation does not establish the required action, authorization, or result.

Put ownership, retention, and deletion behind review gates

Legal-review boundary: This runbook organizes assets, evidence, and operational actions. It does not determine contractual ownership, retention periods, deletion duties, portability rights, privacy obligations, or post-termination responsibilities.

Send a disposition for qualified review when it depends on:

• The service agreement, ownership appendix, privacy terms, or termination provision
• Whether agency-created configuration is a client deliverable, licensed method, or internal operating asset
• Whether records contain personal, confidential, regulated, or third-party information
• A retention need connected to support, audit, disputes, accounting, or another obligation
• A deletion request, data-subject request, portability claim, or processing restriction
• Duties that may continue after the commercial engagement ends

InsertChat’s Data Processing Agreement is identified as effective September 11, 2024. It names InsertChat as processor and the service user as controller, with conditional provisions concerning processing, transfers, audits, and deletion after relevant service cessation. Review the current DPA together with the Terms, Privacy, Security, client agreement, and applicable circumstances. A qualified reviewer should determine how those materials apply.

Retention presents an asset-specific tradeoff. Keeping conversation records or reports may support an agreed audit, unresolved support issue, or service record. Keeping them longer than authorized may conflict with contractual, privacy, or deletion requirements. Record the purpose, authority, access limits, duration, decision owner, and final disposition.

Future agreements can reduce this uncertainty. Add an exit schedule and ownership appendix addressing notice, transition access, client deliverables, agency methods, domains, integrations, records, credentials, decision owners, evidence, and post-termination support.

Test the runbook against a complete client exit

Consider an illustrative agency retiring a website assistant for a professional-services client. The deployment uses client-approved service pages, the client’s logo and colors, an agency-managed workspace, a client subdomain, a CRM webhook, and an agency configuration framework reused across accounts.

The register records the approved source inventory and brand files as proposed client assets, subject to the agreement. The reusable framework is recorded separately as a proposed agency method. The live configuration is not assigned automatically to either party. Its disposition depends on the contract and any verified product procedure.

During the freeze, the agency permits only exit work. It preserves the source inventory and brand files, records the live embed and DNS entries, identifies the CRM webhook owner, and checks whether any credential is shared. The client asks to retain access for five business days to review final records.

A controlled transition may support an orderly handover, but it also extends access after the engagement is ending. The operator should allow it only when the governing terms, authorization, and risk decision support it. The record must state the permitted assets, authorized role, approver, expiry, and final removal evidence. If those conditions are absent, access should not be extended for convenience.

A second illustrative scenario begins after the workspace has closed. The former client requests continued access to conversation records. The request triggers four checks:

1. Does the agreement or applicable policy support the requested access and use?
2. Do privacy, confidentiality, or third-party rights limit the record set?
3. Does current product documentation support the requested retrieval, export, or access arrangement?
4. Can the result be delivered without restoring broad workspace access or exposing another client’s data?

The agency should not promise a transfer because records were once searchable or retrievable through an API. If the procedure was not verified before closure, record the request, preserve only what is authorized, assign the blocker to the appropriate product and qualified reviewers, and keep the disposition open.

Before signoff, check four frequent failure modes:

• Shared credentials: A password, API key, SMTP credential, or provider key still serves another client.
• Undocumented integrations: A webhook, automation, scheduled job, website script, or notification route exists outside the inventory.
• Premature deletion: Records or configuration were removed before entitlement, retention, dependencies, and evidence were settled.
• Undefined post-exit support: The client expects further assistance, but no scope, channel, duration, or owner was recorded.

Finish with one explicit decision:

• Approve the documented exit when every required row has a supported disposition, completion evidence, accepted exception, and authorized signoff.
• Extend a controlled transition when the remaining work is bounded, authorized, assigned, and time-limited.
• Pause closure when a product procedure, ownership question, privacy decision, retention issue, credential dependency, or continuing obligation remains unresolved.

After signoff, add the register fields, evidence standard, exit schedule, and support boundary to future service agreements. Reversibility then becomes a delivery requirement from the start instead of a problem discovered at termination.

FAQ

Who owns chatbot content after the engagement ends?

Ownership must be decided asset by asset. Classify approved sources, brand assets, configuration, reports, conversation records, and agency methods separately. Use the governing agreement, asset history, approvals, and qualified review instead of assuming the party holding the workspace owns everything stored in it.

Should client access be removed immediately?

Remove it immediately when authorization has ended, exposure is suspected, or the governing decision requires removal. A controlled transition may be suitable when continued access is authorized for a defined review or handover. Limit its scope, name the approver, set an expiry, and retain evidence of final removal.

Can conversation records be exported or transferred?

Do not promise either action until current product documentation establishes the procedure for the relevant plan, role, workspace, record scope, format, prerequisites, and result. Search, archive, inspection, API retrieval, and deletion controls do not independently prove that a complete client export or transfer process exists.

What evidence is enough for final signoff?

Match the evidence to each action. Records may include platform confirmation, an access record, credential-rotation log, integration test, DNS check, removed embed, delivery receipt, retention approval, deletion confirmation, accepted exception, or signed decision record. Final signoff should identify what was completed, intentionally retained, blocked, or accepted, with the authorized decision maker for each result.