How to Design Handoff SLAs That Sales and Marketing Will Actually Follow

TL;DR: Most handoff SLAs collapse within 90 days because they're written as policy documents, not system logic. If your CRM can't detect a violation automatically, your SLA is a suggestion. Here's how to build enforcement in from day one, with specific mechanisms for HubSpot and Salesforce.

---

Handoff SLAs are one of those things that feel solved the moment you introduce them. You get sales and marketing in a room, everyone agrees that MQLs should be contacted within 24 hours, someone writes it in a Notion doc, and for about six weeks the numbers look better. Then they don't.

I've seen this cycle play out at company after company. By the time a founder or CRO calls us in, the SLA document is still there. The behavior isn't.

The instinct is to blame attitude. Marketing thinks sales ignores leads. Sales thinks marketing sends garbage. Both are sometimes right. But attitude isn't what kills SLAs in the first ninety days. Design does.

The Real Reason SLAs Fail

Here's the thing: if your SLA only exists in a shared doc, a slide deck from a QBR, or a weekly report someone emails around, you haven't built a system. You've written a preference.

Systems enforce themselves. Preferences require memory, motivation, and managerial follow-through. All three decay under quota pressure.

The operators I work with consistently describe the same failure pattern. The SLA gets introduced with good intentions. For the first few weeks, the revenue leader or head of demand gen manually checks compliance and flags stragglers. Then a big deal closes, a board meeting lands, a rep goes on leave, and the manual checking stops. Within ninety days, the SLA exists on paper and nowhere else.

The fix isn't a better Notion doc or a more emphatic all-hands about pipeline hygiene. The fix is building the SLA into the CRM so that violations are visible automatically, without anyone having to look for them.

If your CRM can't detect a violation and surface it to the right person without a human triggering that process, your SLA is a suggestion. That's not a mindset problem. That's an architecture problem.

Start With What the CRM Can Actually See

Before you write a single SLA clause, you need to know what your CRM can measure natively. This sounds obvious. It almost never happens in practice.

Most SLA documents are written in a business meeting by people who understand the commercial intent but don't know the CRM's data model. The result is SLAs that reference concepts the system can't track. "Sales should respond meaningfully within four business hours" is a great example. What's a meaningful response? How does HubSpot or Salesforce know whether a logged activity counts? It doesn't. Not without significant custom configuration.

Start with this question: what timestamp fields or status changes does the CRM already record at each stage of the handoff?

For a marketing-to-sales handoff, that usually means:

• The moment a lead hits MQL status (a lifecycle stage change or a field update)
• The moment a contact is assigned to a rep (owner field change)
• The moment the first outreach activity is logged (a task completed, an email sent, a call logged)
• The moment the lead is converted, disqualified, or moved to a pipeline stage

For a sales-to-CS handoff, it means:

• The moment a deal reaches Closed Won
• The moment a CS owner is assigned to the account
• The moment the customer first receives an onboarding touchpoint (email sent, meeting booked, task completed)

Work backwards from those timestamps. Build SLAs around them. If you can't draw a straight line from your SLA clause to a timestamp in the CRM, the clause is unenforceable by definition.

Designing the Enforcement Logic

Once you know what the CRM can see, enforcement logic becomes straightforward. The principle is simple: every SLA has three components.

1. The trigger. What event starts the clock? This must be a specific field change, status update, or object creation in the CRM. Not an email. Not a Slack message. A CRM event.

2. The measurement window. How long does the receiving team have? This needs to account for business hours, time zones, and weekends if those matter to your motion. A 24-hour SLA for an enterprise team that operates 9-5 EST is different from a 24-hour SLA for a PLG team with global coverage.

3. The escalation. What happens automatically when the window expires? This is the piece almost everyone skips. Without automated escalation, you're back to manual checking.

Let me walk through how to implement this in both HubSpot and Salesforce, because the mechanisms are different enough to matter.

