Procurement vs Operations Ownership: Who Decides on SaaS and When

The operations team had been evaluating project management tools for six weeks. They'd done demos, run a pilot, scored vendors, and identified a clear winner. The contract was ready to sign.

Legal flagged it. Procurement was simultaneously evaluating three of the same vendors for a company-wide deployment. The operations team hadn't known. Procurement hadn't known the ops team was running a parallel process. And the vendor the ops team had chosen was actually the vendor procurement had ranked third.

The COO now had to make a decision that was politically difficult regardless of which way it went: override the operations team's six weeks of work, or override procurement's in-progress evaluation. Either option consumed goodwill and set a precedent.

The root cause wasn't a bad decision by either team. It was an undefined authority structure. Nobody had answered the question: when does operations decide, when does procurement lead, and how do they hand off when the size or scope crosses a threshold?

That's the question this guide answers.

Why SaaS Authority Is Undefined at Most Mid-Market Companies

Mid-market companies typically don't build formal procurement functions until they're experiencing procurement problems. By then, the informal buying culture is established and difficult to change. Deloitte's Global Chief Procurement Officer Survey consistently finds that companies without formalized procurement authority at the mid-market stage spend 20–35% more on technology categories than comparably sized companies with defined ownership structures.

The evolution usually looks like this:

• 0-50 employees: Founder or COO approves everything. Informal but functional: the CEO knows every tool.
• 50-150 employees: Informal approval at manager level, with finance spot-checking. Most purchases happen below the visibility threshold.
• 150-500 employees: IT, Finance, and Operations are all involved in different purchases with no consistent process. Conflicts emerge. Shadow IT is significant.

The 150-500 range is where SaaS authority needs to be formalized. The organization is too large for CEO-level visibility on every purchase, but not yet structured enough to have built the governance rails. And the SaaS spending is large enough (typically $300K-$1M+ annually) to warrant the structure. Forrester's research on technology governance maturity identifies the 150–500 employee range as the highest-risk window for technology spend management — organizations that formalize authority structures during this growth phase show 40% lower SaaS spend per employee at the 500-person milestone than those that defer governance until a crisis forces it.

The Three Ownership Models

Model 1: Threshold-Based Authority

The most common and practical model for mid-market companies. Authority is assigned based on contract value:

Advantages: Simple to communicate, easy to enforce, maps to financial materiality.

Disadvantages: Threshold gaming. Teams break purchases into multiple smaller contracts to stay under the threshold. Requires a "look-back" rule: purchases from the same vendor, or tools serving the same function, are aggregated for threshold purposes regardless of how they're structured. This is also how SaaS sprawl compounds — small under-threshold purchases that individually seem fine accumulate into a portfolio nobody is overseeing.

Model 2: Category-Based Authority

Authority is assigned by tool category rather than by value:

Advantages: Category expertise drives the decision. HR owns HR tools, revenue operations owns sales tools. Better decisions in specialized domains.

Disadvantages: Category boundaries are fuzzy. A CRM is a sales tool. But it's also an IT tool. And a customer data tool. Category disputes require a tiebreaker.

Model 3: Hybrid Model (Operations Decides Below Threshold, Procurement Advises)

A pragmatic middle ground that works well for companies with an emerging procurement function:

• Below $10K: Operations decides with IT registration requirement. Procurement is available as an advisor but doesn't have approval authority.
• $10K-$50K: Operations leads the evaluation; procurement advises on RFP process, contract review, and negotiation. Joint decision with escalation to COO if unresolved.
• Above $50K: Procurement leads the process; operations is the primary stakeholder who defines requirements and evaluates capability. Joint decision.

The key principle: Procurement's value-add is process expertise (RFP management, contract negotiation, vendor diligence) and portfolio oversight (preventing duplicates, managing aggregate spend). Operations' value-add is use case knowledge (what the tool needs to do and how it fits into workflows). The model fails when procurement becomes a bottleneck rather than an accelerator, or when operations bypasses procurement to avoid perceived slowdown. For tools above the threshold, how to run a SaaS RFP is the three-week process template that keeps the procurement-led evaluation moving quickly enough that teams don't route around it.

Choosing the Right Model

The SaaS Authority Matrix Template

Build this matrix for your company. Fill in every cell before publishing the policy.

The Post-Purchase Ownership Assignment

A question almost as important as "who decides": who owns the vendor relationship after the contract is signed?

