What changes for you
You can answer the question nobody could answer before. Your terms of service have changed over the years: a new price rule, a clearer refund line, a section added when you started selling in a new market. Each version was right when you published it. But the product never noted who agreed to which one.
Then a customer disputes a charge. They say the rule you are pointing to was not there when they signed up. Your team opens the current terms, finds an older copy in a shared folder, and still cannot say which of them this person saw and accepted, or on what day. The conversation turns into a guess, and a guess is a weak place to argue from.
With this work, your product keeps each acceptance with two things attached: the version of the terms the user accepted, and the date they accepted it. When the question comes, someone on your team looks at that user’s line and reads the answer. When you publish a new version, users are asked to accept it, so the record moves with your terms instead of falling behind them.
This is not consent to cookies. That is a separate question about what loads on a visitor’s device, covered in making your cookie banner do what it says. Nor is it a history of every change people make in their accounts, which is showing your customers who changed what. This page is about one thing: which terms each user agreed to.
What you decide
You decide what counts as a new version. A typo fixed on a Tuesday is probably not one, and a new refund rule probably is. Where that line falls is your judgement, made with whoever advises you on your terms. We do not write your terms, interpret them or tell you what the law asks of them. This page is not legal advice.
You decide how the request to accept looks and where it appears, so it reads as part of your product. You decide what happens to a user who has not yet accepted the new version: whether they can carry on as before while they think it over, or whether the request comes first. You decide who on your team may look up a user’s line, and how a version is named so your support staff recognise it at once.
You decide what ships. Nothing reaches your users without your approval.
What you see along the way
The work lands in your own code repository, as small changes your team can read and approve before any user meets them. You can check the result the way a user would: sign in, accept the terms, then look up that user and see the version and the date beside their name. When a new version of the terms is published and that user signs in again, the request to accept is waiting.
Where a choice is yours, such as what a user who declines can still do, it reaches you with the question and a link.
What it costs you in time
A first conversation about your terms as they stand: how many versions you have published, where they live today and which questions about them reach your team. After that, a little time from the person who looks after your terms, because what counts as a new version is theirs to confirm.
What if you want to stop
Whatever you have approved by then is already in your repository. The code we build for you is yours. Your code and your product stay yours to take anywhere.
Starting small
This would be new work for us on a customer product, and we say so plainly. A sensible first piece is the record on its own: from the next sign-up on, each new acceptance is kept with its version and date. You see it working on a handful of users before deciding how to ask existing users to accept again. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.
