Prepare the onboarding brief before the kickoff call

Imagine Priya, implementation lead at Cedar Analytics, preparing for a kickoff with Northwind Works. The customer signed yesterday. Before she agrees a date with the customer, she wants to know what Northwind actually bought.

The signed order form says one administrator training session. Alex in sales wrote that two were discussed, along with single sign-on. The statement of work makes the data import dependent on an approved customer export. The technical administrator's name is blank on the deal. Morgan, the proposed customer-success owner, is away October 12–16, so Priya needs a backup if kickoff falls that week.

The answers sit in four places. Priya needs to gather them and compare what they say before the call. This walkthrough follows a Midpoint worker reading those sources, writing the brief, and leaving each question with the person who can answer it.

Your first job for the worker

Pick one closed deal. The easiest to start with has a signed order form, a named salesperson and an implementation you already understand.

Connect the CRM and project tool, then confirm that the worker can read the specific deal and Asana project space you'll use. Give it three things before you ask for the brief:

• Read access to that deal and the signed documents. Check that it can open the order form itself. A CRM connection may show the deal fields but leave the attachments or call notes unavailable, and a brief built on the fields alone will look complete when it isn't.
• A place to report. A ticket shared by Alex and Priya works well. The worker posts the brief there and mentions the people who have a question to answer.
• Two named people. Alex has authority to settle changes to the sold scope. Priya accepts the delivery plan. Give Priya a backup and a day by which she should reply.

Then ask in plain words:

Prepare the internal onboarding brief for Northwind Works, deal DEMO-2042. Read the signed order form, the statement of work and the sales note. Tell me what the customer wants, what the signed documents cover, what was discussed but not signed, what we still need from Northwind, and who should own each open item. Link every finding to the page it came from. Check whether an onboarding project already exists for this deal. Write the project description and task list for Priya to review. Don't create or change the project, edit the deal, invite Northwind, set up access or send anything outside our team.

The first run ends with the brief and draft project content in the ticket. Use read-only access where you can. Asking for a draft does not remove the account’s write permissions.

Check the commitments against the signed scope

Cedar’s example source pack is at the end of this article. In your own brief, use links to the actual record and document version so the receiving owner can check a finding quickly.

For Northwind, the worker has four sources:

• Order form OF-2042, signed October 7: 40 seats and one administrator training session.
• Statement of work SOW-2042 v2, signed October 7: one data import after Northwind supplies an approved export. Delivery timing will be confirmed after review of the export and technical requirements.
• Sales note NOTE-2042, October 6: “Aim for October 30. Discussed two admin training sessions and SSO.” Northwind wants the workspace for its November 2 board meeting.
• Deal DEMO-2042, checked October 8: executive sponsor named, technical administrator blank, proposed CS owner Morgan away October 12–16.

The order form supports one training session. The sales note mentions two, so Alex needs to settle the second session. The SSO discussion needs a scope decision too.

Keep that relationship context in the brief. Asana’s post-sales handoff guide separates the customer-data layer from the reasons and expectations behind the purchase. For Northwind, the board meeting explains the timing pressure; it also helps Priya ask which first report the customer actually needs.

HubSpot’s B2B onboarding guide recommends capturing outcomes, technical requirements, commitments and ownership before kickoff.

What Priya reads before the call

For Northwind, the worker could leave this in the ticket. Alex has confirmed that the linked order form and SOW v2 are the current signed versions.

Northwind Works, DEMO-2042: internal onboarding brief

What Northwind wants. A shared reporting workspace before its November 2 board meeting (sales note, October 6). Ask at kickoff which report they need first.

What is signed. 40 seats, one administrator training session, and one data import once Northwind supplies an approved export (OF-2042, SOW-2042 v2). Priya hasn't accepted the delivery plan yet.

Three things to settle:

1. Second training session. The order form has one. The sales note says two were discussed. Alex decides what was promised and how the second session is handled.
2. Single sign-on. It appears in the sales note, absent from the linked signed scope. Alex and Priya agree whether it is in scope and on what terms.
3. October 30. A target from the sales note. Priya holds the date decision: the SOW requires the export and technical requirements to be reviewed before she confirms delivery timing with Northwind.

Missing. Northwind's technical administrator and the approved export date. The deal record leaves the contact blank; the SOW identifies the export prerequisite. Alex asks Northwind for the contact; Priya works through the import requirements with that person.

Kickoff owner. Morgan is the proposed CS owner but is away October 12–16 (deal record). If kickoff lands that week, Priya has suggested Taylor, who hasn't said yes yet.

Existing project. No deal-linked project found in the checked internal project space at 9:02 a.m. Pacific on October 8 (deal record). The worker has not looked in any other space. The draft project and tasks are ready; nothing has been created.

Priya can review the delivery questions and send the commercial questions to Alex.

How the handoff comes back to the worker

Keep the questions in the same ticket. The worker records the answers and revises the brief:

• Priya accepts and authorizes the project work. The worker creates the approved project and tasks in the agreed destination, then reads them back (see the project section).
• Priya changes something. The worker revises the brief and marks which version she accepted.
• Alex hasn't answered. The commitments stay open. The brief says so, and no customer timeline is built on them.
• Nobody is free to run kickoff. The worker asks Priya and her backup. Taylor stays "proposed" until Taylor accepts.

