What it means to hand off a lead, a deal or an account, and what has to travel with it.

Definition

To hand off a lead, a deal or an account is to transfer ownership of it from one person or team to another, together with the context the new owner needs to continue the conversation instead of restarting it.

A sales handoff is that transfer treated as a step in the process rather than an email. It has a trigger that says the moment has come, a named owner before and after, a written record of what the buyer has already said, and a point where the receiving side accepts the work.

The dictionary sense is close to the business one. Cambridge defines the noun handoff as the act of giving control of something, or responsibility for something, to someone else. In American football it is a pass in which the ball is put directly into the hands of another player.

That sports picture is a useful standard: direct contact between two people, not a record dropped in the general direction of the next team. This page treats every transfer in the revenue cycle that way, from the first qualified lead to the renewal conversation years later.

Handoffs are the seams of a revenue team. Each seam is a place where information can leak, where customers repeat themselves, and where a deal stalls while two people each assume the other one is following up. The rest of this page is about closing those seams.

Hand off, handoff, hand-off: which one to write

Cambridge lists hand off as a phrasal verb, marked as US usage, with the UK equivalent hand over. One of its senses is to give another person control of something, or responsibility for dealing with it. The noun is handoff, also written hand-off, with handover given as the UK form.

This page writes the verb as two words and the noun as one, which matches how Cambridge separates them. Nothing in the process changes with the spelling, but a style guide that picks one form saves a surprising number of review comments.

Why the handoff decides what happens next

A buyer experiences a company as one conversation. Internally that conversation is split across a marketer, a sales development rep, an account executive, perhaps a solutions engineer, an onboarding lead and a customer success manager, each of whom joins partway through.

When the handoff is clean, the new owner opens with what the buyer already told someone else, and the buyer feels remembered. When it is not, the second call repeats the first, and the buyer reasonably concludes that nobody wrote anything down.

In this page's view the cost is rarely a lost deal on the day. It shows up as a slower B2B sales process, meetings that get rescheduled, onboarding that starts from the vendor's checklist instead of the customer's goals, and revenue that ages quietly because ownership was never clear.

What has to transfer: context, not just a record

Many teams transfer the record and call it a handoff. The record is the easy half. The context is the half that decides whether the next conversation is any good, and it is the half no system fills in by itself.

The right column lives in someone's head and in call recordings. A handoff is the moment it gets written down, which is why handoffs fail for the same reason notes fail: nobody is measured on writing them.

There is also information worth leaving out. A full transcript, every email in the thread, and internal opinions about the prospect all slow the receiver down. The point of a handoff note is judgment about which details matter, not a second copy of the CRM.

Every handoff in the revenue cycle

A B2B account can change hands six times between first interest and its second renewal. The transfers share a shape and differ in what the receiving side needs most. Not every team has all six; a small team may run three of them through one person.

The sections below take each handoff in order. The marketing to sales one gets an overview only, because its stage logic has its own page. The others get the depth they need, with what the receiving role actually does and what the CRM records along the way.

The marketing to sales handoff, in brief

This handoff starts when a lead meets a definition both teams signed. In HubSpot that definition is expressed as a lifecycle stage, and the stage where marketing passes the lead on is the MQL, short for marketing qualified lead.

HubSpot documents eight default lifecycle stages in sequential order: subscriber, lead, marketing qualified lead, sales qualified lead, opportunity, customer, evangelist and other. Its knowledge base says the stage property shows where a record is in the process and how leads are handed off between marketing and sales.

One detail shapes the return path. HubSpot states that default automatic updates only move the lifecycle stage forward. A lead passed on too early therefore has to be walked back on purpose, by a person or a workflow, rather than drifting back on its own.

The stage logic, the sales accepted lead step between the two, and the service level agreement at that boundary are covered in MQL vs SQL. Who receives each lead, by territory, account or rotation, is covered in lead routing.

What belongs on this page is the part every handoff shares: the context. A routing rule assigns an owner and a notification fires, but the reason the lead qualified has to travel too, as written text on the record, not as a link to a form submission.

The feedback has to travel back. A disposition on the record, from a short list such as wrong fit, wrong timing or could not reach, turns complaints into data. How marketing reads that data is the subject of lead quality.

The SDR to AE handoff

In this page's view, the SDR to AE handoff is the one argued about most, because SDRs and AEs are measured on different things and the two measurements disagree. The rep is often paid for meetings booked; the account executive is paid for meetings that turn into deals.

