MegatronLead

How-to

SLA policy template for enterprise sales operations

A concrete SLA policy template you can adapt: targets per (market, source, state), escalation thresholds, business calendar handling, calibration process.

ByFounder, MegatronLead7 min read

Builds operational software for multi-market sales organizations. Twenty years across enterprise IT, M365, and revenue operations.

How-to

SLA policy template for enterprise sales operations

An SLA policy is a contract between operations and the field. Operations sets targets the field can meet; the field meets them; leadership reviews whether the targets are still appropriate.

Without a documented policy, the contract is informal. Some teams meet aggressive targets without anyone noticing; others miss loose targets without consequence. The discipline of documenting and calibrating fixes both.

Here is the template.

Component 1: targets per (market, source, state)

The target is a time window. It is set per tuple of market, source, and current state. A single global SLA is wrong because the dimensions vary too much.

Default targets for a typical B2B SaaS, by transition:

TransitionPaid socialInbound webCold listPartner referral
NEW to CONTACTED1 hour2 hours24 hours4 hours
CONTACTED to QUALIFIED/UNQUAL24 hours24 hours5 business days24 hours
QUALIFIED to PROPOSAL5 business days5 business days10 business days5 business days
PROPOSAL to NEGOTIATION/LOST10 business days10 business days20 business days10 business days

Adjust by market based on business hours, team capacity, and customer expectations. Markets with smaller teams may have looser targets; markets with faster competitive dynamics may have tighter ones.

Component 2: escalation thresholds

For each target window, three escalation thresholds:

  • At 80% of the window elapsed: notify the lead owner. Channel: their primary work channel (Slack DM, Teams, or email). Content: a contextual notification with the lead, the time elapsed, time remaining, and a deep link.
  • At 100% of the window: breach. Notify the owner's manager. Record the breach in the audit log.
  • At 150% of the window: auto-reassign to another available rep on the team. Audit the reassignment.

The percentages are stable across SLAs. The window varies per (market, source, state).

Component 3: business-calendar handling

Each market has a configured business calendar:

  • Business hours. Typical 9 AM to 6 PM local time. Some markets vary.
  • Working week. Monday-Friday in most markets. Sunday-Thursday in Saudi Arabia and some other GCC. Friday-Saturday weekend.
  • Public holidays. Per-market list. Updated annually.

SLA timers pause outside business hours. A lead arriving at 7 PM local time pauses until 9 AM the next business day. A lead arriving on a public holiday pauses until the next business day.

Without this, SLA timers fire breaches overnight that no one can respond to. The team learns to ignore breach notifications; the SLA loses meaning.

Component 4: calibration cycle

Quarterly, review the SLA performance:

  1. Pull breach data for the quarter. Total breaches per (market, source, state). Breach rate as percentage of leads in the tuple.
  2. Pull p90 response time. The 90th-percentile actual response time per tuple.
  3. Compare target to p90. Is the target tighter than p90 (most breaches) or looser (few breaches, target is theater)?
  4. Adjust. Tighten targets where the team consistently beats them. Loosen targets where the team consistently misses them and the cause is capacity rather than discipline.

The calibration meeting is 60-90 minutes per quarter. Decisions get documented.

Pausing for ON_HOLD

A lead in ON_HOLD state has its SLA timer paused. The state is used when:

  • The prospect requested follow-up at a specific later time.
  • The prospect is on vacation.
  • An external event blocks progress (a procurement freeze, a budget cycle).

ON_HOLD requires a documented reason and an unpause date. The platform unpauses automatically on the date.

This prevents the team from gaming the SLA by marking everything ON_HOLD. The reason and date make the use auditable.

Reporting

The policy is operationalized through reporting:

Daily operational view (for ops admins):

  • Breaches today, this week, this month.
  • Owners with the most breaches.
  • Sources with the most breaches.

Weekly team view (for team leads):

  • Breach trend over time.
  • Average response time per rep.
  • Coaching opportunities.

Monthly leadership view (for CRO and regional VPs):

  • Breach rate by market.
  • Trend over time.
  • Correlation with conversion outcomes.

The reports come from the same canonical lead store. Operations and leadership see consistent numbers.

Common mistakes

Three to avoid:

Setting targets without measuring baseline. Pick a number from a benchmark report, the team treats it as theater. Always baseline first; set targets based on what the team can plausibly achieve.

Ignoring business calendar. SLAs that fire overnight breaches produce noise. Configure calendars per market.

Reviewing weekly without quarterly calibration. Weekly reviews catch individual breaches; quarterly calibration adjusts the policy. Both are needed.

Documentation

The SLA policy should be documented in three places:

  1. In the platform. Configuration of targets, thresholds, calendars.
  2. In a written policy document. What the policy is, why it is set this way, who calibrates and when.
  3. In rep onboarding materials. How the SLA affects the rep's work, what notifications mean, what auto-reassignment does.

The first is operational; the second is institutional; the third is cultural.

For how MegatronLead expresses SLA targets, business calendars, and escalation thresholds, see SLA and escalation.

Related reading

More in this category

Operationalize your lead pipeline.

Talk to us about how MegatronLead handles your specific markets, sources, and audit requirements.