The 5 Steps to Close the Loop on a Feature Request From a Year Ago

I once watched a PM ship a feature, open the original request to send the good news, and find a ticket from fourteen months earlier written by someone whose email now bounced. The account was still paying. The champion had moved to a competitor. The request itself described a workflow the shipped feature only half solved. She closed the tab. That loop is still open, and it is the most common kind of open loop there is, because the requests that take longest to build are the ones most likely to outlive the person who asked.

The five steps to close the loop on a year-old feature request are: reconstruct the request from the record, verify the requester and the account still exist, compare what shipped against what was asked, send the specific version rather than the changelog, and close the theme rather than the ticket. What separates a stale loop from a fresh one is not the delay. It is that everything you need to write the message has decayed: the wording, the contact, and the tag it was filed under.

What makes an old request harder to close than a new one

Three things rot at different speeds.

The record rots first. A request filed a year ago was tagged against a taxonomy that has since changed. The category it sits in may no longer exist, which means the query you run at release time does not return it.

The contact rots second. In B2B, the person who filed the request may have changed teams, changed companies, or left. The account usually survives. The individual often does not.

The framing rots last. What the customer asked for in the original words and what you actually shipped are rarely the same thing after a year of roadmap iteration. Sending a triumphant "you asked, we built it" when you built two thirds of it reads worse than silence.

Forrester's 2025 survey found only 27% of VoC and CX teams communicate insights back in a timely way. Old requests are where the other 73% accumulates, quietly, as a backlog nobody reports.

The 5 steps to close the loop on a year-old feature request

1. Reconstruct the request from the record, not from memory

Pull the original text. Not the roadmap item, not the Linear ticket, the actual thing the customer wrote or said. Then pull every other record about the same ask that arrived in the intervening year, across tickets, call transcripts, Slack, and reviews. A request that sat for a year almost always got re-raised, and the newest record has both a fresher contact and clearer wording. If your feedback lives behind an adaptive taxonomy, that grouping already exists and the reconstruction is a query rather than an archaeology project.

2. Verify the requester and the account separately

Check two things independently: is the person still reachable, and is the account still active. That gives you four cases and only one of them is the easy one. Original requester still there: send it to them. Requester gone, account active: send it to the current owner of that workflow and reference the original request by date. Account churned: this is a win-back trigger, not a loop closure. Requester gone and account churned: log the theme and move on. Account context on the request record is what makes this a lookup instead of a research task, which is what the customer context graph is for.

3. Compare what shipped against what was asked, honestly

Read the original request against the shipped feature and grade it: fully solved, partially solved, or solved differently. Then write the message to match the grade. Partial solutions get partial claims. "You asked for bulk export with scheduling. Scheduling shipped last week, bulk export is not in yet" is a closed loop. "Great news, we shipped export" when they asked for scheduled export is a reopened complaint. If the answer is solved differently, explain the different shape before claiming the win. The related move when the answer is no is covered in telling a customer you are not building their request.

4. Send the specific version, not the changelog

The message has to name the request, the date, the shipped behavior, and one next action. Acknowledge the delay in one clause and do not dwell on it. A year of silence is not repaired by an apology paragraph, it is repaired by specificity that proves the request was actually retained. Route it through the channel the request came in on, the Slack thread or the ticket, rather than a generic email, since the original context is right there and does half the work for you.

5. Close the theme, not just the ticket

One year-old request is almost never one customer. Before you consider the loop closed, notify every other requester in the theme, and check whether the theme is still generating new feedback after the release. If mentions do not decline, the fix did not land, and the loop you just closed will reopen. That verification step is its own discipline, covered in verifying a fix actually reduced complaints.

Why the stale loop is a taxonomy problem, not a CRM problem

Teams try to solve this with better contact hygiene. Cleaner CRM, more diligent ticket linking, a spreadsheet of who asked for what.

That is the wrong layer.

The reason a year-old request goes unclosed is almost never that the email address was missing. It is that nobody could find the request when the feature shipped, because the request and the release were filed as different objects, under different vocabularies, by different teams, twelve months apart. Contact data decays at maybe 25% to 30% a year. Taxonomy relevance decays faster, because your product changed and your categories did not.

A taxonomy that learns from the feedback itself keeps old requests findable, since a theme defined by what customers said in March 2025 still matches what they said in August 2026 about the same underlying need. Manual tags do the opposite: they freeze the vocabulary of the quarter they were written in, and every quarter after that, a few more old requests fall out of reach.

The practical test is one query. Pick a feature you shipped last month. Ask your feedback system for every request about it, going back two years, and see whether it returns records from before the roadmap item existed. If it does not, your open-loop backlog is larger than your close-loop rate suggests, and no amount of CRM hygiene will surface it.

How to handle the three cases you will actually hit

The requester is still there. Send it directly, reference the original date and wording, name the gap if the solution is partial. This is the case everyone plans for and the least common one on a year-old request.

The requester is gone, the account is active. Send it to whoever owns that workflow now, with the original request attached as evidence that the account was heard. Have the CSM deliver it rather than sending an automated note, since the new contact has no memory of the request and needs the context.

The account churned. Do not send a shipped-feature note as if the loop is closing. Route it to the win-back motion instead, where a feature that a churned account named as a reason for leaving is the strongest re-entry point you have.

The decision rule: weight account context over contact freshness. A live account with a dead contact is a closable loop. A live contact at a dead account is a sales conversation.

FAQ

Is it too late to close the loop on a request from a year ago?

No, and the delay is usually less damaging than the silence. Customers rarely track how long a request has been open, but they do notice when a company remembers something they said and can quote it back. Specificity outweighs speed on old requests.

Should I apologize for the delay?

One clause, not a paragraph. Name the delay, then move to what shipped. Extended apology shifts the message from an update to a service-recovery note and invites a conversation about everything else that is slow.

What if the feature only partly solves what they asked for?

Grade it before you send it and claim only what shipped. A partial claim closes the loop. An overstated claim reopens it, and the second complaint is harder to answer than the first.

How does Enterpret help close loops on old requests?

Enterpret's adaptive taxonomy groups requests by what customers actually meant, so a request from a year ago still surfaces in the same theme as today's feedback even though your categories have changed since. The customer context graph attaches the account, plan tier, and revenue to each request, which is what lets you separate the live-account cases from the churned ones without manual research.

How do I know how many old requests are still unclosed?

Count shipped features from the last four quarters, reconstruct the requester list for each by theme, and subtract the requesters you actually notified. That difference is your open-loop backlog. Most teams have never calculated it, which is why it keeps growing.

If your open-loop backlog is older than your tagging system, see how Enterpret's close the loop workflows surface requests your categories have outgrown.

‍