What makes it clean is a shared definition of qualified, written down before the argument. Whatever framework the team uses, the rep records the answers rather than checking a box, and the AE reads them before the call. That reading step is the handoff, not the calendar invite.

The information an AE needs is narrower than many SDRs expect. Six items, written at the moment the prospect agreed to the meeting, beat a long summary written from memory two days later.

• The promise: what the rep said the meeting would cover, word for word, so the AE opens on it.
• The problem: the buyer's own description, not a category name chosen afterwards.
• The people: who is attending, what they do, and who was mentioned but is not coming.
• The path in: cold call, referral, inbound form, event, or a reply inside a sales cadence.
• The objection already raised: price, timing, an incumbent vendor, or a project that failed before.
• The acceptance: the AE confirms the meeting is worth keeping, or returns it with a reason.

The return path matters as much as the transfer. Without it, unqualified meetings get held anyway, both reps lose an hour, and neither learns where the bar was supposed to sit. Qualifying sales leads is what that bar is made of.

What the CRM does at this handoff

In Salesforce, the SDR to AE handoff can coincide with lead conversion. Trailhead documents that converting a lead uses the information stored on the lead record to create a business account, a contact and an opportunity. Anything the rep typed into the lead travels with it, and anything left in their head does not.

Dynamics 365 Sales works the same way. Microsoft describes qualifying a lead as validating that it is a genuine sales opportunity, associating an account and a contact, and creating the opportunity record that tracks the deal. Leads that miss the criteria can be disqualified while keeping an audit trail.

HubSpot ships a default lead pipeline with five stages: New, Attempting, Connected, Qualified and Disqualified. A team that hands off at Qualified can attach its handoff fields to that stage, so the rep fills them in at the moment the lead moves.

The AE to solutions engineer handoff

Partway through a technical sale, the account executive brings in a solutions engineer. O*NET files the role as sales engineer, with reported titles such as technical sales engineer and sales applications engineer; some companies say presales.

This is a partial handoff: the AE keeps ownership of the deal and the relationship, and hands off ownership of the technical proof.

O*NET's profile of sales engineers describes the work that receives this handoff. Its listed tasks include collaborating with sales teams to understand customer requirements and provide sales support, conferring with customers and engineers to determine system requirements, and preparing technical presentations.

The same profile lists developing or responding to proposals for specific customer requirements, including responses to requests for proposal. That is why the handoff note for a solutions engineer looks different from the others. It is a requirements brief, not a relationship summary.

• The use case: what the buyer wants the product to do, described in their terms and tied to their goals.
• The environment: the systems the product must connect to, and anything the buyer said about security or data.
• The test: what the buyer will check in the demo or trial, and who on their side will judge it.
• The competition: which alternative the buyer is comparing against, if they said so.
• The boundary: what the AE has already said the product can or cannot do, so the engineer does not contradict it live.

How CRMs record a shared deal

Salesforce handles this with opportunity teams. Trailhead describes an opportunity team as a temporary group of people who help close a deal, and notes that each member is added with a name and a role. A default opportunity team can be added to every new opportunity automatically.

Credit is part of the same design. Trailhead explains that revenue splits divide the deal among team members and cannot exceed the deal total, while overlay splits can exceed it, to recognize extra expertise. Its example is a technical account manager credited for running a demo.

That detail answers a question many teams leave open: who gets credit when two people carry one deal. Writing it down before the handoff removes the incentive to keep the engineer out of the deal, or to pull them in too late.

The sales to customer success handoff

In this page's view, the sales to customer success handoff has the highest stakes of the six, because the customer is now paying and the gap is visible to them. It is also the one most often done as a forwarded email on the morning of the kickoff.

The receiving team needs three things only sales holds: what the customer expects to be true in the first months, what was promised to get the signature, and which parts of the deal are fragile. Everything else the CS team can look up.

The commitments row is the one that saves the relationship. A promise made in month two of a sales cycle and forgotten in month four becomes a broken promise in the customer's memory, even when nobody meant to break it.

The product scope row prevents a quieter failure. If a feature was demonstrated but not bought, the customer may still expect it. Customer success should know that before the customer asks, so the answer is a plan rather than an apology.

Closing the deal record as part of the handoff

The won deal itself carries handoff information. In Dynamics 365 Sales, Microsoft documents that closing an opportunity as won or lost asks the seller to verify details such as actual revenue, competitor, close date and description, and that the forecast category then updates automatically.

Microsoft adds that sales managers can later open the Opportunity Close activity to read what the seller entered. A team that adds its handoff fields to that close form gets the summary written at the one moment the seller has every detail fresh.

Where the handoff meets onboarding

For the customer, the handoff and the start of onboarding are the same event. They signed, and then someone new appeared. Everything the onboarding team does in the first weeks gets read as a verdict on whether the company that sold to them actually listened.

That is why the sequence is worth fixing in one place. An onboarding plan built from the handoff note starts with the customer's own goals. A plan built from a standard checklist starts with the vendor's steps, and in this page's view customers notice the difference in the first call.

The first value row is where the handoff connects to customer adoption. A customer who reaches the outcome they bought for early has a reason to keep using the product; one who is still waiting has a reason to ask why they signed.

Creating the onboarding record automatically

HubSpot's documentation shows how a won deal can start the next process. Its Create record workflow action can create tickets, projects, services and other records, with tickets requiring Service Hub Professional or Enterprise. A deal-based workflow can therefore open the onboarding record the moment a deal closes.

HubSpot also warns about a loop. When a workflow creates records of its own type, such as deals from a deal-based workflow, the new records must not meet the workflow's enrollment triggers, or they keep creating more records endlessly.

The default HubSpot project pipeline has six stages: Planning, Execution, Review, Completed, On Hold and Cancelled. Whichever object a team uses, the rule is the same: the onboarding record should open with the handoff note already attached, not with a link back to a deal nobody on the new team reads.

The handoff to customer support

Once a customer is live, day-to-day questions start, and many of them belong to customer service rather than to the success or onboarding team. This handoff is easy to forget because it rarely has a meeting. It happens the first time a customer opens a case.

Microsoft describes a case in Dynamics 365 Customer Service as a single incident of service, anything in a customer interaction that requires some type of resolution or answer. Cases track the process from the initial intake of an incident, through remediation, to the final resolution.

The same overview lists the parts that make support work: entitlements, which specify the amount of support services a customer is entitled to, queues, routing rules that send cases to a queue or a user, and SLAs that define what should happen when a case is opened, such as how long a response may take.

Salesforce frames case management in similar terms. Trailhead describes it as organizing customer cases into one place and making sure they go to the right person, for the right answer, by the right time, using queues, assignment rules, escalation rules and auto-response rules.

O*NET's profile of customer service representatives lists keeping records of customer interactions, recording details of inquiries, complaints or comments and the actions taken, and referring unresolved grievances to designated departments. Every one of those tasks goes faster when the account's handoff history is on the record.

• Entitlements: what the contract says the customer is owed, so support does not promise more or less.
• The setup as built: configuration choices made during onboarding, and why they were made.
• Known issues: anything that broke during onboarding and was worked around rather than fixed.
• Escalation path: who at the vendor owns the relationship, so a serious case reaches them.

Account management and renewal handoffs

Some companies hand the account to a separate account manager for renewal and expansion; others keep it with customer success or the original account executive. Either way, a handoff happens whenever a renewal window opens, a new need appears, or an owner leaves.

Salesforce draws the line between the two kinds of team in its own documentation. Trailhead notes that account team members can be expected to form a long-term relationship with a customer, whereas an opportunity team is a temporary group that helps close one deal.

A Trailhead project on account teams shows the practical side: account teams give sales reps, engineers, customer support reps and consulting reps access to the opportunities and cases related to the accounts they work on, with team roles such as Sales Engineer and Customer Support Rep.

When an owner leaves

The least planned handoff is the one caused by someone leaving. Microsoft documents a Reassign Records tool in the Power Platform admin center that moves every record owned by a user to another user or team, regardless of state, and notes it also unpublishes workflows assigned that way.

HubSpot allows one owner per record in the default owner property, and documents custom user properties for naming additional people related to a record. A team that wants a customer success owner and an account manager visible side by side needs those extra properties set up before the handoff, not after.

A bulk reassignment moves records, not context. When an owner leaves, the handoff note matters more than at any other seam, because the person who knew the account cannot be asked a follow-up question next month.

When to hand off, and when to wait

A handoff is triggered by an event, not by a calendar. Tying it to a date produces leads passed on because it is Friday, and accounts passed on because the quarter closed.

Wait when the trigger has not happened. A rep who hands off a meeting booked with someone who cannot buy, or an AE who hands off a signature with an open scoping question, is moving a problem rather than a deal.

Hand off early in one case only: when the receiving side has to be in the room to win. Bringing a solutions engineer into discovery, or a customer success manager into a late-stage call, is not a handoff. It is preparation for one, and it makes the later transfer far easier.

The handoff SLA, and what each side commits to

