The key to enabling dynamic growth in HubSpot is kind of the same key to managing it without a full ops team: build processes that scale. That means minimizing manual input, building standard segments for every contact and processes for every revenue employee to operate within, and utilizing shortcuts that prevent you from having to rebuild processes every time an employee leaves or is added.
HubSpot is full of these levers that enable scale. Workflows, Ops Hub, Snippets, etc, are all super useful for building processes that enable scale and speed.
My personal favorite is the HubSpot Teams function. In short, this is a field on every object in HubSpot that reflects the team or division the Owner of said object is on.
These teams are assigned by admins in the Users settings and generally represent divisions of the company, such as Sales, Marketing, Client Success, and Finance.
I tend to take it a step further to make it more useful, and divide revenue teams by more layers, such as region or industry. My Team setups usually look like this:
- AEs - West
- AEs - East
- AEs - EMEA
- AEs - APAC
- BDRs - NA
- BDRs - RoW
- CS - SMB
- CS - Enterprise
And so on. The point being, granularity is good, because it enables a lot more scale and makes the Team field way more useful. Below are my four favorite uses of this function, all of which prevent me from tedium and/or protect my portal's data.
Lead Rotation
If you have geographic territories for your reps, rotating leads among them is easy with the Teams functions. Especially for BDRs, where turnover is usually frequent.
With this in place, leads will be assigned randomly and equally among all members of that team. If someone from the team leaves the company, you can remove them from that team when you deactivate their account, and they'll be removed from the rotation. Conversely, adding a new member to the Team will automatically insert them into the rotation.
Funnel Position Establishment
If you've ever worked with me - or read some of my articles - you know most companies are unable to determine exactly who is a customer and who is not. The Team property doesn't solve that, exactly, but it can serve as a stopgap simply by showing which team is currently the owner of an object.
For example, if sales is the owner, the assumption is the object is not a customer. If the CS team owns it, the system can assume it's a customer. This is helpful in a number of ways, but especially for things like lead routing, where you want to route clients to CS, SQLs to AEs, and raw prospects to BDRs. Instead of a series of branches, you can rely on the prospect's associated account's Team, then send different notifications to the Owner based on that Team.
That way you don't send prospects to CS, and every inbound lead will reach its destination with an automated notification.
Chat and Ticket Routing
Lead and company routing isn't the only helpful function Team can help you assign. It works on incoming live chats and tickets. The way I like to set it up is based on a tiering system, where high tiers get routed to a high priority support team, and smaller clients (or those not paying for advanced support) get routed elsewhere.
HubSpot has some other functions available, such as routing tickets based on specialty or workload, so those may work for you. The Team routing function can act as a fallback option beyond these.
Permissions
In all reality, very few of you reading this have a need for strict marketing permissions. Either your team isn't large or segmented enough to merit it, or more likely, content creators aren't messing with each others content.
No, restricting permissions is all about two things:
- Security, keeping people out of critical data
- Sales and preventing cannibalization
For #1, you can place vendors, non-revenue employees, and others in teams that have restricted access. You can even restrict them from viewing certain objects and editing fields.
#2 depends on the nature of your sales team. If the nature of your sales team is respectful and they stick within their assigned geographic regions and disputes are settled civilly, you don't have to worry about this.
If it's not, and your sales team operates like wild west outlaws and constant cannibalization is a worry, then using teams to restrict access is going to be your new favorite feature.
Separate your sales teams into regions or pairs (for companies who pair up BDRs and AEs, for example) and use those teams to restrict the ability to view, edit or communicate to ONLY the owners. This won't solve all the issues (if your sales team still operates like this in 2024 and your sales leader is okay with it...well, good luck) but it will at least provide a speed bump to Carl the Commission Thief.
Make Teams Part of Your System
You can follow the team function pretty deeply, getting into sub-teams and content/property/process restrictions. I recommend it - Salesforce has had a function like this for years and it's a secret weapon for scaling. If you've ever had to decom a user, then re-wire all the workflows that assigned items to them or triggered Sequences from them, you probably know why the Team property is so valuable.
The main thing? Make it a standard function for every user in your system - add them when you create them, and remove them from teams when removing them.
Want to explore the Teams function in depth? Reach out and let's talk.
