Sales Hub Pro Rollout With Team Silos
Meridian Supply has 30 Sales Hub Professional users: 18 SMB reps, 8 Enterprise reps, and 4 managers. Everyone can see every deal, contact, and company. SMB reps have been cherry-picking inbound Enterprise leads because Enterprise deals carry larger amounts, and Enterprise reps complain that their accounts are being touched. Deal assignment happens in a shared spreadsheet, and two coordinators manually create deals each morning. Meeting links point to a generic company calendar, so prospects often meet the wrong rep. There are six pipelines, but only two are used; the other four were created for experiments and contain 140 stale deals. Managers cannot report on team-specific activity because ownership is inconsistent. The VP wants stricter visibility, automatic routing, and no new headcount. The company is willing to buy Sales Hub Enterprise only if the business case is clear. What should the admin configure first, and what should wait for Enterprise?
1. Design the team and permission structure in Sales Hub Professional. What can be solved with teams, ownership, and sharing settings, and what cannot?
Read the worked answer
Configure teams first: SMB, Enterprise, and Sales Management, with managers assigned to the appropriate team. Set object access so reps see records owned by their team, managers see their team plus roll-up, and admins see everything. This solves cherry-picking visibility for contacts, companies, and deals only if ownership is accurate and sharing settings are applied consistently. It does not solve routing, meeting-link assignment, or stale pipelines. Those are process and automation problems. Do not promise record-level partitioning of specific named accounts; that typically requires more advanced permissions or a separate process. Also consolidate the six pipelines to two active pipelines plus an archived experiment pipeline, and move the 140 stale deals to Closed Lost or a cleanup stage with a reason. Start with teams and ownership because routing depends on a clean team structure.
2. How would you route inbound leads and meeting bookings to end cherry-picking without adding headcount? Include rules for SMB vs Enterprise and exception handling.
Read the worked answer
Define routing rules before configuring tools: Enterprise if employee count exceeds a threshold, or the company is on a named-account list; otherwise SMB. Route by territory or segment, then round robin within the eligible team. Use team-specific meeting links so a prospect booking from an Enterprise page reaches an Enterprise rep; include a fallback owner or queue for no-shows and unassigned leads. Reassigning a lead should require a reason and notify the original owner. For manual deal creation, replace the spreadsheet with a form or workflow that captures segment, owner, and source. Set a response SLA, such as first touch within one business hour, and report on SLA adherence by team. Exception handling matters: strategic accounts, existing customers, and partner referrals should bypass the round robin and go to a named owner.
3. Build the business case for Enterprise. Which problems require Enterprise, and which are process problems that should not be used to justify the upgrade?
Read the worked answer
Build the Enterprise case only around capabilities Professional cannot reasonably provide, such as advanced object-level permissions or custom objects if those are genuinely required. The cherry-picking, inconsistent ownership, generic meeting links, and stale pipelines are process problems; buying Enterprise without fixing them would reproduce the same mess at a higher price. Quantify the cost of the current state: hours spent on manual deal creation, missed Enterprise response SLAs, and deals touched by the wrong rep. Then list which of those the proposed Enterprise features would actually change, and what process changes are still required. If the main need is team visibility and routing, Professional plus disciplined ownership may be enough. Present a phased decision: fix process first, measure for 60 days, then upgrade only if a named capability remains the blocker.