Best Practices & Industry standards for defining SLAs in the Demand Workflow

[John_Stein]

Calling all Platform Owners...and especially those with an efficient Demand intake-to-project approval process...

We're going through an overhaul of our entire Demand intake process to have a defined, single-source intake, where all required stakeholders who currently have some involvement (awareness, approvals, tasks, assessments, etc.) are embedded at the right time, with the right prerequisite data points, to drive action and efficient decisions. The challenge now is to propose realistic SLAs throughout the entire Demand lifecycle to enforce the process with teams.  

Any POs have experience on establishing Demand SLAs for their organization? 

[Mark Manders]

Realistic SLAs depend on what you already have. If you already have metrics/duration reports that show you how long it takes now, you may be able to put some realistic SLAs on the demands.

Measuring the SLAs is a different thing, depending on your process. If you have a demand, is there only one team working on it, or is it send to different teams throughout? And if different teams are involved, is it the actual demand that is handed over, or are you using tasks for the teams to add their part? 

With multiple teams on one demand, it is possible to calculate the time per team on that demand, but in that case you also need to define 'realistic' up front. Where one demand may be realistically go into project within a week (clear requirements, high value, low effort), another one may take months. 

[Phil Scherry]

While ServiceNow technically lets you attach a task SLA to almost anything extending task, applying traditional binding SLAs to Demands introduces friction and skewed incentives:

1. Intake Governance vs. Operational Break-Fix: Demands are strategic evaluation buckets, not operational transactions. A Demand's lifecycle depends heavily on business prioritization, budget alignment, funding cycles, and stakeholder reviews—most of which lie outside the fulfillment team's immediate control. Putting a rigid clock on qualification or approval usually encourages rubber-stamping rather than sound vetting.
2. Resource & Priority Contention: Operational work must strictly supersede strategic intake. If an IT team is balancing work across artifacts, a standard priority hierarchy should govern capacity:
   • Tier 1 (Operational Health): Incident (INC) & Problem (PRB)
   • Tier 2 (Standard Service Fulfillment): Request / RITM (REQ)
   • Tier 3 (Delivery / Value Creation): Agile Story / Defect (STRY)
   • Tier 4 (Strategic Evaluation & Planning): Demand (DMND)
   • A breach timer on a Demand should never draw shared engineering or architecture focus away from a high-priority incident or critical release sprint.
3. Data Before Commitments: Seconding Mark's point—if you don't have historical throughput data, committing to formal timelines is setting teams up for failure. A 6-month observation period is ideal to establish standard cycle time distributions (e.g., Draft → Qualified, Qualified → Approved), identify external review bottlenecks, and filter out outlier review windows.

Recommended Alternative Approach:

• Use KPIs and Target Durations, not Binding SLAs: Measure Lead Time / Cycle Time using Performance Analytics or basic reporting against phase timestamps rather than active breach clocks with escalations.
• Internal OLAs for Business Relationship Managers (BRMs): If accountability is mandatory, establish an internal OLA specifically for the Screening / Triage state (e.g., "Initial review completed within 5 business days"), pausing the clock when awaiting business clarification.

[vaishali231]

Hey @John_Stein 

I think defining SLAs for each stage of the Demand lifecycle would be a practical approach. For example, intake validation could take 2 business days, stakeholder assessments 5 business days, and final approval another 5 business days once all required inputs are available.

It’s also important to define clear ownership, send reminders for pending actions, and have an escalation process for overdue tasks.

I’d be interested to know how other organizations handle delays when multiple teams are involved in the approval process.

***********************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb