AI Adoption GuideSalesHandoff
Cross-system handoff agent
An agent transfers opportunity context, contacts, and notes from the CRM to the CS platform, using tools like Gainsight Horizon AI or Vitally AI.
Sales processProspectQualifyDiscoverProposeNegotiateCloseHandoffRenew
By Don, DoneThat’s AI coach · updated
Copy confirmed Salesforce fields. Do not invent a CS customer.
The job is to copy fields a human already confirmed in Salesforce into the customer success platform. The agent does not invent a customer.
Gainsight and Vitally sit in the same class: CS systems that receive the Closed Won account, including tools in that class such as Gainsight Horizon AI and Vitally AI. Salesforce is the system of record for the opportunity. Gong holds the calls. Write a mapped patch onto a matched CS account. Do not create a new CS customer because names failed to match exactly.
Copy these when they are confirmed: legal account name and billing entity; named contacts and roles; signed products or SKUs; close date and contract start; a pointer to the Salesforce opportunity.
Do not dump every activity row. Do not fill blanks the CRM and the contract left empty. Do not treat a Gong recap as a success objective. Do not create a CS account just because Closed Won fired and exact-name match returned nothing.
Speed is that CS ops reviews a mapped patch instead of re-keying those four objects. It is not a faster create.
The document humans read is the sales-to-CS handoff briefing. This page is the systems transfer: account, contacts, products, dates. Commercial dates and SKUs should already have come from signed-contract data extraction. If a field is still empty there, it stays empty in CS.
The match is a human confirmation, not a create
The first action is a match. Create is a last resort a person chooses.
Wrong legal entity is the expensive failure. Sales closed the UK operating company. CS already has the US parent from an earlier product. Exact-name matching finds nothing, so the agent creates a second customer. You now have two health scores, two onboarding projects, and two owners. Billing still points at the parent.
Duplicating an existing CS account is the same failure with a fuzzier name: trading name versus Inc. legal name versus corporate domain. If any of those already live in Gainsight or Vitally, a create is a duplicate.
- Search before write. Candidates come from Salesforce Account ID if already linked, billing domain, legal name, parent account, and any customer ID you already store. Fuzzy name match is a candidate generator, not a write.
- A human confirms the match. RevOps or CS ops chooses: this existing CS account; this existing account as a parent or child; or no match, create once.
- Never auto-create a second account. If any candidate exists, the agent stops at the queue. If two CS accounts already exist for the same legal entity, queue a merge. Do not pick one silently.
Do not create from a Salesforce account that is still a placeholder, a merged duplicate, or unsigned.
If the contract is with a subsidiary and CS already has the parent, the human decides related entity or child under the parent. The agent does not decide that by string equality.
Map account, contacts, products, and dates, then write
Run this as match-then-confirm-then-write after Closed Won, not as a silent create on stage change.
- Wait for confirmed source fields. Opportunity is Closed Won. Legal name, billing entity, products, and dates are filled, or they are explicitly blank. Prefer contract-extracted values over AE-typed guesses in optional fields.
- Build a candidate list in CS. Same Salesforce Account ID, then domain, then legal name, then parent. Present every plausible hit, including near-duplicates.
- Human confirms the target. Existing account, related entity under an existing parent, or create once. If nobody can tell which legal entity signed, stop. Do not write.
- Map the four objects onto that target. Account: legal name and billing entity; segment only if Salesforce already has it. Contacts: match on email; create only if that email is absent; copy named opportunity roles; skip a law-firm CC. Products: closed-won SKUs, not a demo SKU and not the price book. Dates: close date and contract start as confirmed; leave go-live empty unless CS owns that field and a person typed it.
- Write only accepted fields. Suggested values sit in a review queue until someone accepts them, field by field. A rejected suggestion does not return as an overwrite on the next run.
- Link, do not clone. Salesforce opportunity ID, contract ID, and recording links belong as references. Do not paste Gong transcripts into CS notes.
Leave health scores, playbooks, and success plans out of this write. After CS owns the account, auto-drafted success plan can draft outcomes from quoted commitments, and implementation risk flagger can flag staffing risk. Neither should create a second CS account.
Judge the workflow by whether accepted writes land on one CS account with confirmed fields, versus a new account nobody asked for.
A Salesforce note is not a CS fact
Copying a draft note as gospel is how a maybe becomes an onboarding obligation.
AEs type into Salesforce while the deal is still moving: "SSO in phase 1," "we'll throw in a sandbox," "IT is aligned." Those lines may be true, a hope, or already walked back. Gong recaps have the same problem: they are a reading of a conversation, not a signed exhibit. If you copy them into CS as objectives, the CSM staffs SSO before anyone checks the order form.
Tag notes by source:
- Confirmed. A field or clause a human accepted, or a line that survived contract extraction.
- Draft / AE note. Copied only if CS asked for it, labeled unverified, never a milestone.
- Call recap. Link the Gong recording. Do not paste the recap as the success plan.
Promises from a call belong in promised-commitments extractor, where CS can check them against the SOW. They do not become CS tasks because they appeared in Salesforce Comments. If the note field is empty, leave CS notes empty.
Illustrative close: the subsidiary that already had a parent in CS
The following is a made-up Closed Won, not a measured program and not reported results.
An AE closes Harborline Logistics UK Ltd on a warehouse-visibility SKU. The Salesforce account is the UK entity. Parent account is Harborline Logistics, Inc. Contacts: Priya Shah (VP Ops, UK), an implementation lead with a harborline.com email, and a law-firm CC from redlines. Close date and contract start are filled from the signed PDF. Opportunity notes still say they will want SSO in phase 1. Gong repeats the aside.
CS already has Harborline Logistics, the US parent, from a prior freight-audit SKU: same domain, different Salesforce account ID.
The naive agent writes without a match review: creates Harborline Logistics UK Ltd as a new CS customer because the name did not match exactly; clones the implementation lead whose email already exists on the parent; copies the SSO note into CS objectives; pastes the Gong recap into account notes; leaves the parent untouched. CS now has two Harborlines.
That is the wrong legal entity, a duplicate CS account, and a draft note treated as gospel, in one write.
What the draft should have been:
- Candidates. Harborline Logistics (existing CS account, parent, shared domain).
- Human confirm. CS ops chooses: create UK as a child under the existing parent, or work the parent and tag the UK billing entity.
- Account. Legal name Harborline Logistics UK Ltd, related to the existing parent. Salesforce IDs linked.
- Contacts. Priya Shah created if her email is new. Implementation lead matched to the existing email, not cloned. Law-firm CC omitted unless confirmed as a working contact.
- Products. The warehouse-visibility SKU from Closed Won. Not the prior freight-audit SKU, and not SSO.
- Dates. Close date and contract start as confirmed. Go-live empty.
- Notes. SSO line stored as an unverified AE draft, or left for the commitments extractor. Gong recap linked, not pasted.
CS ops accepts that patch. The agent never auto-creates the second account. Gainsight, Vitally, Salesforce, and Gong will only be as disciplined as that confirm step. The speed win is a confirmed field map onto the account that already exists. It is not a new customer the CRM invented.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first