This is where most governance frameworks stop. They define the approval process and leave ownership undefined. Then the original champion leaves, the renewal approaches, nobody knows the terms, and the contract auto-renews by default.

Post-purchase ownership assignment template:

For purchases under $10K, one person may fill all three roles. For purchases over $50K, these should be separate people.

This assignment should be documented when the contract is signed, stored in the SaaS registry, and reviewed annually.

The Escalation Decision Tree

When operations and procurement disagree on a SaaS purchase decision, the escalation path needs to be defined before the conflict occurs.

Standard escalation tree:

Is this a new purchase or a renewal?
├── New purchase
│   ├── Under threshold? → Operations decides per authority matrix
│   └── Over threshold?
│       ├── Both ops and procurement agree? → Joint recommendation to exec
│       └── Ops and procurement disagree?
│           ├── Is the disagreement about capability? → Operations wins (they define requirements)
│           ├── Is the disagreement about price/terms? → Procurement wins (their domain)
│           ├── Is the disagreement about vendor risk? → IT/Security wins (risk is their domain)
│           └── Is the disagreement about strategy? → COO decides within 48 hours
└── Renewal
    ├── Under $10K? → Business owner decides; commercial owner negotiates
    └── Over $10K? → Business owner + commercial owner joint decision; COO if disagreement

The "COO decides within 48 hours" rule is critical. Open-ended escalations kill momentum. Build a time limit into the process.

Common Failure Modes

Procurement as gatekeeper, not enabler. When every purchase above a threshold requires procurement sign-off and procurement runs a six-week cycle, teams bypass the process. The fix is service-level standards for procurement: a $20K purchase should have procurement turnaround in five business days, not three weeks.

Authority policy without process. Defining who can approve what doesn't help if there's no system for tracking approvals, no SaaS registry for registering new tools, and no renewal calendar for managing upcoming expirations.

Policy that operations ignores. A policy that isn't enforced is worse than no policy. It creates the appearance of governance without the reality. Build the policy around a workflow that teams actually follow: an approval form, a Slack channel, a SaaS registry. The policy should require minimal extra steps, not a bureaucratic detour.

Undefined ownership at contract signature. The moment a contract is signed, the business owner, technical owner, and commercial owner should be assigned and recorded. If this isn't done at signature, it becomes harder to do retroactively. This is especially important for contracts with complex renewal terms — the SaaS contract red flags guide covers the auto-renewal and notice window clauses that only matter if someone actually owns the renewal calendar.

Making the Policy Stick

The most common reason governance policies fail is that they're designed as documents rather than workflows. A document can be ignored. A workflow is part of how work gets done. McKinsey's research on organizational change in procurement functions found that procurement policies embedded into existing approval workflows achieve 3–4x higher compliance rates than standalone policy documents, regardless of policy content.

For the policy to stick:

1. Build the registry. Every approved tool goes into a central tool (a spreadsheet is fine to start; a proper SaaS management platform as you scale) with owner, cost, renewal date, and status.

2. Automate the renewal alerts. Ninety days before every renewal above $5K, the commercial owner gets an automated reminder. This one change eliminates most renewal surprises.

3. Make compliance the easy path. The approval workflow should take ten minutes for a $3K tool, not thirty. If the process is painful, teams route around it.

4. Review exceptions publicly. When a team buys a tool outside the process, address it in a forum where other team leads see it. Shadow IT persists when it has no consequences.

5. Report on the portfolio quarterly. A brief portfolio review (total spend, tools added, tools removed, upcoming renewals) keeps leadership visibility current without requiring a deep audit every time.

Measuring Whether Governance Is Working

The ops satisfaction score is worth tracking explicitly. If operations consistently rates the procurement process poorly, the policy is creating friction that will generate workarounds. That friction is worth diagnosing and removing.

Learn More

• The SaaS Buying Decision Tree: When to Buy, Build, or Bolt On — the decision framework that operates within the governance structure
• How to Run a SaaS RFP That Doesn't Waste 6 Weeks — what the procurement-led process looks like for purchases over the threshold
• The SaaS Sprawl Problem: Signs You Have It and How to Fix It — what happens when governance is absent for too long
• SaaS Consolidation: When to Cut a Tool vs. Keep It — the cleanup exercise that good governance prevents from being necessary
• Measuring SaaS ROI 90 days after purchase — how to tie business owner accountability to measurable outcomes at 90 days
• AI governance policy for departments — how to extend the authority framework to govern AI SaaS purchases specifically