Quick answerTreat customer offboarding as a defined process, not a support ticket that gets closed when the account is cancelled. It needs three legs done in order: return or destroy the customer's data on a fixed timeline with written confirmation, revoke every credential and integration the agent held into the customer's own systems, and reconcile final billing including any usage that occurred after the cancellation request was filed but before access was actually cut off. Skipping any leg leaves either a legal exposure (data you should not still hold), a security exposure (access you should not still have), or a billing dispute (charges the customer did not expect).
Why offboarding needs its own checklist, not a shared one
A lot of companies handle AI agent offboarding as a subset of general account cancellation, which usually means someone flips a status flag and moves on. That works fine for a simple SaaS seat. It does not work for an AI agent that has been reading a customer's data, writing to their systems, and accumulating a transcript history that may include sensitive information. The exit process for an AI agent relationship is closer to offboarding an employee with system access than to cancelling a subscription.
This is a different problem from what happens when your own AI agent vendor gets acquired or shuts down. That post is about you being the customer of a vendor that disappears. This post is about the reverse: you are the one running the agent, and your customer is the one leaving.
The three legs of a formal offboarding process
Data return or destruction. Decide in advance, and put in the contract, whether offboarding means the customer gets an export of everything the agent touched (conversation logs, derived summaries, any data the agent wrote into your systems on their behalf) or whether it means deletion with a certificate of destruction. Many customers will want both: an export first, then destruction after they confirm receipt. Set a fixed timeline, 30 days is a common default, and track it as an operational SLA, not a best-effort favor.
Access revocation. List every credential, API key, OAuth grant, and webhook the agent held into the customer's own connected systems, not just the access the customer had into yours. This is the step teams miss most often because it lives in infrastructure and integration configs, not in the billing system that triggers the offboarding workflow in the first place. A revocation checklist should be generated automatically from whatever system tracks the agent's live integrations for that account, not maintained by hand.
Final billing reconciliation. There is almost always a gap between when a customer requests cancellation and when access is actually cut off, and usage can occur in that window. Decide your policy on that gap before the first dispute happens: do you bill through the actual cutoff date, or through the request date? Whichever you pick, state it in the contract and apply it consistently, because an inconsistent answer here is what turns a routine offboarding into a chargeback dispute.
Sequence the legs, do not run them all in parallel
Revoking access before confirming the data export is received can strand a customer who was relying on that export to migrate to a replacement system. Run data return first, get written confirmation, then revoke access, then close out billing. The one exception is a for-cause termination (fraud, contract breach), where access revocation should happen immediately and data handling follows a separate incident process, not the standard offboarding flow.
What this is not
This is not the mechanics of a data-portability handoff, that is what to negotiate in your vendor contract so you can actually take your data with you if you are the one switching vendors, written from the customer's side of a vendor relationship rather than yours. And it is not the same motion as a responsible customer-facing plan for sunsetting an AI agent, which is about you as the company deciding to retire a product for everyone. Offboarding is one customer's exit on their own timeline, not a product-wide shutdown you are communicating in advance.
FAQ
Does offboarding apply if the customer is on a free trial that just expires? No. A trial expiring without conversion is not an offboarding event, there was no live data relationship with obligations attached. Formal offboarding applies once a paying account with real usage history is closing.
Who owns the offboarding checklist internally? Whoever owns the account relationship should own triggering it, but access revocation should be executed by whoever administers the integration layer, not by account management. Splitting ownership this way is what keeps the access-revocation leg from being missed.
Should the customer get a copy of their own conversation transcripts by default? Make it opt-in with a clear default stated in the contract, not silent. Some customers will not want a transcript archive at all, especially if it contains their own end customers' data, and handing it over without being asked can itself create a compliance problem.