- Which specific step causes people to give up on the task.
- What workaround people have quietly built instead.
- How often the problem comes up, not just that it does.
- What the fix would need to do, not just what's broken.
14 Jul 2026
Why Vendors Should Listen to the People Using Their Software
Most software feedback goes one way. A vendor releases something, customers work around whatever doesn't quite fit, and the gap between what was built and what people actually need quietly grows.
Connect with Clare ↗Follow the thread to see where the work starts, what changes, and how the evidence becomes useful.
How service improves, in four stages:
01 Notice02 Connect03 Change04 Prove
The difference between a complaint and useful feedback
"This doesn't work properly" is a complaint. It's understandable, but it doesn't give a product team much to act on.
Useful feedback looks different. It names the exact moment something breaks down, who it affects, and what the person was actually trying to do when it went wrong.
That level of detail is what turns a frustrated customer into a genuinely useful voice in a vendor's product roadmap.
Why this is worth the effort
It would be easier to just work around a tool's limitations quietly, the way most customers do. But every workaround is a hidden cost — time spent, mistakes introduced, and a tool that's technically working while actually getting in the way.
Raising it properly, with enough detail for a vendor to act on, fixes the problem for good instead of managing around it forever. It also tends to fix it for every other customer hitting the same wall, not just the one who spoke up.
What good vendor feedback requires
This only works if the relationship is treated as a genuine partnership rather than a one-way support ticket.
- Feedback needs to be specific enough to act on, not just a general frustration.
- It needs context — what you were trying to achieve, not just what broke.
- It needs to be followed up on, not raised once and forgotten.
- And it needs a vendor willing to actually listen, which not every vendor is.
When that relationship works, it shows up in small, practical ways — a feature that finally does what people needed, a workaround that quietly disappears, a roadmap that starts reflecting how the tool is actually used, not just how it was originally designed.
A question worth asking
The next time a tool in your business doesn't quite fit how your team actually works, is that feedback reaching the people who could fix it — or is everyone just quietly working around it instead?
Customer experience
When Everyone Cares About Customer Experience, But No One Fully Owns It
Caring about customer experience is not the same as owning it. Without clear ownership across departments, feedback gets discussed but not always followed through.
Read Briefing ↗Customer experienceSmall Assumptions That Break Customer Trust
The small assumptions engineers make during everyday IT support — about terminology, confirmations, and updates — quietly erode customer trust before it appears in any report.
Read Briefing ↗Customer experienceTrain For The Whole Customer Journey
Good onboarding helps staff understand how their actions affect other departments and the customer. Customers do not see internal boundaries; they experience one company.
Read Briefing ↗