When the latest contract is unavailable or signed versions disagree, the worker asks Alex to establish which document governs.

Create the internal project from the accepted plan

After Priya approves the exact plan and authorizes the writes, the worker can use the configured Asana actions to create the project and tasks she approved. Her decision should identify the destination, visibility, task content and accepted owners. If the connection can’t perform a required change, the worker should return the prepared content and say which step remains.

For this example, the intended project is Northwind Works | onboarding | DEMO-2042, private to the approved internal team. The description links to the deal, signed documents and accepted brief. Sensitive contract detail stays in its restricted source. Check who can open those links before sharing the project or a channel update.

The first tasks cover the decisions and preparation:

• Training decision, Alex: Record how the extra session will be handled, with the order-form and sales-note links attached.
• SSO scope decision, Priya with Alex: Confirm the requirement and commercial treatment, then identify the technical prerequisites.
• Technical administrator and export plan: Alex obtains the contact; Priya confirms the import requirements. Import execution waits for the approved export.
• Kickoff owner, Priya: Confirm an available owner and their acceptance. Taylor remains a proposal until that happens.
• Kickoff agenda, accepted owner: Include the customer goal, agreed scope, target date and open questions.

Only use dates the task owner agreed to, or your team’s approved standard offsets. Document the import prerequisite in the task notes. If the connected Asana actions support dependency writes and the worker is authorized to use them, add and check those relationships separately.

Read the saved project and tasks back after a permitted write. Confirm the deal link, assigned people, visibility and unresolved commitments. The worker’s final note should include the real project link and any step it couldn’t finish.

Handle repeat events and later amendments

A closed-won event can arrive more than once. A delivery can be retried, a deal can be edited after close, or the opportunity can be reopened and won again.

Keep a mapping from the CRM account and deal ID to the onboarding project. Match on that identity rather than the customer name. A renewal at Northwind can be a separate deal with its own work.

Before creating anything, read the current deal and any existing handoff. An unchanged repeat should return the existing project link. If the SOW changed, the worker proposes a revision to Priya, preserving tasks that people have already accepted or completed.

If a create request times out, first check whether the deal-linked project was created. Retry only after resolving that uncertainty. Concurrent runs need a shared claim on the deal so both can’t create a project after both find none. These behaviors need to be configured and tested in the job; a connection or name search alone doesn’t provide that guarantee.

Start manually. Repeat the same input, introduce a changed scope and test an unavailable source before enabling a closed-won trigger.

When HubSpot’s built-in Asana action is enough

HubSpot documents a Create an Asana task workflow action. It requires the Asana connection, appropriate workflow permissions and a project visible to the integration. If a fixed task with copied deal fields covers your handoff, that existing action may be sufficient.

A worker is useful for the preparation that requires reading several sources and returning decisions: the training discrepancy, the missing administrator, the export prerequisite and the available receiving owner. Keep the first assignment at that internal handoff. Customer invitations, welcome messages and provisioning need their own authorization.

For background on transferring responsibility, see handoff patterns. The ownership model covers the continuing decision rights.

Run it again on the next deal

After the first brief, sit with Alex and Priya and read it together. Check that each finding is supported by its source, each link opens the right document, and the brief includes what they need for kickoff. Add any missing information to the request before trying the next deal.

Once the brief holds up on a few deals, configure and test a job that starts when a deal is marked won in the intended CRM pipeline. Even then the project and every message to the customer wait for a person to approve them.

If you want to try this with HubSpot and Asana, talk to Midpoint about the onboarding handoff.

Example source pack

Example order form

OF-2042, signed October 7: Northwind Works purchases 40 seats and one administrator training session from Cedar Analytics. Alex confirms this is the current signed order form. It contains no second training session or SSO implementation commitment.

Example statement of work

SOW-2042 v2, signed October 7: One data import after receipt of a customer-approved export. Delivery timing will be confirmed after the export and technical requirements are reviewed. Alex confirms v2 is the current signed version. No later amendment appears in this example pack.

Example sales note

NOTE-2042, October 6, 2:00 p.m. Pacific: Northwind wants a shared reporting workspace for the November 2 board meeting. “Aim for October 30. Discussed two admin training sessions and SSO.” These statements are sales context, not a signed scope amendment.

Example deal record

DEMO-2042, checked October 8, 9:00 a.m. Pacific: Closed won. Executive sponsor named; technical administrator blank. Sales owner Alex, with authority to settle changes to the sold scope. Approved export date not set. Delivery-plan acceptance pending with Priya. Proposed CS owner Morgan, unavailable October 12–16. Priya is the receiving implementation lead and nominates Taylor as a possible kickoff backup; Taylor hasn’t accepted. Internal project-space search at 9:02 a.m. finds no matching deal-linked project in that space. This review hasn’t created one.

How you'd run this on Midpoint

Your worker already has its own computer and browser. You don't have to set up either one.

Connect the accounts this job needs, or save a website login for the worker to use. Share the relevant files and tell it what you want in plain words:

Compare this closed deal's signed scope and sales notes. Prepare the onboarding brief with open questions and owners. Don't create anything or contact the customer.