Automation  ·  Customer success

How to build a closed-won to onboarding handoff

The deal closes and six weeks later nobody can say whether the customer is live, or what sales promised to get it signed. What follows is the model behind a handoff that carries both, the prompts that build it, and what changes in production.

Built with Tray Headless

  1. System Salesforce
  2. Step Required fields
  3. Step Pull commitments
  4. Step Generate plan
  5. System Jira
Also Gong Clock starts at close

Commitments made during the sale are surfaced for the rep to confirm, then carried as obligations.

The short answer

What is a closed-won handoff?

A closed-won handoff is four parts: carrying the commitments made during the sale instead of only the products bought, generating an onboarding plan from what was actually sold, starting the time-to-value clock at close instead of at kickoff, and a structured handoff record that neither team can skip. Most of these come apart on the commitments. What sales promised to win the deal is usually in a call recording and an email thread, and delivery finds out about it in week three.

What matters here

  • Carry what was promised, not only what was sold. The custom report a rep agreed to is a commitment and it needs to survive the handoff.
  • Generate the plan from what they bought. One onboarding template for every customer under-serves the complex ones and annoys the simple ones.
  • Start the clock at close, not at kickoff. Close to kickoff is usually the largest interval and it is owned by nobody.
  • Make the handoff a record with required fields, not a meeting. Meetings get skipped at quarter end, which is when most deals close.
  • Surface a stalled onboarding to the account owner too. It is a renewal risk before it is a delivery problem.

Who this is for

You run customer success operations or revenue operations. Deals close, delivery picks them up somewhere between immediately and a fortnight later, and what was promised during the sale is rediscovered gradually.

How it works in practice

What happens between a deal closing and a customer being onboarded.

  1. 1

    Closed-won creates the handoff record immediately

    Not at the next weekly meeting. The clock is already running and everybody can see it.

  2. 2

    What was sold generates the onboarding plan

    Products, integrations, user count, migration and security review requirements each add their own tasks.

  3. 3

    Commitments made during the sale are pulled forward

    From the opportunity, the quote, and the call summaries, so delivery inherits the promises rather than discovering them.

  4. 4

    Required fields block an incomplete handoff

    Technical contact, success criteria and go-live target. A handoff missing those is the one that stalls.

  5. 5

    The customer team is created and notified

    Owner, implementation lead and the account team, in one place, with the context attached.

  6. 6

    Time to value is measured from close

    Close to kickoff, kickoff to first value, first value to live, reported separately.

What the handoff is made of

The gap between sold and delivered. Four parts, and the third is the one that surprises delivery.

Commitments carried

What was promised to win the deal, gathered from the opportunity, the quote and the call record, attached to the handoff as obligations rather than notes.

A generated plan

Tasks assembled from what was actually bought. A single template serves the simple customer badly and the complex one worse.

A clock starting at close

Close to kickoff is usually the biggest interval and the least owned. Measuring it is most of the reason to build this.

A record, not a meeting

Required fields that block an incomplete handoff. Meetings get skipped at quarter end, which is exactly when the deals close.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    Set up and find where the promises actually live

    The commitments are the hard part, and they are scattered.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are Salesforce and our
conversation intelligence tool, or whatever we run in those seats.

I need the opportunity with its line items, the quote, any custom fields
where a rep records commitments, and how call summaries are stored and
queried.

The products are easy. What I actually need is where a promise made
during the sale ends up, because that is what delivery currently
discovers in week three.
  2. 2

    Create the record at close, with required fields

    A handoff that can be incomplete will be, at quarter end.

    Headless skills build-workflow 

    Use build-workflow. Trigger on Opportunity StageName changing to Closed
Won. Create the handoff record immediately, not at the next meeting.

Require these before the handoff can be marked complete: technical
contact with an email, business sponsor, success criteria in the
customer's words, target go-live date, and any commitment made outside
the standard product.

An incomplete handoff stays open and visible with the rep named on it.
Do not let it be marked done, and do not let the deal disappear from the
sales view until it is.

    Required fields are the whole mechanism. A handoff form that can be submitted empty is a form that gets submitted empty in the last week of a quarter.

  3. 3

    Pull the commitments forward

    So delivery inherits the promises rather than discovering them.

    Gather what was promised, from three places:

  Structured commitments the rep recorded on the opportunity
  Non-standard terms on the quote: custom SLAs, specific integrations,
  professional services, anything discounted in exchange for something
  Call summaries from the last three calls before close, searched for
  commitment language: we will, we can add, that is included, by then

Present the third list to the rep for confirmation rather than treating
it as fact. A model reading a transcript is a prompt for a person to
confirm, not a source of contractual truth.

Anything confirmed becomes an obligation on the handoff with an owner and
a date. That is the difference between a promise and a surprise.
  4. 4

    Generate the plan from what they bought

    Because one template serves nobody well.

    Headless skills tray-gotchas 

    Use tray-gotchas, then assemble the onboarding plan from task templates
