Beyond ITSM: Using SLAs to Control Work in Sales, Legal, and Ops

[#1]

Beyond ITSM: Using SLAs to Control Work in Sales, Legal, and Ops

Sales, Legal, and Operations teams are the engines of any modern business. When they run smoothly, deals close, compliance is maintained, and employees are set up for success. But what happens when the engine stalls?

Imagine a high-value inbound lead sitting untouched for 24 hours while a competitor snaps them up. Picture a critical contract review stuck in a lawyer's Jira inbox for two weeks with no visibility into its status. Or consider a new hire waiting days for their equipment because the internal Operations team handoff failed.

These failures–the lost deal, the missed deadline, the internal friction—all boil down to one common problem: a lack of clear, measurable, and time-bound expectations.

The truth is simple: once work is inside Jira, SLAs become a universal mechanism for visibility, predictability, and timely action across departments.

In this article, we explore how Sales, Legal, and Ops teams can use SLAs to structure their workflows – and how tools like Jira and SLA Time and Report for Jira can support these cross-department processes in a practical, non-ITSM way.

What SLAs Really Are: A Business Perspective

In simple business terms, an Service Level Agreement (SLA) is a formal commitment that defines the level of service a provider (whether IT, Legal, or Sales) promises to a customer (internal or external).

The power of an SLA lies in its focus on time. It answers two critical questions:

1. Time to Respond: How quickly must we acknowledge the request?
2. Time to Resolve: How quickly must we complete the work or reach the next milestone?

By defining these expectations, SLAs introduce predictability and fairness. Everyone—the requestor, the assignee, and the manager—knows precisely what "on time" means and what constitutes a failure (a breach).

While the main SLA is customer-facing, you will often need supporting agreements:

• Operational Level Agreements (OLAs): Agreements between internal support teams (e.g., Legal promises a response to Sales within 48 hours).
• Internal Key Performance Indicators (KPIs): Metrics used to monitor the efficiency of individual contributors or processes (e.g., "Average time in 'Pending Approval' status").

In Jira, the SLA is the master timer, and the OLAs and KPIs are the process metrics you track to ensure the main SLA is met.

Why Non-IT Teams Need SLAs Too

The pain points experienced by Sales, Legal, and Operations are structurally identical to the problems IT support faces: they are time-bound tasks where delays cause business risk.

Pain Points in Sales 🛒

If inbound leads are manually routed or tracked in spreadsheets, the process lacks accountability. A "hot" lead can go cold in hours. When there is no measurable First Response Time SLA, the sales funnel becomes leaky, and deals are lost due to follow-up failure, not lack of interest.

Pain Points in Legal ⚖️

Legal work is often seen as a black box. Internal teams submit contract review requests and have zero visibility. Without an SLA defining Time to Deliver Redlined Version, critical business cycles slow down, and project deadlines are missed, causing widespread frustration.

Pain Points in Ops ⚙️

Operations (shared services like HR and Procurement) frequently involves handoffs between multiple internal teams. Without SLAs defining milestones like Time for IT Setup or Time for Procurement Approval, requests stall, leading to internal friction, lack of accountability, and significant process bottlenecks.

Designing SLAs in Jira for Sales, Legal, and Ops

SLAs don’t need to be complicated. The key is mapping each department’s real-world workflow into events Jira can track.

Below are three practical examples.

Sales: Disciplining the Funnel

In sales, speed is profit. Tracking response time outside of a formal SLA system is an enormous risk.

Problem: An inbound lead ticket is assigned but the representative is tied up, delaying the initial contact. The lead moves on to a competitor who responded quicker.

Example SLAs:

• First Response to a New Lead: <2 hours in working calendar (M-F, 9-5).
• Time to Send First Proposal: <3 working days.

Jira Implementation:

You could use a Jira Business Project or a Jira Service Management (JSM) Request Type customized for lead tracking.

The First Response SLA should start on issue Created and stop on First internal comment (indicating the rep reached out).

The Proposal SLA could start when the issue transitions to Status: Qualified and stop on Status: Proposal Drafted. Using Jira’s calendars ensures that the clock only ticks during defined business hours.

Legal: Time-Bounding Compliance and Review 

Legal work needs clarity to prevent it from becoming a bottleneck.

Problem: A high-priority client contract review sits unassigned in the Legal team's queue for a week because the intake process is unclear.

Example SLAs:

• Time to Acknowledge: <4 hours.
• Time to Deliver First Redlined Version (Standard): <3 working days.
• Time to Approve (Low-Risk/Express): <1 working day.

Jira Implementation:

Utilize a JSM Legal Service Management project or a customized Jira Business Project for routing.

The SLA starts when the request hits Status: Ready for Legal Review. It stops when the issue transitions to Status: Redlined Sent.

Priority and Workflow: Different SLAs are set based on the issue priority or a custom field (e.g., "Contract Risk Level: Low, Medium, High"), ensuring low-risk, high-volume approvals are routed via an express workflow with a tighter SLA goal.

Operations: Accountability in Shared Services 

Operations often manages complex internal processes involving multiple departmental handoffs (OLAs).

Problem: The onboarding process stalls because the request for the laptop is approved by the manager but sits for days with the Procurement team.

Example SLAs:

• Time to Approve Purchase Requests: <2 working days.
• Time to Complete IT Setup (Onboarding OLA): <48 hours after approval.
• Time to Unblock Production Incident (Ops side only): <30 minutes.

Jira Implementation:

This is where multi-step workflows are key. An SLA can be configured to start and stop based on assignment changes or specific custom field updates, such as "IT Status: Hardware Ordered."

This provides visibility into exactly which team is accountable for the work at any given moment, transforming bottlenecks into measurable metrics.

How to Configure These SLAs Technically in Jira

At a high level, configuring an SLA in Jira requires these steps:

1. Identify Request Types and Priorities: Map your business needs (e.g., "Hot Lead," "Standard Contract," "Urgent Purchase") to Jira issue types and priority levels.
2. Define Working Calendars and Business Hours: This is crucial for fairness. Configure calendars to exclude weekends, holidays, and non-working hours so the SLA clock only ticks when the team is available to work.
3. Map SLA Goals and Events: This is where you define the precise mechanics of the timer:

Start Conditions: Define when the clock begins (e.g., Issue Created, Status change to Ready for Review).

Stop Conditions (Success/Pause): Define when the clock stops because the goal is met (e.g., Status change to Resolved), or when it pauses (e.g., Status change to Waiting for Customer or when a specific field, like "Contract Review Date," is populated).

Goals: Set the specific time limit (e.g., 2 hours, 3 days) for each combination of request type and priority.

SLA Reset: Crucially, define conditions under which the SLA timer should reset. For example, if a resolved ticket is re-opened by the customer (e.g., a contract needs a second review), the SLA timer must restart to enforce discipline on the follow-up work (multi-cycle tracking).

Automated Actions & Notifications: This addresses the need for proactive management. Configure pre-breach notifications (e.g., send an email/Slack alert to the manager when the SLA is 80% consumed) and set up automated actions that trigger upon breach (e.g., auto-escalating the priority or assigning the ticket to a supervisor).

Limitations of Standard Jira/JSM SLAs

While native Jira Service Management (JSM) offers robust SLA tracking, it is fundamentally designed for service projects. You will quickly encounter limitations when trying to apply this discipline across the entire organization:

• Non-Service Projects: Native JSM SLAs do not work in standard Jira Software, Jira Work Management (Business), or custom projects, which is where many Sales, Legal, and Ops teams manage their work.
• Complex Reporting: Generating aggregated reports across multiple service projects, or creating management dashboards that combine SLA data with project-level metrics, can be challenging.
• Proactive Alerts: Standard functionality typically reports on breaches after they occur, limiting your ability to intervene proactively.

Where SLA Time and Report Helps 

When your goal is truly cross-departmental SLA enforcement and reporting, extending Jira's native functionality becomes necessary. SLA Time and Report for Jira is an example tool that solves these limitations by providing an extra layer of visibility and flexibility.

It functions as a concrete solution to ensure time-based discipline applies universally:

✔️Beyond JSM: It allows you to track, display, and report on SLAs in any Jira project type–Software, Business, Service, or custom.

✔️Advanced Alerts: You can configure alerts (via comments or Slack integration) to notify assignees, managers, or external stakeholders when an issue is, for example, 80% close to breach, allowing proactive intervention before a failure occurs.

✔️Complex Tracking: It enables the configuration of highly customized SLA timers based on complex criteria, such as specific status, custom field values, or even tracking time between handoffs in multi-project workflows.

✔️Manager Reports: The tool provides dedicated, pre-built reports focusing on managerial oversight, such as compliance trends, bottleneck identification, and assignee-level performance ranking.

Sample Metrics and Dashboards 

The data tracked by SLAs is the foundation for effective management. By visualizing this data, managers can move from reacting to problems to proactively managing processes.

Key Managerial Metrics 👇

Metric Name	Interpretation	Use Case
First-response SLA met % (by assignee/team)	Measures the team's discipline and responsiveness to new requests.	Sales, Legal, Shared Services Intake
Average breach time per issue type	Identifies which specific service items (e.g., "High-Risk Contract," "Urgent Purchase") suffer the greatest delays.	Legal, Ops
Average time in 'Waiting for Customer'	Identifies process stalls caused by the requestor, helping the team manage expectations and follow up.	All teams
Tickets with multiple re-openings	Indicates issues with quality of service or definition, highlighting training or process weaknesses.	All teams

You can build these using a combination of Jira's native gadgets and specialized widgets from the SLA Time and Report app, here how it looks like:

Conclusion: The Universal Discipline of Time

The core principle behind Service Level Agreements–setting clear, time-bound expectations–is not limited to ITSM. It is a universal discipline tool for any business process managed in Jira. By extending SLA tracking to Sales, Legal, and Operations, you transform vague process goals into measurable business commitments.

The result is less internal friction, clearer accountability, protected workloads for employees, and a better, faster experience for your customers, whether they are external clients or internal colleagues.

We encourage readers to experiment: Start small. Implement 1–2 simple, high-impact SLAs in a non-IT department, such as "First Response to a Hot Lead" in Sales or "Time to Acknowledge Contract" in Legal. Use the resulting data from your Jira reports, potentially enhanced by app – SLA Time and Report, to refine goals, identify process bottlenecks, and iterate toward a more disciplined, predictable operation.