NIST's glossary, citing NIST SP 800-47 Rev. 1, describes a service-level agreement as a commitment between a service provider and one or more customers. It addresses specific aspects of the service, such as responsibilities, the type of service, the expected performance level including response times, and requirements for reporting and resolution.

A handoff agreement between two internal teams has the same shape, with one team as the provider and the other as the customer. The SLA for the marketing to sales boundary is set out on the MQL vs SQL page linked above; the table below applies the same clauses to every other seam.

Pick your own response windows and write them down. The number matters far less than the fact that both teams agreed to the same one and can see when it is missed.

What a handoff note contains

One handoff checklist covers every transfer on this page. The items change shape between them, the questions do not, and a note that cannot answer them is not ready to send. The checklist below was written for this page.

• Trigger: which agreed event happened, and on what date.
• Owner: who owned this before, who owns it now, and from what moment.
• Problem: what the buyer said is wrong, in their words, with a quote where you have one.
• Evidence: what they did, not only what they said: pages read, calls held, questions asked.
• People: names, roles, who is sponsoring this and who is resisting it.
• Promises: everything committed to so far, including anything said on a call and never written down.
• Risks: what could make this go wrong, written plainly rather than optimistically.
• Next step: the single next action, with a date and a named owner.
• Acceptance: confirmation from the receiver that they have read it and are taking it.

Keep the note short enough that it gets written. A checklist nobody completes protects nothing, and a nine-line note beats a three-page template that is filled in for two weeks and then quietly abandoned.

A handoff note, written for this page

The note below was written for this page as an example of the internal format. It is deliberately short, because the real test of a handoff note is whether it gets filled in on the day of the trigger.

Handoff: {{accountName}}
From {{fromName}} to {{toName}}, effective {{date}}

Trigger: {{trigger}}
Problem, in their words: "{{quote}}"
Why now: {{timingReason}}

People: {{champion}} (champion), {{decisionMaker}} (signs), {{skeptic}} (unconvinced)
Promised so far: {{commitments}}
Open risk: {{risk}}

Next step: {{nextStep}}, by {{nextStepDate}}
I am unsure about: {{unknown}}

The last line is the most useful one. A sender who names what they are unsure about gives the receiver a first question to ask, and signals that the rest of the note can be trusted.

The handoff meeting, warm or cold

A handoff meeting is where the written note gets questioned. It has two versions, and running only the second is a common way for a well-documented handoff to still fail.

Warm handoff vs cold handoff

A warm handoff means the two owners overlap in front of the buyer. A cold handoff means the buyer learns about the change when an unfamiliar name appears in their inbox.

This page does not suggest a meeting per lead for the marketing to sales handoff, because the volume is too high. The equivalent is a weekly review of disputed leads, which does the same job for a batch instead of a case.

What a handoff looks like in the CRM

In the CRM, a handoff is three changes at once: the owner field, the stage, and a written summary attached to the record. Doing one without the other two is where the process quietly breaks.

• Owner change: the record shows one name, with the date it changed and who changed it.
• Stage change: the lifecycle, lead, deal or ticket stage moves to the one that matches the trigger.
• The note: the summary sits on the record, not in a direct message that scrolls away.
• Acceptance flag: a field saying the receiver has taken it, so returns become visible.
• Timestamps: when the trigger fired and when the first touch happened, so the SLA is measurable.
• Return reason: a short picklist, so disputes turn into data instead of opinions.

Pipelines, required fields and automation in HubSpot

HubSpot's knowledge base explains that pipelines visualize a process through stages, with deal pipelines to track revenue and ticket pipelines to track customer issues. Its default sales pipeline runs from Appointment scheduled through Qualified to buy, Presentation scheduled, Decision maker bought-in and Contract sent, to Closed won or Closed lost.

For handoffs, the key feature is conditional stage properties. HubSpot documents that a stage can show chosen properties when a user creates a record in it or moves a record to it, and that a property marked required blocks the update until it has a value. That is a handoff note the system enforces.

Pipeline automation handles the notice. HubSpot documents automations on deal, ticket and project stages that create and assign a task, send an internal email notification or edit a record when a record enters a stage. A task for the receiver, due on the SLA date, is the simplest acceptance step there is.

For ownership, HubSpot's Rotate record to owner workflow action assigns records to paid sales and service users, with load balanced, round robin and random options for tickets and leads. A user who manually creates a record becomes its owner unless they choose someone else.

Where the note should live

Keep the note in the CRM rather than in a separate document. Anyone picking up the account later, after the CSM changes or the AE leaves, then finds the history where they already look, and does not have to ask who has the file.

