procurement-optimizer

# Procurement Optimizer

Most software spend reduction is not a negotiation problem. It is a measurement problem:
organisations buy seats in round numbers, assign them generously, and never look at whether
anyone logs in. The typical mid-size portfolio carries 20-30% reclaimable seat spend before
anyone talks to a vendor, and the reclaim requires no concession from the vendor at all.

This skill works the levers in order of yield: **stop paying for unused seats**, then
**stop paying twice for the same capability**, then **negotiate price**. Reversing that
order — leading with a price negotiation on a bloated contract — is how organisations
congratulate themselves on a 10% discount against 40% more seats than they need.

## When to use this skill

- A **budget-reduction target** has landed and software spend is in scope
- A **renewal is approaching** and you need a defensible position before the vendor call
- **SaaS sprawl audit**: nobody can say how many tools the company pays for
- **Post-merger consolidation** where two portfolios overlap heavily
- Building a **renewal calendar** so contracts stop auto-renewing unexamined
- A vendor has proposed an **uplift** and you need leverage to counter it

## Inputs the skill expects

- **Spend inventory**: tool, category, annual cost, renewal date, contract term
- **Seat data**: purchased, assigned, and — critically — *active in the last 30 days*
- **Contract terms**: notice period, auto-renew flag, term length
- **Criticality** per tool, and whether a capability alternative exists
- **Headcount**, for per-head benchmarking
- The **as-of date**, so renewal-window maths is reproducible

## Clarify First

Before generating, confirm these inputs. If any is unknown or vague, ASK — do not assume:

- [ ] **Whether seat data is assigned or active** — this is the single most consequential input. Assigned seats overstate usage by 30-60%, and an analysis built on them finds almost nothing
- [ ] **Notice periods and auto-renew flags** — a contract inside its notice window is committed for another full term, so its "savings" are not available this cycle and must not be counted toward a target
- [ ] **Whether the goal is in-year cash or run-rate reduction** — seat cuts at renewal reduce run-rate but may deliver nothing this fiscal year, which is the wrong answer to an in-year cash problem
- [ ] **Which tools are politically untouchable** — if the CRM is the CRO's and cannot be cut, that changes which opportunities are worth analysing at all

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

## Workflows

### Workflow 1 — Find the wasted seats

Start here always. It requires no vendor conversation and no cross-team negotiation.

1. Assemble the inventory with purchased / assigned / **active-30-day** seat counts. If you
   only have assigned counts, stop and get active counts — the analysis is not meaningful
   without them.
2. Run the analyser. It compares active utilisation against a per-category benchmark (an LMS
   is not used weekly; a CRM is) and sizes reclaimable spend with a 12% safety buffer.
3. Separate the two failure modes it reports. **Over-licensed** means cut seats.
   **Adoption failure** means seats are assigned to people who never log in — cutting seats
   there treats the symptom, and the tool may simply not deserve to survive.

```bash
python3 business-operations/procurement-optimizer/scripts/license_utilization_analyzer.py \
  --input business-operations/procurement-optimizer/assets/sample_spend.json --format text
```

### Workflow 2 — Find the tools you are paying for twice

1. Run the overlap detector. It groups by category and picks a survivor by **displacement
   cost**, not by price — moving 400 active users is expensive regardless of licence cost.
2. Check the umbrella-label warnings first. If it flags a category as an umbrella, your
   tagging is claiming that a wiki and a chat tool are substitutes. Re-tag by the job the
   tool does and re-run before believing any number in the output.
3. Treat the recovery figure as net of an assumed 20% migration cost. Consolidations that
   look marginal at 20% are usually negative in reality once you count the disruption.

```bash
python3 business-operations/procurement-optimizer/scripts/tool_overlap_detector.py \
  --input business-operations/procurement-optimizer/assets/sample_spend.json --format text
```

### Workflow 3 — Rank the opportunities against the renewal calendar

1. Run the ranker with an explicit `--as-of`. It discounts each opportunity by how much
   leverage the renewal timing actually gives you this cycle.
2. Work the shortlist top-down. Time-boxed items (inside the notice window or in the ideal
   T-120 to T-90 negotiation window) are promoted above higher-ROI items on distant renewals,
   because missing a window costs a full contract year.
3. Read the `locked_this_cycle` figure to leadership before committing to a savings number.
   It is the portion of the opportunity that is genuinely unavailable this year, and
   discovering it after committing to a target is a bad conversation.

```bash
python3 business-operations/procurement-optimizer/scripts/savings_opportunity_ranker.py \
  --input business-operations/procurement-optimizer/assets/sample_spend.json \
  --as-of 2026-07-21 --top 10 --format text
```

## Decision frameworks

### Utilisation benchmarks by category [RECOMMENDED]

Active seats in the last 30 days, divided by seats purchased. A single flat benchmark is the
most common analytical error here — it flags an LMS as catastrophically wasteful when quarterly
use is its normal pattern.

| Category | Healthy active utilisation | Why |
|----------|---------------------------|-----|
| Security / identity | 90% | Near-universal deployment; unused seats are pure waste |
| CRM, chat, support desk | 85% | Daily-use tools with a defined user population |
| Developer tools