The Inbox Clause: Catching Software Term Changes Before Continued Use Counts as a Yes

Most software contracts do not get renegotiated in a meeting room with biscuits. They change by email, by a link in a portal, or by a banner that appears when someone logs in on a Tuesday. The vendor calls it an update. Your team calls it admin. The clause calls it deemed acceptance.

That is the quiet part. Continued use can be treated as agreement, and the change can land between renewals when nobody is looking. For small UK teams, the risk is not usually a dramatic outage. It is a data-processing addendum that shifts sub-processors, an acceptable-use policy that quietly rules out a normal workflow, or a price clause that grows teeth at the next invoice.

You do not need a legal department to handle this. You need a place to put the notices, a person who owns the first read, and a deadline that is not set by the vendor.

Why these notices slip past

Software terms change for ordinary reasons: new features, new security commitments, a shift in hosting, a new parent company. The problem is the delivery. A notice lands in a shared inbox that three people watch and nobody owns. It arrives as a PDF attachment named terms-update-final-v3. It sits behind a portal login that only one former employee used. Or it is announced in a product dashboard that your team only opens when something is on fire.

The practical result is that the first proper read often happens after the change has already taken effect. That is a bad time to discover that your data-processing addendum now names a sub-processor in a country you have not assessed, or that the support policy has moved from 'we will respond' to 'we will acknowledge'.

Start with a terms register, not a legal review

A terms register sounds grander than it is. A shared spreadsheet will do. For each supplier, record the contract owner, the renewal date, the notice address, the notice period, the date the terms were last reviewed, and a link to the current terms. Add a second link: the version you archived last time. That last column is the one that saves arguments.

When a notice arrives, save a copy of the new terms and the covering email. Do not rely on the vendor's portal as your only record. Portals change. Inboxes get cleaned up. If the question later is 'what did we agree to in March?', you want a file you can open without asking the supplier for permission.

Give the first read to a person, not a folder

Name someone to triage change notices. It does not have to be the most senior person in the room. It does have to be someone who knows the difference between a typo fix and a clause that changes who can access your data.

A simple triage rule works: any notice that touches data, money, security, exit rights or acceptable use gets a second read. Everything else can be filed with a note. Set a target of ten working days for the first read and thirty days for a response. Put those dates in the calendar at the moment the notice arrives. Vendors are very good at setting deadlines. Your team should set one too.

Read the clauses that actually move

You are not looking for a full contract review every time. You are looking for movement in a handful of places.

Check the data-processing addendum and the sub-processor list. If a new sub-processor appears, ask what it does, where it sits and whether your UK GDPR obligations are still covered. Check the security schedule. A change from 'encrypted at rest' to 'encryption available' is not a wording tweak. Check the acceptable-use policy. If it now bans a workflow your team relies on, you need to know before the next audit, not after.

Check money clauses: price indexation, auto-renewal, minimum seat counts and overage charges. Check liability caps, indemnities and termination rights. Check suspension rights. A supplier that can suspend service for a minor policy breach without notice is a different supplier from the one you thought you bought.

And check the notice clause itself. If the vendor has changed how it delivers notices, or shortened the objection window, that is worth a conversation before the next change arrives.

When to push back

Not every change needs a fight. A new feature description or a clarified support channel is usually fine to accept. Push back when the change is material and the notice was thin: no clear effective date, no explanation, no chance to object, or a data-processing change that leaves your UK compliance story worse than it was.

A short email is often enough. State that you are reviewing the change, that you do not treat continued use as acceptance while the review is open, and ask for the effective date and the rationale. Keep it factual. Copy the contract owner. Calendar the follow-up. If the change affects personal data, involve whoever owns data protection in your organisation and consider whether the ICO's guidance on contracts and processors is relevant to your situation.

If the supplier will not budge on a material point, you have found something useful: a real negotiating issue before renewal, while you still have leverage. That is much better than discovering it after the invoice has gone up and the migration window has closed.

Make the decision visible

Whether you accept, negotiate or plan an exit, write it down. A one-line note in the register is enough: date, decision, who agreed it, and what happens next. This is not bureaucracy for its own sake. It is the difference between a team that knows what it agreed to and a team that is hoping the answer is still in someone's inbox.

Software terms will keep changing. That is normal. The quiet part is optional. Put a person, a file and a date on the change notice, and continued use stops being the thing that decides for you.