How to tell customers a promised feature is delayed

Why a delay hurts more than the delay itself

Most customers can live with a late feature. What they cannot live with is learning about the delay by accident, after they have planned around the date you gave them. A missed date that you named early reads as a change of plans. A missed date that nobody mentioned reads as a broken promise, and it spreads to the rest of your relationship with that customer.

The fix is simple to describe and harder to do: tell the people who were promised the feature before the promised date passes, say what changed, and tell them when they will hear from you next. That is the whole message. The rest of this article is about the details that make it land well.

Tell them early and specific

Early means before the date, not on it. The day you realize the date is at risk is the day to write. Waiting until the date passes gives the customer one more day of planning around a promise you already know is shaky.

Specific means naming the feature, the reason in plain words, and what the customer can still rely on. "The CSV import is delayed" is vague. "The CSV import we mentioned for March is now planned for the next release, because the file parser needs more testing with large files" tells the reader what you know. The reason does not need to be detailed, but it should be real.

Say what changed, what is still true and what happens next

A good delay message has three parts. First, what changed: the new state of the work, in one or two sentences. Second, what is still true: anything the customer can count on, such as a workaround, a partial release or the fact that the work has started. Third, what happens next: when they will hear from you again, which is a commitment you can keep.

The third part is the one most teams get wrong. If you say "I will update you soon", the customer waits and wonders. If you say "I will write again on the first Monday of next month, even if nothing has changed", you give them a time they can plan around, and you keep the promise even when the news is not new.

Template for the people who asked

Send this to each person who was promised the feature, from your own email. Replace the bracketed parts with the facts.

Hi Lena, I wanted you to hear this from me before March. The CSV import we talked about is now planned for the next release, not this one. The parser needs more testing with large files, and I do not want to ship it before it handles them well. In the meantime, you can import in smaller batches of up to 200 rows, which works today. I will write again on the first Monday of February, even if nothing has changed, so you are not waiting on me.

The message names the change, gives a workaround that is true today and commits to the next update. It does not apologize seventeen times, and it does not promise the feature for a date that might move again.

Give a new date only when you are confident

A new date feels like a fix, but a second missed date does more damage than the first. Give one only when the work is nearly finished and the risk is low. If you are not sure, give a window of time you can defend, or no date at all, and promise an update instead.

When you do give a date, say what it depends on. "We expect the import to be ready for testing by the end of February, provided the parser tests pass" is more honest than a bare date, and it tells the customer what would change it.

What not to say in a delay message

Do say	Do not say
The feature is now planned for the next release	Sorry for any inconvenience this may cause
Here is the workaround that works today	Just hang tight, it is coming soon
I will write again on this date	We are working around the clock on it
The part that changed is the parser testing	The engineers messed up the estimate
I will tell you when it ships	You will definitely have it by next month

Be careful with blame, even when the cause is outside your control. A supplier, a platform change or a dependency can all be the reason, but the customer is buying from you, so the message should be about what you are doing, not who you are blaming.

Keep the trust you have built

Trust comes from being consistent more than from being perfect. A customer who gets an early, honest delay notice usually stays, and sometimes becomes a better source of feedback because they trust you to tell the truth. A customer who hears nothing and then finds out from a changelog is more likely to leave and tell others why.

After the feature ships, send a short follow-up to the same people. Thank them for waiting, say what is now live, and invite them to check it. The steps for that message are in how to tell customers their request shipped.

Logging a delay in Escuta Produto

Each feedback item in Escuta Produto has a status: new, planned, in progress, done or closed. When a promised feature slips, move the item from planned to in progress only if work has actually started, and add an internal note with the new plan and the date you will next update the customer. Notes are private, so write them for the team: the old promise, the reason, the new commitment and the date.

Find the people who were promised the feature by searching the inbox for the words they used when they asked, and check each item before you write. Escuta Produto does not send automatic emails, so each update is a reply you write from your own address. For the status meanings and how to move items through them, see how to design a feedback status workflow. If you are not sure whether the request was a promise or only a note, the wording in how to say no to a feature request helps you separate the two. Setup details for the feedback form are in the widget docs.