with conditions over what was actually sold:

  Which products, which integrations, how many users
  Whether data migration is in scope
  Whether a security review or a DPA is required
  Whether the customer is regulated
  Which region, since that changes data residency tasks

A single product with no migration should produce eight tasks. A complex
enterprise rollout should produce forty. Giving both the same checklist
annoys the first and under-serves the second.

Split tasks by owner side: ours, theirs, joint. Most onboarding delay is
waiting on the customer, and a plan that only shows internal tasks
reports green while nothing moves.
  5. 5

    Start the clock at close, and watch the gap

    Close to kickoff is the interval nobody owns.

    Stamp Closed_Date, Handoff_Complete, Kickoff_Held, First_Value and
Live_Date. Report the intervals between them separately.

Close to kickoff is the one to watch. It is usually the largest and it is
owned by nobody, because sales believe they have handed over and delivery
believe it has not started.

Alert when a handoff is incomplete after a few days, when kickoff has not
happened within the target, and when an onboarding stalls in a stage.
Send stall alerts to the account owner as well as to delivery, because a
customer stuck in configuration for five weeks is a renewal risk before
it is a delivery problem.
  6. 6

    Check it end to end, then hand the templates over

    Because the onboarding plan belongs to the team that runs it.

    Run the per-step schema checks and the whole-workflow audit before this
touches production.

Then open the same workflow in Tray Build so customer success operations
can maintain the task templates, the conditions and the target intervals
in the visual canvas. The onboarding plan changes as the product does,
and it belongs to the team delivering it.

What it connects to

The handoff spans the deal, the delivery plan and the people on both sides of it.

Salesforce

Read the closed-won opportunity, its line items, the quote and recorded commitments. Write handoff status back so the account team can see it.

Reads and writes

Gong

Read call summaries from before close, so commitment language can be surfaced for the rep to confirm.

Reads

Slack

Create the customer channel, notify both teams, and escalate a stalled onboarding to the account owner.

Writes

Jira

Create the onboarding tasks where the delivery team already works, rather than in a parallel tracker.

Writes

Gmail

Send the customer their outstanding tasks, which is most of what an onboarding manager does by hand.

Writes

Snowflake

Land the intervals, so time to value by product and segment is a query instead of a quarterly exercise.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Microsoft Dynamics 365, Google BigQuery, Microsoft Teams, ServiceNow, Microsoft Outlook or HubSpot.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

This runs at quarter end, at volume, when everybody is busiest. That is when it has to work.

It runs on the platform, not on somebody's machine

Handoff creation fires on every closed-won deal, including the fifty that close in the last week of a quarter, with retries and a history for each.

The commitments are recorded, not remembered

Each obligation with its source, its owner and the confirmation that a person accepted it. That record is what a disputed promise gets settled with.

Credentials are managed, never written into the build

The CRM and conversation intelligence credentials read commercially sensitive material. Both live in your workspace, scoped to read and rotatable.

Customer success owns the templates

Task templates, conditions and target intervals open in Tray Build, maintained by the team that delivers against them.

Stalls reach the account owner

Not only the delivery queue. A customer stuck for five weeks is a renewal conversation, and the account owner usually finds out last.

Questions people ask

Why carry commitments instead of just products?

Because what a rep promised to win the deal, a custom report or a specific integration date, is usually in an email thread or a call. Delivery discovers it in week three, and by then the expectation is already set.

Should a model read call transcripts for commitments?

It can surface candidate language for the rep to confirm, but it should never record a commitment as fact. A confirmed obligation with a named owner is useful; an inferred one is a liability.

Why generate the plan rather than use one template?

Because a customer buying one product with no migration needs eight tasks and a complex enterprise rollout needs forty. One template annoys the first and under-serves the second.

Why start the clock at close rather than kickoff?

Because close to kickoff is usually the largest interval and nobody owns it. Sales believe they have handed over, delivery believe it has not started, and only a clock starting at close makes the gap visible.

Why a record rather than a handoff meeting?

Because meetings get skipped at quarter end, which is when most deals close. Required fields that block completion survive a busy week in a way a calendar invitation does not.

Vibe-coding app guides

Vibe-code an entire app with Helix

This moves the data between systems. It does not give anybody a screen to work in. Build that app in Claude Code, Codex or Cursor, then deploy and run it governed on Tray Helix. Same kind of guide, same kind of prompts.

How to build a customer onboarding tracker (opens helix.tray.ai in a new tab)

Related guides

Revenue operations

How to build an order-to-cash integration

Closed-won to sales order to invoice to cash applied, as a CRM to ERP integration. Idempotent writes, a reconciliation loop, and the Headless prompts that build it.

Revenue operations

How to build pipeline hygiene automation

Detect the staleness that matters, nudge the owner rather than the report, escalate on the deals that count, and measure whether it worked. The prompts that build it.

Last reviewed September 2026.