AI Adoption GuideSalesHandoff
Implementation risk flagger
Machine learning predicts onboarding risk based on sales-stage signals like buying-team turnover.
Sales processProspectQualifyDiscoverProposeNegotiateCloseHandoffRenew
By Don, DoneThat’s AI coach · updated
Cite the risk, then staff the project
The job is a flag with cites, produced from sales-stage evidence before kickoff. Customer success still staffs the project. The go-live date does not move because a tile went red.
A useful flag names a driver the implementation lead can check on the handoff call: the champion left, IT was never on the committee, or a SKU sales described is not on the contract. An opaque score is not that. Do not publish a go-live slip rate. Thin implementation history cannot support one.
Cites already live in tools you run. Opportunity products, contact roles, and close notes sit in Salesforce. Calls sit in Gong and the rest of that class. The CS record often lives in Gainsight. The onboarding board often lives in Asana. None of those products is the flagger.
Put the flag on the sales-to-CS handoff briefing. A cite that never reaches the implementation lead is hallway talk. A score with no cite is a health tile.
Champion left, no IT, SKU mismatch
Work the deal before kickoff so the model cannot invent a reason from a first-time buyer flag.
- Salesforce products and contact roles. What was sold. Who is on the opportunity. If a role is blank, it stays blank until a cite exists.
- Gong, and the rest of that class. Who spoke, who left, who was promised an intro to IT, which SKU was described as included. Quote enough that the AE can confirm it on the handoff call.
- Contract versus opportunity. If closed-won products and the signed SKU list disagree, the flag is the mismatch, not a generic scope risk.
Champion left. A bounce, an out-of-office that says they are gone, or a call where a peer says they left is enough. Champion-departure monitoring is the later watch after the account is live. At handoff the same fact is a staffing problem: the person who sold this internally will not sit in kickoff. Do not auto-promote the next title. Leave champion empty and send a lead who can rebuild the map.
No IT on the committee. If your motion always hits SSO, sandbox, extracts, or a security review, and nobody from IT, security, or a technical buyer appears on contact roles or on calls, that is a coverage hole. Buying-committee mapping already treats a missing function as an empty seat. At handoff, empty IT means send a technical onboarding owner, not only a relationship CSM.
SKU mismatch. Salesforce products, the contract, and the last call are three artifacts. If Gong has the warehouse connector in phase one and Professional does not include that connector, write both cites. Promised-commitments extractor lists what was said. This pass asks whether you are about to staff unpaid work. Ignoring a SKU the contract does not include is how kickoff becomes a scope fight.
A compressed close, a discount, or a new logo can be notes on the briefing. They are not cites unless you can point at a person, a missing function, or a product line. If you cannot name a driver, it is not a flag.
Illustrative handoff: Meridian Cold Storage
The following is a made-up but realistic closed-won week, not a case study and not reported results.
An AE closed a WMS add-on with Meridian Cold Storage. Salesforce shows Professional plus Implementation. Contact roles: VP of Operations as champion, a warehouse supervisor, procurement. Close notes: IT aligned, go-live in six weeks. Kickoff is on the calendar for Monday.
Call recordings disagree. On the last Gong call the VP says they accepted a 3PL role and Friday is their last day. No IT person is on any recording. Mid-cycle the AE said the warehouse connector comes with the package. Closed-won products do not include that connector. Procurement's packet lists Professional only.
What the flag should carry:
- Champion left. Cite: the last-day line on the last call. Staffing: a lead who can rebuild the committee, not a junior CSM expecting the VP at kickoff.
- No IT on the committee. Cite: contact roles and attendance. Staffing: a technical owner in the room from day one, plus a written ask for a named IT counterpart before configuration starts.
- SKU mismatch. Cite: the comes-with-the-package line against Professional. Staffing: do not put a connector specialist on the project as if the SKU were sold. Put the mismatch on the briefing so CS and the AE choose: sell the SKU, walk the promise back, or write a change order. Do not ignore the SKU the contract does not include.
What they almost did is the usual failure. RevOps scored the account high-risk because it was a first-time buyer and the discount was large. CS auto-moved go-live. The Asana board still had the connector as a phase-one task. The new Ops contact arrived expecting the VP and the connector. The date had slipped. The mismatch had not.
CS should have staffed the project: a senior lead, a technical owner, no connector work until the SKU is sold or the promise is cut. The original go-live stayed until a human named a reason work could not start. First-time buyer was not that reason.
First-time buyer is not a cite
Punishing every first-time buyer trains sales to hide new logos and trains CS to over-staff every net-new account. New logo is a fact about the motion. It is not evidence that the champion left, that IT never joined, or that a SKU is missing.
If you have only a handful of implementations, you do not have a model. You have a checklist: committee seats, departed people, products versus promises. Do not fit a score on that history and call first-time buyer a feature.
A heavy discount is the same trap. Discount can mean a competitive bake-off, a champion who needed air cover, or a seller who could not defend the SKU. Without a cite it is not implementation risk. With a cite (the connector was given away on the last call) it belongs under SKU mismatch, not under discounted deal.
Keep the flag internal. Do not put a risk grade in customer-facing material, including an auto-drafted success plan the buyer will see. A flagged customer treated as a problem customer often becomes one.
Sales will read a faceless score as blame for how the deal was sold. A cite they can confirm (this call, this missing contact role, this product line) is a handoff fact.
A flag is not a go-live change
Do not wire the flag to the date. A script that slips go-live because the champion left, or because IT is missing, punishes the customer for a hole you already knew about. It also teaches CS to wait for the model instead of staffing the hole. The implementation lead still chooses: restaff, add a technical owner, send the SKU mismatch back to the AE, or decide the flag was a stale contact role.
Staffing is the action. Champion gone: send someone who can rebuild relationships. IT never in the room: send someone who can run a technical kickoff and name the missing counterpart. SKU missing: do not staff delivery for unpaid work, and do not delete the promise from the board so the project looks clean. Put both facts on the briefing.
Asana should reflect who is on the project and which tasks are actually in scope. Gainsight can hold the internal flag and the cites. Salesforce remains the source of products and contact roles. Gong remains the source of what was said. None of them should auto-change a date.
Trial this on closed-won deals before kickoff, in parallel with the handoff you already run. Check whether the implementation lead can name the driver, whether first-time buyer accounts were left alone unless a cite existed, whether any go-live moved from a tile, and whether a SKU off the contract was sold, cut, or written as a change order before configuration. If the only change is a new health score in Gainsight, you have relabeled status. The job is a cited flag, a human staffing call, and a date that still belongs to CS.
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.
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