HubSpot: Where to Build the Logic

HubSpot's enforcement toolkit is primarily built on workflows, deal properties, and task automation. Here's a practical structure.

Tracking the MQL-to-contact SLA:

Create a custom contact property called something like "MQL Assigned At." Set a workflow to populate this timestamp the moment the lifecycle stage changes to MQL and an owner is assigned. Then create a second workflow that fires 24 hours (or whatever your window is) after that timestamp and checks whether a "First Outreach Logged" property has been populated. If it hasn't, the workflow should do two things: create a task assigned to the rep's manager flagged as high priority, and update a custom property called "SLA Status" to "Breached."

That "SLA Status" property is critical. It makes violations visible in list views, deal boards, and reports without anyone having to calculate anything.

Tracking the Closed Won-to-CS handoff SLA:

Set a workflow trigger on deal stage moving to Closed Won. Populate a "CS Handoff Due By" date property on the associated company or contact record. Then use a branch in the same workflow (or a second enrollment) to check 48 hours later whether a CS owner has been assigned and whether an onboarding task has been created. If not, auto-create a task for the CS team lead and flip the SLA Status field.

Reporting:

Build a saved contact view filtered to SLA Status = Breached. Make that view the default landing page for the sales manager in HubSpot. It should be the first thing they see. Not a report they have to navigate to. The default view.

One honest caveat: HubSpot's workflow branching on time delays works well for simple windows. If you need to calculate business-hours-only windows, you're going to need either a workaround using calculated properties or an integration with a tool like Zapier or Make. HubSpot doesn't handle business hours natively in most plans.

Salesforce: Where to Build the Logic

Salesforce gives you more flexibility and more rope to hang yourself with. For most Series A-C companies I work with, the right combination is Process Builder (or Flow in newer orgs), custom fields, and either a native reporting dashboard or a lightweight managed package.

Tracking the MQL-to-contact SLA:

Create a custom DateTime field on the Lead object: "MQL Qualified Time." Populate it via Flow when the Lead Status changes to MQL. Create a second custom field: "First Activity Logged Time." Populate this via a Flow that fires when a task associated with that lead is marked complete within a relevant task type (call, email). Then build a report formula field that calculates the difference in hours between those two timestamps. Anything above your threshold surfaces in your SLA compliance report.

For escalation, use Flow to check that delta on a scheduled basis (every hour during business hours is reasonable). When it crosses the threshold without an activity logged, create a follow-up task assigned to the rep's manager and update a picklist field on the Lead: "SLA Status" with values like In Window, At Risk, Breached.

Tracking the Closed Won-to-CS handoff:

The logic mirrors HubSpot's but uses Opportunity and Account objects. When Opportunity Stage = Closed Won, a Flow creates a record in a custom object (or populates fields on the Account) with the expected CS assignment date. A scheduled Flow checks 24 or 48 hours later. No CS owner assigned? Auto-create a case or task for the CS leadership queue and update the SLA Status field on the Account.

Reporting:

Build a Salesforce dashboard with two widgets front and center: current SLA breach count by rep and by team, and a trend line of SLA compliance over the past 30 days. Embed this dashboard in the weekly revenue meeting deck. Not as an afterthought. As the first slide.

The reason this matters: SLA compliance becomes a metric that leaders are accountable for in front of each other. That social accountability, backed by clean data, does more for behavior change than any policy memo.

The Conversation That Has to Happen First

None of this configuration matters if the thresholds themselves are wrong.

Most SLA windows are picked based on gut feel or what sounds reasonable in a meeting. Before you touch the CRM, do this exercise: pull your historical data and look at the deals that closed in the last two quarters. What was the average time from MQL to first contact for deals that converted, versus deals that didn't? What was the average time from Closed Won to onboarding kickoff for customers who hit their 90-day health targets, versus the ones who churned?

