Skip to main content
DoneThat

AI Adoption GuideSalesHandoff

Auto-drafted success plan

AI generates a 30/60/90 outcome plan from discovery and ROI commitments.

Sales processProspectQualifyDiscoverProposeNegotiateCloseHandoffRenew

By Don, DoneThat’s AI coach · updated

A 30/60/90 is a draft until the customer owns the dates

The useful output is a dated 30/60/90 built from quoted commitments, sitting in review with CS, not in the customer's inbox as if the dates were already agreed.

CS and the customer still own the plan. Generation does not. Speed here means the onboarding lead does not rebuild milestones from memory the night before kickoff. It does not mean the model invents an outcome the buyer never said, a date nobody put on a call, or a SKU that is not on the order.

A success plan measures what was sold. If the metric was never quoted, leave the field empty. A filled template that could apply to any account is not this customer's plan.

Gainsight, Salesforce, Gong, and Asana belong to the same class of places the plan, the opportunity, the calls, and the tasks already live. This page does not rank them. None of them should write a 90-day outcome the buyer did not agree to.

Pull the quote, then stop when the quote is missing

Three inputs. If a required one is missing, stop and flag it. Do not let the model complete the sentence.

  1. Quoted metrics. Numbers the buyer used, or numbers they accepted in the business case. Take them from discovery notes and from the ROI business case generator only where the customer signed off on the figure. A model that fills a cycle-time cut because that line sat in the deck's sample is inventing an outcome.

  2. Promised work. Every commitment the AE or SE made that delivery will be asked about. Promised-commitments extractor is that list, with cites. If the extractor is empty on a line, the plan is empty on that line. Do not backfill from the product one-pager.

  3. What is actually on the order. Product, quantity, term, and services SKUs from signed-contract data extraction and from the Salesforce opportunity. If a capability showed up on a Gong call and never became a quote line, it is a flag, not a 60-day milestone.

The sales-to-CS handoff briefing is the packet those three inputs should already live in. The success plan is the dated version of that packet. It is not a second invention pass over the same files.

Empty stays empty. "Time to first value" with no quoted definition is not a 30-day milestone. "Executive sponsor engaged" with no named sponsor is not a 60-day owner. Write the gap on the draft so kickoff has a job: confirm, cut, or add with the customer in the room.

Put commitments on a calendar the buyer already used

Map each quoted item to 30, 60, or 90 only when a date or window already exists in the record.

  • Day 0 is close, or the kickoff you already booked, whichever CS already treats as start. Do not pick a start date because the template wanted a Monday.
  • 30, 60, and 90 are windows for quoted outcomes, not a generic enablement checklist. If the buyer said they need the warehouse live before peak in November, that is a dated constraint. If they never said a month, do not assign November.
  • Owners on both sides, named from the record. Champion, admin, implementation lead. If implementation risk flagger already flagged a missing IT owner or a departed champion, the plan should show the empty owner, not a guessed name from the org chart.
  • Work that is not on the order does not get a date. Single sign-on, a second site, a custom report, a professional-services week: if it is not a SKU or a contracted line, it stays off the 90-day outcomes until CS and the customer add it on purpose.

Keep the draft where CS will actually update it. Gainsight, Salesforce, Gong, and Asana are a class, not a ranking. Use them for the plan, the opportunity, the cites, and the tasks. Do not treat a transcript as a project plan.

Do not copy the ROI deck as the plan. A value model is a CFO narrative from discovery. A success plan is the work and the metric the customer will inspect at day 90. Pasting a payback headline into week four is how you start the relationship with a number nobody operationalized.

Dates nobody agreed are the other hard stop. A generated Tuesday does not become the customer's IT freeze because it looked complete. Leave the date blank, keep the dependency, and ask in the room.

Illustrative kickoff: the deck that became a fake 90 days

This walkthrough uses made-up names. It is not a measured result.

Northline Analytics closed a mid-market seat deal plus a packaged implementation. Priya is the AE. Jordan is the CS onboarding lead. Salesforce shows the current seat SKU and the current implementation SKU. Gong's last call has the operations director saying they want dock-to-stock "under two hours," and that they will need single sign-on before they roll past the pilot site. The ROI deck, built during propose, used a sample cycle-time improvement because the buyer did not give a baseline.

Jordan generates a 30/60/90 the morning of kickoff. The file looks finished: owners, dates, metrics, a first-review placeholder.

Three things are wrong on arrival.

The 30-day metric is a percentage improvement on dock-to-stock. That figure lived in the ROI template. The buyer never quoted a baseline and never accepted the sample. Copying the ROI deck as a plan turned a sample line into a customer commitment. The honest 30-day line is: agree the dock-to-stock definition and a baseline measurement method. Empty on the percentage is correct.

The 60-day milestone is "SSO live for all warehouse users" on a calendar Tuesday in October. Nobody agreed that Tuesday. The operations director said SSO before a broader roll-out. They did not pick a day. Dating the plan from a template calendar is how CS shows up looking like they already decided the customer's IT queue.

The 90-day scope includes SSO as delivered work. SSO is not on the order. The implementation SKU does not include identity. Promising a SKU not on the order, inside a success plan, is a second contract with friendlier formatting. The draft should flag SSO as promised on a call and not on the order, and keep it off the dated outcomes until commercial and CS decide to add it.

The useful pass is markup with Priya before the customer sees it. Strip the invented percentage. Strip the invented date. Move SSO to a gap list. Then Jordan walks the draft in kickoff and changes it live. Until the customer confirms owners and dates, it is still a draft.

Confirm in the room, then keep the empty lines empty

CS confirms with the customer. That is not a courtesy pass for typos.

In kickoff, read each 30/60/90 line as a question: is this the metric you will inspect, is this a date you can staff, is this person the owner. Change the draft in the meeting. Send the version that came out of the room, not the generated file.

The AE attends for the promises. If a Gong line and the order disagree, the AE says which one the company will stand behind. CS does not resolve a missing SKU by writing it into Gainsight.

After kickoff, the plan is the artifact you review at 30, 60, and 90. Do not quietly fill empty metrics because the dashboard looks better with a number. Do not slip dates in the tool because a risk flag looked scary. A flag is a staffing conversation. It is not an automatic rewrite of the calendar the customer just confirmed.

Try this on the next closed-won deal you already have a recording for. Generate from the opportunity, the commitments list, and the signed lines as they looked at close, not from the cleaned story after week two. Look at the edits that were invented outcomes, invented dates, or scope not on the order. If those edits are still the whole document, the generator is writing a generic checklist. Stay on accounts where discovery actually quoted something.

Success looks like kickoff starting from a short, cited draft instead of a blank template. Failure looks like a customer nodding at a 90-day number they never said, then being held to it at the first review.

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