Your client sends a Slack message at 4pm on a Friday: "The thing on the dashboard is doing something weird when I click the export button." That's the entire bug report. No screenshot, no browser info, no steps to reproduce. Just vibes.
You ask a few follow-up questions. Some get answered Monday morning. The developer who built the export feature is now on a different project. The project manager logs it as a task in ClickUp with the description "Fix export bug" and moves on.
Three weeks later, the same bug reappears. Nobody remembers that it was reported before. The cycle repeats.
This is not a tooling problem. It is a process gap, and it exists because there is no structured path between "client noticed something" and "this is now a verified, repeatable test case."
Where feedback actually lives
In most agency workflows, client feedback ends up scattered across at least four different systems:
Slack or Teams messages are the most common. They are fast and informal, which is why clients prefer them. But they are also ephemeral. Important context gets buried under other conversations within hours. Searching for "that thing Sarah mentioned about the login page" three weeks later is a losing game.
Email threads contain the more formal feedback, usually wrapped in three layers of forwarding and 100MB of email signatures, with conflicting opinions from different stakeholders. The actual issue is in paragraph two of the third reply, surrounded by pleasantries and scheduling logistics. Half the time it arrives as a screenshot with no steps to reproduce and no device details.
Meeting notes capture verbal feedback, if someone is taking notes. The quality varies wildly. Sometimes you get detailed acceptance criteria. Sometimes you get "Client wants changes to the user flow" with no further detail. Or the classic: "It doesn't pop."
Task comments in Jira, ClickUp, or Asana contain inline feedback that was added after the original task was created. These are easy to miss because they arrive as notifications that get cleared without reading.
The result is that client feedback exists, but it is distributed across systems in unstructured formats that resist any kind of automated processing or systematic review.
The gap between feedback and tests
Turning that scattered feedback into actionable test cases requires someone to do several things that are surprisingly time-consuming:
First, they need to interpret the feedback. "The thing is weird" needs to be decoded into "the CSV export generates a file with incorrect column headers when the user has custom fields enabled." That translation requires context about the feature, the client's usage patterns, and the technical implementation.
Second, they need to check whether a test already exists. If the team has any kind of test suite, there might be a related test case that just needs updating. Or there might not be. Finding out means searching through whatever system the tests live in, which is often a different tool from where the feedback arrived.
Third, they need to write the test case in a format that is useful. Not just "export should work" but a step-by-step procedure with preconditions, actions, expected results, and environment details. This is the part that takes the most time and gets skipped the most often.
Finally, they need to link the test to the feature it covers, so that when the feature changes in future, the test surfaces as potentially affected.
Most of the time, none of this happens. The feedback gets actioned as a one-off fix. The developer patches the issue, marks the task as done, and moves on. No test is created. No systematic protection is added. The next time the same area of the codebase is touched, the same type of bug can reappear.
Building the bridge
The key insight is that feedback and test cases are not fundamentally different things. A piece of client feedback is an informal observation about expected behaviour. A test case is a formal specification of expected behaviour. The difference is structure, not substance.
What you need is a workflow that makes it natural to promote feedback into structured tests. Not as a separate activity that someone has to remember to do, but as part of the normal process of responding to feedback.
When a client reports that the export is broken, the fix should produce two things: the code change that resolves the issue, and a test case that verifies the fix and prevents regression. The test case should be linked to the feature it covers (data export), tagged with the environment details (custom fields enabled), and written in enough detail that anyone, including an AI agent, can execute it later.
When features are structured as proper specifications with acceptance criteria, the AI can help draft test cases from the feedback. It can look at the feature spec, understand what the expected behaviour is, compare that to what the client reported, and produce a test case that covers the gap. Not perfectly, and not without human review, but enough to eliminate the blank-page problem that stops most teams from writing tests at all.
Compounding returns
The real value shows up over time. Every piece of feedback that becomes a test case adds to a growing suite that represents what actually matters to the client. Not theoretical coverage of every code path, but practical coverage of the things real users have actually encountered.
After three months of this approach, your test suite is not a theoretical exercise. It is a living record of every issue the client has raised, every edge case that has appeared in production, and every assumption that turned out to be wrong. Running it before a release gives you genuine confidence, because it tests exactly the things that have broken before.
And when you hand the client a shareable test report showing 47 test cases all passing, including the specific scenarios they reported as bugs last quarter, the conversation shifts. You are not just delivering features. You are demonstrating that you are protecting their investment.
This is the workflow we built Specsource around. Tests are tied directly to feature specs that carry the business context, acceptance criteria, and user stories that explain what you are actually building. When a client reports something, the path from their feedback to a structured test case is short enough that it actually gets followed. The AI can draft the test from the feature spec, a human reviews it, and the test lives alongside the feature it covers from that point forward.
And when you hand the client a shareable report showing 47 test cases all passing, including the specific scenarios they reported as bugs last quarter, the conversation shifts. You are not just delivering features. You are demonstrating that you are protecting their investment.
That is how you turn scattered feedback into a testing culture. Not by mandating process, but by making the bridge between "client said something" and "we have a test for that" short enough that people actually cross it.