Where the handoff sits inside the wider flow is a pipeline design question. Each transfer on this page matches a stage boundary, which is one reason building a sales pipeline and fixing handoffs tend to happen in the same week.

Ownership, acceptance and the return path

In this page's view, handoffs go wrong most often in the hours when nobody owns the account. The fix is to define ownership as continuous: the sender owns it until the receiver accepts, and the receiver owns it from the moment they do.

Acceptance has to be a real decision. If the receiver can only accept, the bar erodes, because everything gets passed on and worked. If they can return without a reason, the sender learns nothing and sends the same thing again next week.

Write three return reasons and no more: out of scope, missing context, wrong timing. Each implies a different fix, and a short list gets used where a long one does not.

Ownership has a compensation side too. If the sending team is paid on volume passed on and the receiving team on what converts, the two will disagree by design. Shared credit on the outcome, however partial, ends much of that argument, which is the logic behind the overlay splits described above.

Deciding who owns which seam is a revenue operations job in many companies, because the rules span marketing, sales and customer success at once. Where nobody holds that role, each pair of teams ends up negotiating its own private version.

How to measure handoff quality

The last row is the only one that justifies the work, and it is the slowest to move. Track the first five weekly, so you can fix the process before the sixth tells you anything.

Count buyer repeats by listening. A few calls a week, marking every time a customer explains something they had already explained to someone else, will tell you more about your handoffs than a dashboard will.

All six measures come from your own CRM: stage entry dates, owner change dates, a completeness flag and the return reason field. No outside benchmark is needed to see whether the numbers are moving in the right direction.

Why handoffs fail, and the common mistakes

• No agreed trigger. Each side has a private definition of ready, and both are certain theirs is the obvious one.
• Documentation is unpaid work. The sender is measured on the thing before the handoff and moves on the moment it happens.
• The note is a link. A link to a recording is not context, it is homework, and homework does not get done.
• No acceptance step. Ownership stays ambiguous for a day, which is long enough for a buyer to go quiet.
• Too late. Customer success meets the customer after the contract has already set expectations nobody can meet.
• No feedback loop. Bad handoffs get complained about privately and never corrected at the source.
• Tool sprawl. Context sits in a notes app, a chat thread and a recording tool, while the CRM holds the phone number.

Common mistakes in a sales handoff

• Treating the calendar invite as the handoff, so the first call opens with "tell me about yourself".
• Writing the note in categories rather than in the buyer's own words.
• Passing on the win and hiding the discount that bought it.
• Bringing the solutions engineer in without telling them what the AE already promised the product could do.
• Letting the previous owner stay the buyer's real contact, so the new one never becomes credible.
• Running the customer introduction before the internal meeting.
• Automating the routing and calling the automation a handoff.
• Handing an account to customer success with an open commercial question still unanswered.
• Reassigning a departed rep's accounts in bulk and assuming the context moved with them.

Setting up handoffs when you have none

1. Name the seams

   List every point where a lead, deal or account changes hands today, including the informal ones nobody ever wrote down, such as support escalations and departing reps.

2. Write one trigger per seam

   A single sentence both teams sign. If the two sides cannot agree on one sentence, you have found the real problem.

3. Build the note

   Start from the nine checklist items above, as required fields on the record rather than as a separate document nobody opens.

4. Add acceptance and returns

   One flag and three return reasons. Make both visible on the record and in the weekly report.

5. Set the windows

   Agree how fast each side moves after the trigger, write it into the SLA, and measure it from the first day.

6. Review weekly for a quarter

   Ten minutes on returns and misses. Once the disputes stop recurring, the review can move to monthly.

The order matters. Teams that buy routing software before agreeing on the trigger end up automating a disagreement, which makes it faster rather than smaller. Who owns these rules across functions is covered in GTM team.

In a sequence

The internal note above is only half of a handoff. The other half is the message the buyer sees, where the outgoing owner introduces the incoming one and repeats what the buyer already said, so the buyer does not have to. The email below was written for this page.

Subject: Introducing {{newOwnerName}}, who takes it from here

Hi {{firstName}},

From {{date}}, {{newOwnerName}} owns {{accountName}} on our side.

I have briefed them on what you told me: {{problemInTheirWords}}, and that {{expectedOutcome}} is how you will judge this in the first months.

{{newOwnerName}} will write today to set up {{nextStep}}. I stay on this thread until {{overlapEndDate}} in case anything is missing.

{{senderName}}

Frequently asked questions