Your SaaS Stack Doubled in 18 Months. Your Renewal Process Did Not.

In growth mode, buying decisions are fast and decentralised. A team lead has a problem. They evaluate two or three tools, pick the best fit, and sign an annual contract. Procurement either does not exist yet or is not in the loop for sub-£50k tools. The contract goes into someone's inbox, sometimes a shared drive, and that is the last anyone thinks about it until the vendor sends a renewal notice.

This is not irresponsible. It is the correct behaviour for a company that is growing fast and needs to move quickly. The problem is not the buying decision. The problem is that the process never matures when the company does. The same informal approach that worked for 30 contracts becomes a liability at 80.

At 80 contracts, a 5% average annual uplift on £1.2M of SaaS spend is £60,000 a year in price increases landing without any review. At 30 contracts, nobody noticed. At 80, the CFO notices on the first budget cycle that tries to cut costs.

The renewal process at most scale-ups is not a process. It is a combination of vendor-sent renewal notices, a shared spreadsheet that someone updates when they remember, and a handful of calendar reminders set by whoever signed the original contract.

That approach works at 10-15 contracts. At 30 it starts to show gaps. At 80 it collapses.

The fundamental reason it never scaled is that nobody was specifically responsible for scaling it. RevOps owns the process, but RevOps was also hired to instrument the sales pipeline and build the reporting layer. Finance owns the budget, but Finance sees the invoice, not the contract. Procurement, if it exists, was brought in at 200 people when the stack was already at 60 tools and most of the damage was done.

The spreadsheet that works at 15 contracts requires someone to maintain it at 80. When that person leaves - and in a scale-up they often do - the spreadsheet stops being maintained. Within two quarters it is out of date. Within a year it is a liability, because people trust it when they should not.

Seat-based SaaS contracts have a structural problem at scale-ups: they are bought during hiring cycles and renewed during efficiency cycles.

A sales team signs a 40-seat contract for a sales engagement platform in Q1, expecting to reach that headcount by Q3. The company hits a hiring freeze in Q2. 22 of the 40 seats are active. The contract renews in Q4 at 40 seats plus a 6% uplift. Nobody catches it because the person who signed the contract left in the reorg, and the renewal notice went to their old email address.

This pattern repeats across every seat-based tool in the stack. Zoom rooms for offices that closed. Figma licences for designers who were laid off. Salesforce seats for BDRs who left in the last RIF. Each one a small overspend. Collectively, seat overprovisioning across an 80-tool stack is often 15-25% of total SaaS spend.

The catch is that rightsizing seats requires knowing three things simultaneously: what seats are provisioned, what seats are actively used, and when the notice window to change them is. Most scale-ups can answer one of those three questions on any given day. Almost none can answer all three.

At a 200-person company that has been operating for four years, roughly half the people who signed the first 30 contracts are no longer there. That is not a pessimistic assumption - it is close to the median for a scale-up that went through a growth phase and then a reorg or RIF.

When the person who signed the contract leaves, three things happen. First, the renewal notice goes to their old email or their manager's inbox. Second, the institutional knowledge about what the tool does and whether it is still needed leaves with them. Third, the relationship with the vendor account manager disappears, which means the company loses any goodwill built up over multiple renewal cycles.

The result is that a quarter of the contracts in a typical scale-up's portfolio have no active owner. Nobody who has the combination of context, authority, and calendar reminder required to manage the renewal. Those contracts almost always auto-renew at the standard uplift.

Ownership is not a difficult problem to solve, but it requires a register. You cannot assign an owner to a contract you do not know exists.

SaaS vendors have been raising renewal prices consistently. The industry average uplift on an annual contract renewal is running between 5% and 9% depending on the category. Security tools and data infrastructure are closer to 9%. Productivity and collaboration tools are closer to 5%. Either way, a company that does not actively manage renewals is accepting those increases by default.

On a £1.2M SaaS spend, a 7% average uplift is £84,000 a year in price increases. Over three years, compounded, the same stack costs roughly £1.46M. The extra £260k did not buy any additional capability. It bought the same contracts at higher prices because nobody pushed back.

Pushing back requires lead time. The typical vendor contract gives 30-60 days of notice before auto-renewal. That is barely enough time to review the contract, assess usage, compare alternatives, and have a meaningful negotiation. Most procurement teams that find themselves inside a 30-day notice window take the uplift. The vendor knows this - the notice window is designed to create exactly that time pressure.

The companies that negotiate renewals effectively start the process 90 days out. At 90 days, there is time to pull usage data, identify seat overprovisioning, assess alternatives, and approach the vendor with either a credible walk-away or a credible consolidation play.

The companies now facing this problem all share a similar history. They bought fast in 2021-2023. They are now renewing in a tighter environment with a CFO who wants every line item justified.

The challenge is that the contracts were built for growth mode. Annual terms with seat counts set at headcount targets that were never reached. Uplifts that nobody reviewed because the tool budget seemed small relative to the ARR target. Renewal cycles that nobody managed because there were 40 other priorities.

The reckoning is not dramatic. It is a slow accumulation of auto-renewals, each one defensible in isolation, that adds up to a SaaS spend figure that looks embarrassing in the context of a company that is now being asked to cut 15% of operating costs.

The fix is not complicated. It is not even particularly expensive. What it requires is a register, ownership, and enough lead time to have a real conversation before the notice window closes.

A renewal process that works at 80 contracts has five components that a spreadsheet cannot reliably provide:

• A complete register. Every active contract listed, not just the ones someone remembered to add. Vendor name, contract value, renewal date, and - critically - the notice deadline, which is often 30-90 days before the renewal date. These are not the same thing.
• A named owner per contract. One person who is accountable for the renewal decision. Not a team. Not a shared inbox. One named individual who will still work there when the renewal lands.
• Alerts that fire 90 days out. Not 30. Not a calendar reminder that gets buried. Ninety days is the minimum lead time to do anything meaningful with a renewal. Sixty days is the absolute floor for a negotiation. Thirty days is damage control.
• A lightweight review step. For each renewal, a prompt to check current seat usage against provisioned seats, and a quick assessment of whether the tool is still the right fit. This does not need to be a committee review. It needs to be one person with the right data answering two questions.
• A decision log. Renew at standard uplift, renegotiate, rightsize, or cancel. One line per contract per cycle. This is what turns renewal management from a reactive scramble into a trackable process.

None of this is complex. The barrier is not process design. The barrier is that building the register from scratch, assigning owners, and setting up the alert cadence takes time that RevOps teams rarely have when they are also running the reporting layer, the CRM, and the comp plan.

Renewly is a vendor contract register built for exactly this situation. Upload your contracts - the PDFs from vendor confirmations, order forms, signed agreements. Renewly extracts the vendor name, contract value, category, and notice deadline. Each contract gets an owner, a renewal alert at 90 days, and a record of what was decided. The register builds itself as contracts are added rather than requiring manual data entry across 80 rows.

For RevOps teams inheriting a stack that grew without a process, it is the fastest path from a spreadsheet held together by memory to a register that survives employee turnover.

Free for up to five vendor contracts.