A RevOps Playbook for Cross-Team Ownership in HubSpot
Broken handoffs between your teams are quietly wrecking your funnel. This playbook lays out how to fix it with clear ownership, shared visibility, and HubSpot automation. We’ll cover strategies for structuring multi-team ownership (when to split by team vs. brand), keeping everyone on the same page (think Gong calls, Outreach sequences, Aircall logs all visible in one timeline), and tactical how-tos like stamping last-touch by team in HubSpot.
The goal: no more “Who’s on first?” confusion. You’ll get decision frameworks, real field setups, workflow examples, and a few Dunder Mifflin cameos to keep it real. In short, you’ll learn to mind the handoff so every BDR, AE, AM, and CSM knows exactly who owns what, when, and your customer never feels dropped.
We’ve all felt this pain. One team thinks “I thought someone else was on it,” while the customer gets bounced around or, worse, left in a black hole. Broken handoffs aren’t just an internal nuisance; they hit revenue and relationships. Research shows a well-executed handoff makes a customer 3.5x more likely to stay on board. Mess it up, and you’re laying groundwork for churn. In RevOps terms: broken processes, unclear ownership, and manual follow-ups have real opportunity costs.
Handoffs in a B2B sales cycle aren’t easy or simple. In a typical SaaS business, a Business Development Rep (BDR) passes a lead to an Account Exec (AE), who closes the deal and then tosses the customer to an Account Manager or Customer Success (CS) rep. At each pass, there's a risk of fumbling it. Leads sit untouched by AEs, opportunities fall through the cracks, CS drops the onboarding and time-to-value drags on for the customer. Guess who churns? When “Who is responsible for this account right now?” is anyone’s guess, no one does.If your handoff is ad hoc, your funnel is leaking revenue. Even if you have the handoff process written down somewhere, do you know it’s being followed? Are you enforcing it? So much documentation rots in Notion. We need to fix the ownership questionat each stage of the customer journey. Think about the last time a customer asked you, “So…who should I actually contact now?” That’s a sign your internal ownership isn’t clear even to your own team, to say nothing of the poor prospect or customer who just wants to talk to someone.
HubSpot is an outstanding CRM (arguably the best, we’re all fans here), but it doesn’t magically solve human process issues. While we’re going to talk about the tech, these almost always start as human, process problems. Handoffs break for a few common reasons:
If it’s not crystal clear who is responsible for a lead or account at a given moment, everyone assumes someone else has it. Lack of defined ownership is handoff enemy #1. For example, if a deal closes and the AE moves on, but the Customer Success Manager isn’t formally assigned, the customer floats in limbo. In HubSpot, that might look like a contact still assigned to the AE while the CS team thinks “not my account yet.” Even if a CSM is assigned, do they have what they need in order to onboard the customer successfully? This kills your key “time to first value” for CS team success.
Many teams simply change the Owner field in HubSpot as they pass between teams. BDR does the hard work and reassigns the Contact or Deal owner to the AE. That’s better than nothing but it nukes historical data of who sourced or touched it last. Suddenly, reporting by original BDR or conversion rates per rep becomes impossible because the original owner is overwritten (a classic HubSpot gotcha). Lock it in today: Savvy operators create separate fields (e.g. BDR Owner + Sales Owner + CS Owner) to preserve that info. If you don’t, say goodbye to analyzing BDR-to-opportunity conversion by rep without digging through activity logs.
It’s hard to believe that in 2025, this is still an issue, but here we are. This is a classic: sales engagement happens outside of HubSpot without proper integration. If your BDRs live in Outreach or your AEs log calls in Zoom or Gong, those engagements might not be visible on the HubSpot timeline for the next team. The result? The AE has no idea the BDR already emailed that lead three times last week (because those emails sit in Outreach and didn’t sync over). Or the CSM doesn’t see the sales call recording (because it’s in Gong, not linked in HubSpot). In short, one team’s activities are siloed, so the next team is flying blind. Have you checked the GTM team’s shadow stack lately? Teams should be encouraged to use point solutions where it makes sense and provides functionality otherwise missing from HubSpot. However, Rev Ops needs to bring a critical eye to these purchases: if the tool can’t feed data into your CRM, that’s a red flag! Most GTM software segment leaders integrate with HubSpot at this point, but there are some weird quirks. In any case, we need to fix the visibility gap making sure tools like Gong, Outreach, Aircall, and Zoom feed engagement data into HubSpot where everyone can see it. You can use hubspot Teams to limit visibility, if you want certain data protected from prying eyes.
If your handoff process lives in someone’s head or a Slack message, you’re set up for failure. Life and work is complex: it’s not fair to ask teams to remember all this. Relying on an AE to remember to email the CSM with context, or a BDR to ping an AE in Slack, is not a system. “I think I told them about Acme Corp…did I?” is not a process. HubSpot can automate a lot of this (task creation, notifications, ownership changes)...if you set it up. If not, expect missed signals. As a RevOps manager, one of your jobs is to remove discretion from the critical path: use workflows and fields so that handoffs happen systematically, not at the whim of busy reps. Start small, you don’t need to go nuts with this.
Finally, you can’t improve what you don’t measure. Many teams don’t track handoff success metrics. How long does it take from a demo being completed to an AE actually engaging? What percent of closed-won deals get a CS follow-up within 24 hours? If nobody owns the handoff outcome, it falls into the cracks. We’ll talk about reporting later (e.g. creating a report for “untouched new customers” or “BDR -> AE handoff time”). Assign an owner to the process itself: maybe your RevOps manager or a team lead who is responsible for monitoring that handoffs occur on time. If the handoff isn’t happening in the way you want, think carefully about enforcement. Is your team properly incentivized? Do you run a competition for your CS team to accelerate “time to first value”? If an AE doesn’t pick up an inbound or BDR sourced lead fast enough, does the lead go to the next AE to have a show? Compensation design is out of the scope for this article, but it’s an important lever managers can pull and you should be aware of it.In summary, handoffs break because of fuzzy ownership, lost data, siloed tools, reliance on human memory, and lack of accountability. While many of these are human problems, HubSpot gives us the technology to fix a lot of it. It’s on the entire GTM team to practice the right habits. But it’s on the operator to design the system so practicing those habits is easy!
Defining Ownership Across Teams (Team vs. Brand)
Before we dive into tactics, you need a strategy for how you assign and segment ownership in HubSpot. Let’s break it down by two dimensions: by team role (BDR, AE, AM, CSM, etc.) and by segment/brand (if your business has multiple product lines or brands). Let’s outline a decision framework to get this right. Of course, your business might have different ways of lead handling. This is not meant to be prescriptive to all instances, but an example of the type of thinking required to get this right.
First, clarify the stages of your customer lifecycle and assign a single owner role for each stage. For a typical B2B company, a simple map might look like:
Lead Qualification (BDR/SDR) – Owner: BDR. This covers from Marketing Qualified Lead to Sales Qualified Lead (SQL). The BDR owns outreach and qualification.
Opportunity & Closing (AE) – Owner: AE. From SQL/Opportunity created through Closed Won/Lost, the Account Exec is responsible.
Onboarding (Implementation/CSM) – Owner: Implementations or Customer Success. Right after the deal is won, a CSM or onboarding specialist takes over.
Ongoing Account Management (CSM/AM) – Owner: Customer Success Manager or Account Manager for the life of the account (renewals, upsells, support).
This seems straightforward, but get your leadership to agree and document it. This is often harder than you think, and you may need to put on your “hostage negotiator” jacket to iron this out between all the teams. This is not a technical project but a process mapping exercise. Don’t rush it!
State the owner for each stage clearly in your playbook. When everyone knows “who’s on point” at a given stage, you’ve solved half the battle. Ensure every stage has entry/exit logic and ownership: when it’s time to change owners, does the next person in line have what they need
Reflect these stage owners in HubSpot. That could mean using the built-in Lifecycle Stage property in Contacts/Companies with values like Subscriber, MQL, SQL, Opportunity, Customer, etc., and aligning each stage to a team. Call them whatever you want, just make sure everyone on the GTM team knows what they mean.
If you prefer custom properties or statuses (some folks use a custom field “Lead Status” or “Deal Stage Owner”), that’s fine. The key here: don’t just use whatever HubSpot suggests in their settings. Customize it to your business. The key is that when a record moves to a new stage, HubSpot should either automatically assign the new owner or (if you insist on doing things by hand) prompt someone to do it.
For example, when a Deal is created (SQL), set the Deal Owner as the AE, but keep the Contact Owner as the BDR until the AE engages. Once the AE has that first meeting, you might trigger a Contact Owner change to the AE as well. Then on Closed Won, trigger assignment of Company Owner (account owner) to the CSM. In this instance, you would keep the deal owner set as the AE. Each handoff is a distinct moment with a definitive ownership change.
HubSpot’s default is one owner per object (contact, company, deal). But you might need to track multiple roles simultaneously. For example, some orgs keep the Contact Owner as the BDR even after an AE is working the deal, until a certain point (to credit the BDR for sourcing). Others might have two reps actively involved (say, an AE and a Solutions Engineer) and want both associated.
Cautionary sidebar: HubSpot now allows creating custom HubSpot User fields, including a multi-select user property (meaning a record can have multiple owners listed in one field). Use this feature judiciously. In fact, I almost never recommend this. Multi-select fields almost always make life more difficult than you think they would.
But if your process truly has co-owners, you can create a field like “Secondary Owner” or a multi-select “Owners (Multiple)”. But avoid muddying who the primary accountable owner is. Multi-owner scenarios often lead to, “I assumed the other owner did it.” If you do use multi-select owner fields, define what each person’s responsibility is (e.g. AE is primary, SE is secondary with a specific role). Truly, I don’t believe this is the way to handle multiple-owners in hubspot. /rantover
A better pattern is to use role-specific owner fields. For instance, on a Company record you might have “BDR Owner”, “AE Owner”, “CSM Owner” as separate properties (all of type HubSpot User). This way, even after ownership moves on, you keep a record of who was the BDR or AE.
It also allows simultaneous assignments. A contact might have BDR Owner = Alice, AE Owner = Bob, CSM Owner = (empty) until later. During the sales cycle CSM Owner might be blank, then filled at Closed Won. This is how you preserve history for reporting (like how many deals each BDR sourced, even if the live owner is now an AE).
If you create custom owner fields, consider automation to populate them. For example, when a deal is created by BDR Alice, auto-set a custom BDR Owner field on the deal or contact to Alice (so even when the HubSpot Owner later changes to Bob the AE, you have Alice recorded). You can do this with this example workflow:
Trigger: Deal stage changes to SQL (or deal created) AND Owner is known AND Team is not Sales;
Action: Copy Owner to BDR Owner (not BDR Owner=Alice), then set a new owner on your sales team (round robin or whatever makes sense for your business) so Owner = Bob the AE. Then copy Owner to Sales Owner, so now you have three owner fields in hubspot:
1. BDR Owner = Alice
2. Sales Owner = Bob
3. Owner = Bob (was Alice before)
This way the info is locked in a permanent field, solving that HubSpot quirk where historical owner info is otherwise lost on change.
Now, if your company runs multiple business units, teams, or brands (each with their own sales teams and customers), you have an extra layer to consider. The question is: do all teams share one HubSpot portal or not? And if yes, how do you delineate ownership by brand?
HubSpot offers Business Units (mainly for marketing assets segmentation) if you’re on Marketing Hub Enterprise. However, Business Units don’t solve CRM record ownership sharing by themselves. They’re more about separating content and tracking per brand.
If your brands have totally separate customer bases and rarely overlap, some companies actually go with separate HubSpot accounts (portals) per brand. The downside: zero visibility across brands, duplicate admin work, and of course, it’s expensive. The upside: you keep data and process quarantined within each portal.
For mid-size B2B (50–300 people) it’s almost always preferable (and cheaper) to use one HubSpot portal for multiple teams/brands, and segment within it. To do that, you need a way to assign owners by both team and brand without chaos. Here’s a playbook from experience:
Use Teams and Permissions: HubSpot’s Teams feature lets you group users (e.g. “Brand A – Sales”, “Brand B – Sales”, “Brand A – CS”, etc.). You can then set CRM access rules like “Users can only view contacts owned by or assigned to their team.” This is critical if you want to avoid Brand A reps snooping Brand B’s contacts (or just to declutter views). In your case, maybe BDRs and AEs are split by brand or region; you can nest teams. For example, one Sly Orange user had Brand A as a parent team, with sub-teams for BDR and Sales under it.
Consider Brand-Specific Owner Fields: As an advanced solution, some RevOps pros create separate owner fields per brand, akin to what we suggested above. For example, Brand A Owner, Brand B Owner, etc., on the Contact/Company. This is a workaround to allow two teams to “own” one account in parallel. In one user’s case, they had scenarios where an account was sold across multiple product lines (Brand A and Brand B), each with different reps, and they wanted both reps to have visibility. By populating both Brand A Owner and Brand B Owner on the same record, a HubSpot permission rule “user can view records owned by their team” would let both teams see it.
Gotcha: This approach can get complex. You’ll need workflows to keep those brand owner fields in sync with activity. For instance, if someone from Brand A’s team engages with a record and thereby becomes an owner, you’d update Brand A Owner field accordingly. And as the example shows, you might end up making “last touched by Brand A” date fields… it can spiral. So only go down this road if you truly have accounts jointly managed by multiple brands.
Split by Pipeline: Another way to handle multi-brand is using separate pipelines for each brand or product line (if the sales process differs). You could have “Brand A – Sales Pipeline” and “Brand B – Sales Pipeline” in Deals. This naturally segregates deals, and you can even use pipeline-specific workflows to assign different owners or teams. The company and contact might remain shared, but deals are separate. Many companies do this for separate product lines (with separate AEs) while sharing the master company record for a 360° view. Note: we only recommend this when the sales processes for each brand are different enough to warrant a separate pipeline setup. If you are cloning the pipeline across multiple brands, it's easier to just mark a field on the deal indicating which brand the deal applies to.
When to Split Portals: If your brands are so distinct that they share zero overlap in data and require totally different HubSpot customizations, you can split into multiple HubSpot accounts. But then cross-team visibility becomes literally impossible because data is in different systems. That’s a last resort for extreme cases (or if required for legal data separation). For most scale-ups, a single portal with clear segmentation is the way. Don’t overcomplicate it…even if HubSpot would love to sell you another portal.
Decision framework summary
Use one portal unless there’s a compelling reason not to, leverage Teams to partition where needed, and introduce custom owner fields (or multi-select owners, if you must) if and only if a single Owner property can’t cover your use case. Always bias towards clarity (one record, one clearly accountable owner) and layer on complexity only to the extent that reality forces it.
Once ownership roles and fields are defined, the next challenge is ensuring everyone can see the full picture. When a BDR hands off to an AE, that AE shouldn’t need to dig through two other tools and an email thread to know what happened.
Similarly, when an AE hands off to CS, the CSM should have everything they need to know about the account’s journey so far in HubSpot (or whatever tool they are using, covering that possibility isn’t in the scope of this article). This is where cross-team visibility comes in: making sure that all engagements and data are logged in one place (your CRM) and accessible to the right people.
Once ownership roles and fields are defined, the next challenge is ensuring everyone can see the full picture. When a BDR hands off to an AE, that AE shouldn’t need to dig through two other tools and an email thread to know what happened.
Similarly, when an AE hands off to CS, the CSM should have everything they need to know about the account’s journey so far in HubSpot (or whatever tool they are using, covering that possibility isn’t in the scope of this article). This is where cross-team visibility comes in: making sure that all engagements and data are logged in one place (your CRM) and accessible to the right people.
Email Sequences & Sales Engagement (Outreach, Salesloft, Apollo Sequences): If your BDRs use external tooling to email prospects (whether 1-1 emails or 1-to-many sequences), ensure those emails sync to HubSpot. This usually means connecting your Gmail/Outlook to both systems or using the BCC address HubSpot provides ([your HubID]@bcc.hubspot.com). Ideally, use the native HubSpot-Outreach integration or HubSpot’s own Sequences. The goal is that every email sent or replied is visible on the contact’s timeline in HubSpot. A gotcha on some vendors: their native integration may only syncs contacts and some activities one-way. Confirm that email activities are logging. If not, implement a process where reps either use the HubSpot sales extension or BCC HubSpot on Outreach emails. No one should have to ask, “Did anyone email this prospect?” There’s no excuses to not have this set up. Buried in the hubspot activity settings are the email log and track settings. You should make sure to review these for everyone in your portal. We typically recommend the following on the hubspot email (note users can override them in their personal settings):
Calls and Voicemails (Aircall, Zoom Phone, HubSpot Calling): If phone conversations happen, log them. Tools like Aircall have a tight HubSpot integration that automatically logs calls (with duration, outcome, recordings, etc.) to contacts, companies, and deals. In Aircall’s case, within seconds of a call, HubSpot records the call activity with a link to the recording and notes, even SMS texts as an engagement type. If reps sometimes call via their cell or Zoom, encourage them to log those calls in HubSpot after the fact (or use HubSpot’s mobile app with calling features). Zoom can integrate too – if you use Zoom for sales meetings or demos, turn on the setting to sync Zoom meetings to HubSpot. That can log meetings attended as timeline events, and even drop in cloud recording links or transcripts if configured. The result: when a CSM opens a customer’s contact record, they see every call and meeting that has happened, regardless of whether it was via Aircall, Zoom, or HubSpot’s native calling. No blind spots.
Sales Call Recordings & Analysis (Gong, Chorus): Many AEs love Gong, Fathom, Fireflies, etc. for call recording and analytics. Gong can auto-export call records to HubSpot, typically as completed call activities or meeting records with a link to the Gong recording. Make sure this is enabled. Yes, there might be up to a 6-hour delay for Gong to push the data, but it’s better than nothing. This means if an AE had a discovery call, the CSM can find the link and listen to the recording right from HubSpot (and not have to ask the AE “how did it go?” or search in Gong separately). Other call recording tools have their own quirks: it’s worth digging into this to make sure you have it right, as these recordings are a goldmine for unstructured data you can feed into LLMs.One caution: avoid double-logging. If you also use Zoom and it logs a meeting, and Gong logs the same meeting, you could clutter the timeline with duplicate events. Decide on one source of truth for each type of engagement. Maybe treat Gong calls as call-type engagements and disable Zoom logging for those meetings. The end state should be one timeline, key touchpoints, minimal noise.
Sales Outreach (Sequences, LinkedIn, etc.): HubSpot Sales Hub has Sequences, and if your BDRs/AEs use it, all those touches are naturally logged. If they use LinkedIn messaging as outreach, that’s harder to auto-log (some tools can sync LinkedIn messages, but often not). HubSpot can at least open sales navigator right within a record, but it’s not a seamless experience. In such cases, consider manual logging or at least notes. We’re aiming for signal, not noise: 100% of emails/meetings, and at least notes for significant conversations that happen elsewhere.
Customer Success Engagements (Email, Ticketing, Chats): Don’t forget post-sale. If your CS team uses HubSpot Service Hub (tickets, conversations), great, it’s already centralized. If they use something else like Zendesk, integrate it or at least surface the info in HubSpot (e.g., use the Zendesk-to-HubSpot integration to log tickets on the timeline). The new account owner should see if the customer has opened support tickets or had issues recently. Similarly, if CSMs primarily email customers, make sure they are logged in through HubSpot, so the AE (if they ever get involved again for upsell or renewal help) can see the interaction history too. The baton might get passed back and forth (say Sales gets involved in a renewal), so visibility has to go both ways, Sales seeing CS touches and vice versa. This is also critical if an account manager on your CS team gets promoted, reassigned to a new account, or leaves the company; whoever takes over should have as much context as possible when they take the account.
In short, integrate your tools. Gong, Outreach, Aircall, Zoom: these aren’t just logos to mention; they’re part of your RevOps data fabric. Each of them, when connected properly, feeds engagement data into HubSpot’s activity timeline. That timeline becomes the de facto ledger of truth. You want anyone opening Acme Corp in HubSpot to be able to answer: when was the last time anyone from our company touched them, and who was it? Was it a BDR’s call? An AE’s email? A CSM’s QBR meeting? It should all be there.
A quick note on permissions: cross-team visibility doesn’t mean every rep sees everything. Use HubSpot Teams and user permissions to strike the right balance. For example, you want Sales and CS to see each other’s contacts once they’re customers, but not before. Or allow all sales roles (BDR, AE) to see all leads until they become customers (so BDRs can see if anyone is working an account). Transparency is generally good for alignment, but each org has sensitivity (e.g., maybe BDRs shouldn’t see accounts owned by another segment).
If you insist on creating a custom “multi-team” owner field (which again, I rarely recommend), note that HubSpot does not automatically use that for permissions. However, you can possibly fudge by adding users to multiple teams or leveraging the “View Team and Child Teams” permission setting. If in doubt, simplest is often best: set Contact/Company owner as the one main owner (which grants them visibility), but then for others who need to see it, either make them on the same Team or use the additional owner fields only for reference, not access control.
Our goal in this section is to eliminate the excuse “I didn’t know X happened with this account.” With unified logging and appropriate sharing, that excuse goes away. When Sales says “I logged that call in HubSpot,” CS can actually find it. When CS solves a support issue, Sales can see it before upselling. This builds trust internally and gives your customers a seamless experience.
That being said, teams shouldn’t need to play detective through the entire engagement history to see what’s up with an account. Take advantage of HubSpot’s included Breeze Record summaries to summarize accounts in ways that make sense to you!
Now let’s get into the fun stuff: fields and workflows in HubSpot that will operationalize these ideas. By setting up the right properties, you create a common language for cross-team ownership. Here are the must-haves and a few nice-to-haves. We usually recommend having these core fields on all the core objects (contacts, companies, and deals). This makes reporting easier down the line so don’t have to mess with cross-object reporting to track conversions and performance across teams. Again, we’re using the classic BDR-AE-CSM model, but you should customize this to your business:
BDR Owner – A HubSpot User type property on Contact (or Deal) to store who originally sourced or qualified the lead.
Example: Original BDR (the BDR who first worked the lead).
Rules for Use: This should be set once and only overwritten if the owner changes to another person on that same team. If you’re using HubSpot’s built-in “Contact Owner” to assign BDRs, you’ll want to capture this before reassigning the contact to an AE.
Why it's Important: So you can later filter or report “Deals by BDR” or measure each BDR’s SQL to Opportunity conversions, even though they aren’t the owner at close. Without this, once you reassign, that info is gone unless you dig into property history.
AE Owner – A custom HubSpot User type field (e.g., Account Executive) to hold the AE’s name.
Example: A custom Account Executive field on Contact/Company, even while the official contact owner is still the BDR.
Rules for Use: Some teams choose to keep the Contact/Company owner as the BDR until the deal is won, and only then change the owner to CS. In that case, you might track the AE on the Deal record only. But it can be handy to have it on Contact/Company too.
Why it's Important: Allows for parallel tracking during the sales process, ensuring AE attribution even if they aren't the primary Contact Owner.
CSM/AM Owner – A custom property on Company (or Contact) to denote the ongoing account owner post-sale.
Example: A separate CSM Owner field on Company, distinct from the Company Owner if that remains the AE.
Rules for Use: Often people will eventually make the main Contact/Company Owner be the CSM for customers, which is fine. If you do that, consider keeping the AE recorded somewhere (e.g., Company “Original AE” or a read-only field set at deal close). Alternatively, you leave Company Owner as AE and have a separate CSM Owner field.
Now that you have the basics, here’s where things get interesting:
Last Touch By User and Last Touch By Team – This is a bit more advanced, but extremely powerful for visibility. The idea is to have properties that automatically update to reflect who last engaged the contact/company and which team they’re on. For example, Last Engagement User and Last Engagement Team. Whenever someone logs an email, call, or meeting, these fields on the object update to that user and that user’s team. HubSpot doesn’t do this natively (it has “Last Contacted” date, but not who contacted).
However, this can be achieved via custom code workflow or a third-party like SlyOrange. In fact, SlyOrange creates exactly these fields on install and updates them in real-time via webhooks:
Last Activity User – who performed the most recent engagement.
Last Activity Team – the team that user belongs to.
Last Activity Type – was it an email, call, meeting, etc.
With or without an app, capturing these is the necessary but not sufficient condition for cross-team awareness. Once you have these fields, you can use workflows to datestamp when each team last engaged. Then you’ll have fields that look like this:
Last Sales Activity User – who on the sales team performed the most recent engagement?
Last Sales Activity Type – was it an email, call, meeting that sales had?
Last Sales Activity Date – when was the last sales touch?
Last CS Activity User – who on the CS team performed the most recent engagement?
Last CS Activity Type – was it an email, call, meeting that CS had?
Last CS Activity Date – when was the last CS touch?
%20(1).png)
Once you have these fields, you can do fun things like calculate and report on the time between the last sales touch and first CS Touch as an indicator for handoff velocity. More on that later.For instance, you could look at a company and see “Last Activity Team = Sales” which tells the CSM, “hey Sales touched this account last” (maybe working an upsell?), or vice versa “Last Activity Team = CS” tells the AE that CS has been in contact recently. You could trigger alerts to to the sales owner if CS has been involved lately. Sky’s the limit!
Without a dedicated tool: you can approximate this with HubSpot workflows workflows triggered when an activity is logged; the downside of this approach is that object re-enrollment doesn’t trigger off of additional activities logged. So, you might be able to use this pattern for the first CS touch, but not the second, and that might be enough for you! But if you have multiple teams touching the record, it gets unsustainable.(As of Q3 2025, HubSpot can’t trigger workflows using the activity as the primary object in workflow, which is a whole separate talk show).
One hack: use contact property “Last Engagement Date” (which HubSpot auto-updates for some events) plus some custom code action that reads the latest engagement via API and sets the user.
This is a case where leveraging a tool or API script saves a ton of headaches, which is why tools like SlyOrange exist.
Later in this article, we’ll show how to implement last-touch logic both manually and with SlyOrange, so hold that thought. Just know that having a “last touched by [team]” field is a game-changer for quickly answering, “Who owns this account right now?” Maybe Sales technically owns it, but if CS was the last to talk to them, you get context at a glance.
Handoff Timestamp Fields (optional but useful)
If you want to measure handoff efficiency and speed, create date/time fields like “SQL to AE Handoff Date” or “Closed Won to CS Handoff Date”. Populate them via workflows at the moment a handoff occurs (e.g., when deal stage changes to Qualified and an AE is assigned, set SQL->AE Handoff Date = now). This lets you later calculate time gaps (e.g. how long from handoff to first CS contact).
If that’s too granular, you can simply use existing date fields (e.g. the date a deal was created as the handoff from BDR to AE, and date the first CS task created as AE->CS handoff). The downside with this latter approach is that it can be inconsistent because they rely on manual efforts.
Finally, document these fields in a mini data dictionary for your teams. Make sure everyone knows what “Last Activity User” means, or what it means when Lifecycle Stage changes. Clarity in definitions prevents the “I wasn’t sure if I should update that field” issues.
Fields alone won’t solve handoffs: you need workflows to move the baton. Let’s talk through some HubSpot workflow examples that enforce your handoff process.
Trigger: BDR qualifies a lead (e.g. Contact’s Lifecycle Stage = SQL, or BDR books a meeting). Often the trigger is “Deal created” in a certain pipeline, if your process creates a Deal at qualification.
Actions:
1. Assign the Deal to an AE (round-robin or based on territory).
2. Create a task for the AE: “New SQL from [BDR Name]: follow up with [Contact]” due within X hours.
3. Optionally, notify the AE via email/Slack.
4. Also, copy over context: you might use HubSpot’s workflow actions to set some fields on the deal like “BDR notes” or include recent engagement info.
Owner: System/RevOps owns making this workflow, but from a human standpoint, the AE becomes the new owner. The workflow should also update ownership fields: e.g., set Deal Owner = AE, and you might also change Contact Owner = AE (or you might wait until the AE actually connects). Some teams leave Contact Owner as BDR until the AE has the first call, to ensure BDR gets credit for SQL count. Do what makes sense for your business.
Measure: SLA on AE follow-up – e.g., time from deal create to first contact attempt. You can derive that from the last contact date minus deal create date, or use tasks completion time. This helps catch if AEs are not picking up what BDRs are putting down. If your BDR to AE handoff is solid, there should be no SQLs going untouched beyond the agreed time (say 24 hours). A simple dashboard chart “SQLs with no activity in 24h” solves that.
Trigger: Deal stage changes to “Closed Won”.
Action:
1. Assign Company Owner (or a custom CSM Owner field) to the appropriate CSM. This might be territory-based or a round robin in the CS team.
2. Create an Onboarding Task or Ticket for the CSM: e.g. “Welcome new customer – schedule kickoff with [Client Name]” due within 1 business day. Include key info from sales: perhaps use workflow to populate the ticket description or task with notes like “Deal amount, use case, any special notes” pulled from deal properties or a handoff notes field AEs fill in. If you have a formal handoff playbook document (some use a HubSpot Playbook or a custom object for handoff info), link it.
3. The workflow can even post a message in a Slack channel #new-customers, tagging the CSM and relevant people.
Owner: CSM becomes the new external owner to the customer. Internally, the Sales -> CS handoff might have a RevOps or Implementation Manager overseeing it. Make that explicit if needed (maybe a RevOps person is tasked to ensure all steps done for each new customer). The workflow automates notifications, but a human should be accountable to monitor nothing slipped through (this could be an operations person or CS team lead).
Measure: Time to CSM first contact (Closed Won to First CS Meeting Date; you could use the last meeting date by team field we set up earlier to do this). You might log when the CSM completes the onboarding task or when the first meeting is held.
BONUS: measure Handoff Completeness. For example, did sales fill all required fields for CS before marking Closed Won? Use required properties on the Deal stage or a workflow that checks for empty critical fields (like missing “Closed Lost Reason” in losses, or missing “Onboarding Notes” on won deals) and alert if incomplete. You can also gate your closed-won deal stage, so AEs can’t win a deal until the data is complete. This gets back into incentives; if a customer hasn’t had a good onboarding experience because sales dropped the ball, the sales team should be held accountable for it.
As RevOps, you can even set up exception reporting: any deal won in last X days where “Kickoff Scheduled” date is blank gets flagged, so you catch new customers that aren’t set up to be engaged by CS.
This one is more complex but worth mentioning conceptually. If you don’t have a third-party tool, you can use a workflow with a custom code action (requires Operations Hub Pro or Enterprise) to update Last Activity User/Team fields.
Trigger: Updates to HubSpot’s “last activity date field”, which updates any time a call, email, meeting, or note is logged against a contact/company/deal.
Action: Custom Code (JavaScript in a workflow) that calls the HubSpot API to find the latest engagement on that record, pull the hubspot_owner_id or user, and set the contact’s Last Activity User and Team fields accordingly. You’ll need to figure out how to track meetings that are set up in the future or are cancelled.
Owner: RevOps/ops engineer to build and maintain this. There’s no ongoing human owner; it’s an automation that keeps data in sync.
Measure: N/A for performance, but you measure outcomes enabled by this, like how many accounts had a sales touch vs CS touch in a period.
If building this is not in your wheelhouse, SlyOrange comes in: it provides this logic out-of-box in real time. It will create and maintain Last Activity User/Team/Type/Timestamp for you. It even offers backfill services to populate historical data (imagine updating millions of past engagements…not fun to do manually. The net gain: any rep can glance at a record and answer “when, how, and by whom was the last touch.”
This is a guardrail type workflow. Scenario: a BDR goes rogue and starts working an account that’s already owned by, say, an AE or CSM. Or Sales engages a customer for upsell without looping in the account manager. If that’s a no-no in your org, you can catch it. How?
Trigger: Engagement logged by Team = Sales on a record where Lifecycle Stage = Customer (or Support rep reaches out to a prospect not yet closed).
Action: Send alert to the CSM and maybe Sales manager: “Heads-up: Sales rep X just contacted your customer Y (Owned by CSM Z).”
Owner: RevOps/Ops Engineer to build; Sales/CS Managers for ongoing human oversight.
Measure: Reduced instances of unintentional cross-team contact or improved collaboration and alignment on customer accounts.
Maybe it’s fine (collaboration on upsell), maybe it’s not (AE poaching a CS account). But an automated FYI can spur the right internal conversation. In reverse, if a Support rep reaches out to a prospect not yet closed, you might alert the AE.
These are edge cases, but they give you an idea of how once you have the data, you can automate guardrails to maintain clean lines or at least transparent exceptions. You can power up these guardrails by using enablement and rule-setting tools like Supered as well!
Not every lead converts, not every deal closes. Have a plan for recycling: e.g., if an AE disqualifies an Opportunity (Closed Lost reason = Not a fit now), perhaps that company goes back to a Marketing nurture or a BDR for later cadence. You can automate that.Trigger: Deal Closed Lost with certain reasons (timing, product isn’t mature enough) OR no activity on an Opportunity for 30 days (the deal stalled, the buyer ghosted, etc.).
Action: If criteria met, clear the sales owner field, and reassign a BDR, or keep the same BDR. Perhaps set a “Recycle Date” field. Create a task for someone (BDR or Marketing) to touch base on the “Recycle Date”. And crucially, update status fields (e.g., mark the contact back to a custom “Recycled” stage).
Owner: RevOps to orchestrate, BDR/Marketing to execute follow-up.
Measure: How many recycled leads get reactivated, or how many fall through? This ensures that after AE says “not now,” it doesn’t just disappear. Instead it’s either re-marketed or given to an outbound team. Cross-team ownership also means knowing when to give up ownership. If Sales isn’t actively working it, explicitly hand it off to Marketing/BDR for recycling. Don’t have it languish under an AE who’s moved on to better opportunities.
These examples scratch the surface, but the pattern is: identify each handoff or status change, and automate the transition as much as possible. Use Triggers that correspond to a stage change or activity, specify the Action clearly (assignment, task, notify, field update), designate an Owner (the person/team now responsible), and define a Measure to watch it.
One of the trickiest parts we identified is capturing last-touch attribution by team. Let’s break down two approaches: without a specialized tool and with SlyOrange. This gets a bit technical, but it’s the tactical meat for advanced HubSpot admins.
What you can do natively: HubSpot has built-in date fields like Last Contacted (the last time a sales email, call, or meeting was logged by a user) and Last Activity Date (last time any activity including notes/tasks was logged). Those are useful for triggers, but they don’t store who did it or what team. However, you can hack together a solution:
Create custom fields: Last Activity User (User type), Last Activity Team (Dropdown or text), Last Activity Type (dropdown with call/email/meeting, etc.), Last Activity Time (datetime). These will mirror what we described earlier.
Use a custom code workflow action: If you have Ops Hub, one workflow trigger “Last Activity Date is updated” (not sure if that exists as trigger directly) or just run a scheduled workflow daily on contacts/companies, then use a Custom Code action to call the HubSpot API for recent engagements. The API can return engagements sorted by timestamp, get the latest one and its user. This requires a developer, but you’ll need to consider the following: which engagements types to process, error handling, treatment of deleted engagements, other intricacies unique to your business.
Batch updates: You might have to run batches to initialize the values for existing records (or bite the bullet and only populate going forward, leaving old records blank or doing a one-time backfill script).
Maintenance: The DIY approach is maintenance-heavy. Anytime teams change or new engagement types come (what about LinkedIn InMail logged as a note? SMS logged as an engagement via Aircall? You’d need to incorporate those too. Aircall logs SMS as a type “SMS” engagement. Essentially, you are programming business logic. It can work but expect to babysit it, especially if you vibe code it ;)
Pros: Full control, no extra cost if you have the in-house skill. Cons: Opportunity cost of your time, risk of something not updating in real-time, and you might hit HubSpot workflow limits if volume is huge. Also, it’s only as accurate as your triggers; if someone logs a backdated call or edits an old note, could throw off things.
Despite those cons, many RevOps folks do at least a basic version: e.g., they use Last Contacted date and maybe a field Last Sales Owner which they update whenever owner changes, to approximate last touch by each team. It’s better than nothing, and we applaud any and all efforts to improve!
SlyOrange is built to solve exactly this last-touch problem in HubSpot. Since this is not a sales pitch, we’ll just describe how it works and how you’d use it.
What it does: On install, it automatically creates the custom properties on your HubSpot portal (Last Activity User, Team, Type, Timestamp). It then listens to HubSpot via webhooks for any new engagement (email, call, meeting, etc.) and instantly updates those fields on the associated Contact, Company, and Deal. It uses the HubSpot Team of the user who logged the activity (the “primary team” in case of nested teams). For example, if a call is logged by user X on Contact Y, within seconds Contact Y’s Last Activity fields are updated: User = X, Team = (Team X belongs to, say “Sales Team”), Type = Call, Timestamp = now.
Historical backfill: Suppose you install it today, you might want past data too. SlyOrange has a backfill option (one-time job) to crunch through all past engagements and set the fields accordingly. That could be a lifesaver if you want immediate reporting on “who touched all these accounts last” without waiting months for it to populate.
How to implement last-touch logic by team using SlyOrange: Basically, you authorize the app with HubSpot, it sets up those fields and starts doing its thing. You as an admin should then incorporate those fields into your views, reports, and workflows:
1. Add Last Activity Team as a column in your Companies view, for example, or create active lists like “Accounts last touched by Sales team > 30 days ago” for each CSM to monitor.
2. Use Last Activity User in dashboards to give credit or to see activity distribution (e.g., you can see if certain reps are touching way more accounts).
3. Use Last Activity Type to analyze which channels are being used last – maybe you’ll find 70% of last touches are emails, 20% calls, 10% meetings, which can spark a strategy talk (“Should we call more often if email responses drop?”).
Edge cases: It even accounts for meetings scheduled in the future: Sly orange checks hourly if a scheduled meeting time has passed and no one marked it held, and then treats it as last activity when it happens. This covers cases where reps don’t click “meeting occurred” (which they almost always forget); however, if the meeting is cancelled or deleted, Sly Orange doesn’t update the record, since the meeting didn’t actually occur.
Without vs With example: Let’s say you don’t use SlyOrange. You might have manually managed Owner fields and rely on Last Contacted date. If the CEO asks, “Sales says they’ve been in touch with the 50 clients on this list, but CS says they haven’t heard from them in months. What’s true?” you’d have to dig into the timeline and manually figure out the last contact.
With SlyOrange, you can just check Last Activity Team on that client: if it says “Sales” and a recent date, it means Sales indeed was the last to engage, and CS probably hasn’t reached out in a while. If it says “CS” and a really old last activity date, then Sales might be mistaken. Or, because you are a sly operator, you even build automation taking advantage of SLy Orange to stamp “Last Sales Touch” and “Last CS Touch”, so you can say exactly when each team last engaged.
You get an objective answer in seconds, not finger-pointing. It stamps a source-of-truth field for “last touch attribution” inside HubSpot, which is hugely helpful for RevOps and managers to maintain accountability.
Whether you build it or buy it, implementing last-touch-by-team logic is possible and highly recommended. It brings that single view of engagement that many revenue teams lack.
One more benefit: these fields are reportable and triggerable. If you want to report on the count of customers who haven’t had a CS call in the last month, how would you do it if you only had Last Activity Date and Owner/Team fields? You’re in for some manual work. By having this data explicitly, you create more automation opportunities.
Let’s bring this to life with a few concrete examples.
Let’s say your company owns two brands: Beet Brigade sells beets, Fancy Forklifts sells forklifts. (It’s weird, but go with me here). Both brands operate in a single HubSpot portal, and they both sell to the same customer: Dunder Mifflin (a mid-size paper company).
You’ve got two separate GTM teams:
Beet Brigade sells to Dwight
Fancy Forklifts sells to Daryl
(Michael is a wildcard who insists on talking to both teams)
Everyone's working the same company record. The same contacts. The same cluttered timeline. So when someone asks, “Hey, who last talked to Dunder Mifflin?” you get guesses. Shoulder shrugs. Conflicting answers. No one knows whether Beet Brigade is mid-deal or if Fancy Forklifts already closed.
Let’s say you’re looking at the Dunder Mifflin company record. Who last talked to them? What were they trying to sell? Unless you want to dig into the record timeline, Default HubSpot gives you nothing. No team-based attribution, no audit trail, just vague "last activity" dates tied to whichever user logged the last call or email, or even note.
With Sly Orange every Contact, Company, and Deal record in HubSpot auto-updates with:
Last Activity User: Name of the rep who engaged
Last Activity Team: Which brand/team they’re on
Last Activity Type: Email, call, or meeting
Last Activity Timestamp (HubSpot default property): When it happened
If you had installed Sly Orange, and a Forklifts AE emails Daryl yesterday, the Dunder Mifflin company shows:
Last Activity User: Jamie Lee
Last Activity Team: Fancy Forklifts
Last Activity Type: Email
Last Activity Timestamp: Aug 22, 2025 2:46PM
Now you know exactly who touched the record last and on which team. Even better, as a sly operator, you used a workflow and copied that data onto a new field called “Last Touch - Fancy Forklift Team,” so Dunder Mifflin now has the data:
Last Touch - Fancy Forklift Team: Aug 22, 2025 2:46PM
Now saw your Beet Brigade hops on a call with Dwight today, those fields flip to:
Last Activity User: Shruti Sharma
Last Activity Team: Beet Brigade
Last Activity Type: Call
Last Activity Timestamp: Aug 23, 2025 10:15AM
And again, you used a workflow and copied that data onto a new field called “Last Touch - Beet Brigade Team Team,” so now you know exactly which team talked to Dunder Mifflin when:
Last Touch - Beet Brigade Team: Aug 23, 2025 10:15AM
Last Touch - Fancy Forklift Team: Aug 22, 2025 2:46PM
So now when leadership asks, “Who’s working Dunder Mifflin right now?” you’re not fumbling through the activity feed. You’re looking at a clean answer, stamped right on the record.
Let’s move into the world of The Office, who is trying to expand a customer account: Acme Corp.
The Office team is working them:
Andy (AE) is working the expansion
Kelly (CSM) already manages Acme as a customer
So you’ve got two different motions running in parallel: Sales chasing a new deal, CS keeping the renewal warm. And it’s all happening in one HubSpot company record.
Without Sly Orange, you’re blind. The last activity date flips depending on whichever user logged a call, but it tells you nothing about which team owns the touch. Sales can step on CS. CS can step on Sales. Everyone looks like Michael: lovable but kind of a mess.
Now every touch at Acme is stamped with:
Last Activity User (who)
Last Activity Team (sales vs. CS)
Last Activity Type (call, email, meeting)
Last Activity Timestamp (when)
Yesterday, Kelly had a renewal check-in call:
Last Activity User: Kelly
Last Activity Team: Customer Success
Last Activity Type: Call
Last Activity Timestamp: Aug 22, 2025
Today, Andy makes a pitch call for the upsell. The fields instantly update to:
Last Activity User: Andy
Last Activity Team: Sales
Last Activity Type: Call
Last Activity Timestamp: Aug 23, 2025
Now, if leadership asks, “Who’s handling Acme right now?”, you’ve got a clear answer: Sales touched them last. If you set up workflows to stamp last activity date per team, you can even say: CS was active yesterday.
To keep things tight, you set a workflow:
Trigger: If Sales logs an activity on a CS-owned account
Action: Slack alerts the CSM
Owner: RevOps maintains the workflow
Measure: No touches go uncoordinated
So when Andy calls Acme, Kelly gets pinged:
“Heads up @Kelly, @Andy just reached out to Acme. You talked to them yesterday, sync up before the next step.”
Instead of surprises, you’ve got closed-loop handoffs.
On your HubSpot dashboard, you drop in a widget: Latest Customer Touch by Team.
If Acme’s last five touches are all Sales, maybe CS is out of the loop
If it’s all CS, maybe Sales dropped the ball on expansion.
Either way, you now have facts, not hunches.
These scenarios highlight why all this setup matters. We’re not adding fields and workflows for fun (although if you’re a nerd like me, it’s kind of fun). It’s to answer these exact questions in real life. When it’s 5pm and someone urgently asks, “Has anyone spoken to [Client] this month?” or “Hey, why did that customer churn without us noticing?”, you’ll have facts: maybe no one on CS talked to them in 90 days and it fell through cracks, which your new system will prevent with alerts and reports. Or maybe multiple sales team bombarded them with different messages, which you could avoid using guardrails around each team’s last engagement data.
sThe only “Michael Scott” moments should be on TV, not in your customer handoffs.
Ownership clarity should also be reflected in your reports and alerts. This is the final piece: ensuring that if something slips, someone knows, and continuously shining a light on the handoff points so they stay healthy. Here are practical ways to leverage the data we’ve assembled:
Build a HubSpot dashboard focused on handoffs and follow-up. For example, include:
Report: “Conversion by BDR” – shows how many leads each BDR passed to AEs and how many became deals/opps, using the Original BDR owner field and deal stages. This keeps BDRs accountable and gives them recognition for sourced pipeline.
Report: “Untouched New SQLs” – list of deals in stage = SQL (or contacts Lifecycle = SQL) with no activity by the sales team in X days. Filter by Last Contacted > X days ago. This surfaces any dropped balls in the BDR→AE transition. Sales managers should review this daily/weekly.
Report: “Onboarding Speed” – a simple bar or KPI: median days from Closed Won to first meeting date by the CS team (you’d need to capture first CS meeting date either via a field or using the first CS activity on timeline as proxy). If it starts slipping beyond your target (say average is 5 days and your goal is 2 days), that’s a flag to investigate. You can break it down by CSM to see if someone’s overloaded or by segment to see if enterprise clients take longer, etc.
Report: “Last Touch by Team – Customers” – could be a chart showing % of customers whose last engagement was by Sales vs by CS in the last 30 days. Ideally for active customers, CS should dominate touches. If you see a big chunk of customers only being touched by Sales (or not touched at all), that could indicate CS isn’t engaging enough or Sales is doing reactive outreach (which might be fine, but it’s something to note).
Report: “Stale Accounts by Owner” – a table of CSMs (or AEs for prospects) with count of their accounts that haven’t been touched in over N days. This uses Last Activity Date or your custom Last Touch Timestamp. It basically produces an “exceptions list” to go work on. No CSM wants to be on top of the “accounts with no recent contact” list, it creates natural accountability.
Report: “Multi-Team Touches” – could be something like a list of contacts that had engagements from more than one team in the last 14 days. This might indicate active collaboration (good) or potential overlap (needs coordination). This one’s more advanced. If using SlyOrange, one trick is you can compare Last Activity Team vs an “Account Owner Team”: if they differ, that means the last touch was by a team other than the owning team. That can feed a report or list.
Not everything should wait for someone to check a dashboard. Set up a few key alertsBuild a HubSpot dashboard focused on handoffs and follow-up. For example, include:
New SQL Alert: When a BDR creates a new SQL/Deal and assigns an AE, ping the AE immediately (HubSpot can send internal email or use Slack integration). This ensures the AE doesn’t discover a deal sitting in their name hours later by chance. Don’t forget to capture the first outreach by the AE, so you can measure the time from assignment to outreach!
No Follow-up Alert: If 24 business hours pass after an SQL was assigned and the AE hasn’t made contact (no new activity by AE on that record), alert the AE and CC their manager. This is a bit strict, so calibrate to your SLA, but it automates sales management 101: speed to lead.
Closed Won Alert: This is great to do regardless of anything we’ve talked about. Always celebrate your wins! Then, notify the assigned CSM and maybe the CSM team channel the moment a deal is Closed Won and they’re assigned. Include deal info. This often happens via built-in workflow or the Deals settings “Assign Company Owner = deal owner on Close Won” (though if you assign CSM via workflow, that handles it).
Overdue Onboarding Alert: If, say, 7 days after Closed Won, the CSM still hasn’t completed the kickoff (no meeting held, or your “Onboarding Task” is still open), trigger an alert to the CS team lead: “Customer X has no recorded onboarding activity 3 days post-sale.” Early warning to intervene.
Account Inactivity Alert (CSM): Could be monthly: each CSM gets an email listing their customers with no engagement in >60 days (or whatever threshold). This prompts proactive outreach. It’s essentially an automated nudge to not neglect any accounts.
Expiring Trials/Renewals Alert: If relevant, e.g., AE gets alert 90 days before a contract renewal if they are involved, or a task for AM to reach out. Ownership shifts can happen at renewal (sometimes AEs re-enter for upsell/renewal in some models), so define whose job that is and automate the reminder.
Use HubSpot Playbooks (if you have Sales Hub Enterprise) for handoff checklists.
For example, create a Playbook template for “BDR → AE Handoff” with fields like “BDR Qualifying Notes, Key Pain, Next Steps agreed”. BDR fills it out and pins to contact. AE can refer to it easily.
Similarly, an “AE → CS Handoff” playbook ensures sales provides the info CS needs (like what’s been promised, custom terms, personalities encountered, etc.).
While this is more qualitative, it ensures nothing falls through cracks in the content of the handoff, not just the mechanics. The existence of a completed Playbook entry can even be a criterion in your process (e.g., a deal can’t be marked Closed Won until AE fills the handoff playbook – you might not enforce via software, but sales leadership can enforce culturally).
This isn’t a system report, but it’s worth mentioning. Encourage a short weekly sync between BDR manager & Sales manager (for lead handoffs) and between Sales & CS managers (for new customer handoffs). They can review any anomalies: “We handed 50 leads to sales last week, 2 still haven’t been touched, let’s address that.” Or “We closed 10 deals last month; CS reports 1 of them hasn’t engaged with onboarding yet. What’s going on?” Use the data from your HubSpot dashboards to drive these meetings. They should get shorter and happier over time as your system matures (initially you might have a laundry list of issues; over time just a quick check-in).
One more thing on visibility: share some of this data with execs in a digestible way. Don’t puke up all the raw data. A VP of Sales or CRO will love a simple metric like “% of new leads followed up within SLA” or “Customer Onboarding CS touch rate”. It shows that the revenue engine is humming. Conversely, if it’s not, it flags that RevOps is on top of it and working with teams to fix it.
The end goal is no surprises, internally or for customerscan review any anomalies: “We handed 50 leads to sales last week, 2 still haven’t been touched, let’s address that.” Or “We closed 10 deals last month; CS reports 1 of them hasn’t engaged with onboarding yet. What’s going on?” Use the data from your HubSpot dashboards to drive these meetings. They should get shorter and happier over time as your system matures (initially you might have a laundry list of issues; over time just a quick check-in).
We’ve gone deep, so here’s a final rundown of how to mind the handoff and nail cross-team ownership in HubSpot, step by step:
1. Lock down ownership at every stage
Map BDR, AE, and CSM/AM to specific lifecycle stages. Write it down in one line per stage: “At Stage X, [Role] owns the record.” No overlap, no guessing.
2. Keep a permanent record of who touched it
Don’t let HubSpot’s single owner field erase history. Create custom fields like Original BDR, AE Owner, CSM Owner. Add Last Activity User, Team, Type, Date so anyone can see who actually engaged last.
3. Automate the baton pass
Workflows should do the heavy lifting:
Trigger: Meeting booked, deal created, or stage changed
Action: Assign owner, create task, notify the next rep
Owner: Make the new role accountable on the spot
Measure: Enforce SLAs (e.g. AE touches new SQL within 24 hours, CS meets new customer within 7 days)
4. Centralize every engagement
No blind spots. Hook up Outreach, Gong, Aircall, Zoom so calls, emails, and meetings all hit the HubSpot timeline. If it’s not in HubSpot, it didn’t happen.
5. Make last touch tracking actually useful
Knowing who last engaged and from which team changes everything. Build reports like “Accounts with no CS touch in 60+ days” or “Deals last touched by Sales >14 days ago.” That visibility kills shrug-fests.
6. Add guardrails and alerts
Don’t wait for quarterly reviews to find gaps. Alerts should fire when:
- A new SQL sits untouched past SLA
- A Closed-Won customer hasn’t heard from CS in a week
- Sales touches a CS-owned account without looping them in
7. Standardize the handoff package
Mechanics aren’t enough. The substance has to transfer. Use Playbooks or required fields for BDR notes, AE commitments, and CS onboarding details. Customers should never have to repeat themselves because your team dropped the memo.
8. Measure, review, and tune
Track handoff conversion rates, follow-up times, and account engagement cadences. Run quick weekly reviews between team leads. Treat this like pipeline hygiene: inspect, fix, repeat.
9. Lean on tools when it’s worth it
If maintaining all this manually becomes overhead, use a tool like SlyOrange. It stamps last-touch fields automatically, backfills history, and keeps reporting honest.
Above all, drive the culture of accountability. Technology and processes support it, but the teams have to embrace it. Make clear that every lead has a captain, every customer has a concierge. When a handoff happens, the previous owner doesn’t disappear either; have them do a warm intro or at least stay informed until the new owner fully takes over. Marketing, Sales, CS all carry the revenue baton at different times, but winning the race requires smooth passes.
By implementing this RevOps playbook in HubSpot, you’ll go from chaos to clarity. No more leads left in purgatory because “I thought so-and-so was handling it.” No more customer emails going unanswered because the rep left and nobody re-assigned the account. Instead, you get a well-oiled machine: BDRs to AEs to CSMs operating in concert, with HubSpot as the source of truth coordinating the moves. Clear ownership, transparent activity, and timely handoffs are non-negotiable in a high-performing revenue engine.
Mind the handoff, and you’ll find your teams stop tripping over each other and start scoring those revenue goals together. If you need help doing this or want to vent about why this can’t just work out of the box, we’re here for you.