This doesn't take a data scientist. It takes a pivot table and an hour. But the answer will tell you whether your proposed SLA window is grounded in reality or aspirational theater.

At VEN Studio, we almost always do this analysis before writing a single SLA clause. The numbers either validate the proposed window or they surface a gap between what teams believe is happening and what's actually in the data. Either outcome is useful.

When SLAs Break Down Anyway

Even well-designed SLAs break under certain conditions. Know the common ones.

High inbound volume spikes. A well-timed campaign can flood a sales team and make SLA compliance temporarily impossible. Build a volume alert into your workflow: if more than a defined number of MQLs are assigned to a single rep in a 24-hour window, flag that for the manager rather than creating a breach notification. The breach isn't the rep's fault. The capacity model is the problem.

Ownership gaps. SLA violations often happen not because reps are slow but because the lead was never cleanly assigned. A lead with no owner can't trigger an SLA clock. Build validation into your lead routing before you build SLA tracking. Unowned leads should never sit quietly in the system.

CS handoff without a named CS rep. In fast-growth environments, a deal closes before a CS rep is hired or assigned. The SLA clock runs, the violation fires, and everyone knows why. The answer isn't to pause the SLA. It's to have a CS leadership queue that acts as the fallback owner. The queue owns the SLA until a rep is assigned.

What Good Looks Like

An SLA that works at 90 days looks exactly like it did at day seven. Not because the team has extraordinary discipline but because the system doesn't give them the option to quietly let things slide. Violations are visible. Escalations are automatic. The conversation in the revenue meeting is about trends, not about whether anyone followed up on a specific lead.

That's the goal. Not compliance theater. Actual measurement.

Build the enforcement logic first. Then write the policy to match what you've built. Most teams do it backwards and wonder why nothing sticks.

---

Frequently Asked Questions

What's a realistic SLA window for MQL-to-first-contact if we're an enterprise motion?

For most enterprise motions I work with, 24 business hours is the standard starting point. The honest caveat: if your leads require meaningful research before outreach, a 24-hour window may produce rushed, low-quality first touches. Consider breaking it into two SLAs. One for lead acceptance (the rep claims it and confirms it's worth pursuing) within four hours, and one for first outreach within 24 business hours. That way you're measuring two distinct behaviors, not collapsing them into one timestamp.

Our CRM data is messy. Should we fix the data first or build the SLA enforcement first?

Fix the data first. SLA enforcement logic built on top of incomplete or inconsistent field data will produce false violations and false clean bills at the same rate. The team will stop trusting the report within weeks. The minimum bar: lead ownership assignment must be clean and consistent, and lifecycle stage changes must be reliable. Without those, you're building on sand.

How do we get buy-in from sales for SLA enforcement when there's already tension with marketing?

Don't frame it as accountability for sales. Frame it as protection for sales. An SLA that surfaces MQL quality issues (leads that get contacted within SLA but never convert) gives sales the data to push back on marketing. Good SLA design measures both sides. Marketing's SLA is lead quality and volume. Sales' SLA is speed and coverage. When both teams have visible metrics, the conversation shifts from blame to optimization.

What's the minimum viable version of this if we're pre-Series A and don't have a RevOps hire yet?

Two fields and one report. Add a "Lead Assigned At" timestamp and an "SLA Status" picklist to your lead object. Set one workflow or automation to populate both. Build one report that shows every lead where SLA Status is Breached and who owns it. Review it in every weekly sales meeting. Don't automate escalations yet. That comes later. But make the data visible now so you're not flying blind.

How often should SLA thresholds be reviewed?

Quarterly is the right cadence for most Series A-C companies. Your pipeline velocity changes as your ICP sharpens, your sales team grows, and your inbound volume shifts. An SLA designed for a five-person team with 200 MQLs a month needs to be revisited when you have 12 reps and 600 MQLs a month. The system should scale with the business. If it doesn't, you're optimizing for a version of the company that no longer exists.