Telling customers when their feedback led to a product revision

Tell customers about a completed revision after confirming what changed, which versions it affects and how feedback contributed. Give them enough version information to distinguish the earlier item from the revised one, plus a route to ask questions.

Verify the change before writing the message

Ask the product owner for the approved specification, the first affected batch or release date if known, and the checks completed. Compare the old and new versions.

State a customer-facing effect only if evidence supports it. Replacing a component does not establish that a failure can no longer occur, and a design aim is not a measured performance result.

Keep a record of what customers reported, what the team investigated, what changed and what remains uncertain. Feedback may contribute alongside inspection or supplier work; say so when that is the case, and do not credit one customer’s comment as the sole cause unless the record supports it.

Customer feedback impact on product revisions

Match the message to its audience

An affected customer with an open support case needs a direct update about that case and any available next steps. Owners of an earlier version may need to know whether the revision changes anything about their item. Potential buyers need an accurate description of the version currently sold.

Use confirmed version and batch or release information, where available, to distinguish earlier items from revised ones and select recipients. If you cannot confirm which version a customer has, avoid stating that their item is affected and give them a way to check with your team.

If an earlier product may have a safety issue, follow product-safety responsibilities and consult ACCC Product Safety; a revision announcement is not a substitute. Keep customer remedies separate from promotion.

The Australian Consumer Law (ACL) includes consumer guarantees. If goods do not meet a consumer guarantee, customers can ask for a refund, replacement or repair; do not imply that every earlier-version owner automatically qualifies for a particular remedy.

Say exactly what changed

State the earlier issue, the verified change, which version or batch receives it, and any relevant limit. Distinguish earlier units from revised ones, and tell customers with concerns about an earlier item how to have it reviewed.

A usable message can follow this pattern: Subject: [Product] update — revised version [version]. We changed [feature] in [version], introduced from [batch or release date], after customer feedback about [issue] contributed to our review. [Inspection or supplier work] also informed the decision, if applicable. If you have [earlier version], check [identifier or location] and contact [support route] with questions about your item.

Replace each bracketed detail with verified information, and remove any clause that does not apply. Avoid “fixed for good”, “customer approved” or a performance percentage unless suitable evidence supports it; the ACCC can require businesses to back up product or service claims.

Do not edit or suppress genuine negative reviews of the earlier version to make the revised one appear better. If public reviews cover different versions, make that context clear where the publishing system permits it.

Leave a route back

Include a support contact or case route in the update, and tell customers what version information to provide if they have it. Make the same version distinction clear wherever customers see the current product description.

Invite customers to report how the revision performs in use, and record new feedback against the correct batch where possible. Thank contributors without suggesting that all feedback was adopted or that a future change is guaranteed.