Client feedback becomes difficult to manage when comments arrive in several places and nobody can see which version they refer to. An email asks for a different headline. A meeting introduces a new section. A message says “looks good,” but does not identify the version being approved.
A useful feedback tracker brings those inputs together without treating every comment as an instruction to start work.
1. Create one record for each actionable request
Create a database called Client Feedback. Use one record per request that can be clarified, decided or completed independently. Keep related comments together when they describe the same change.
“Make the page better” needs clarification. “Replace the homepage headline with the approved wording” is actionable.
| Property | Type | Purpose |
|---|---|---|
| Request | Title | Describe the change in one sentence |
| Project | Relation | Connect to the existing project |
| Source | URL or Text | Record where the feedback came from |
| Version | Text | Identify the deliverable being discussed |
| State | Select | Track the request’s current stage |
| Owner | Person | Assign the next action |
| Next Action | Text | Explain what needs to happen |
| Follow-up Date | Date | Set the next check when needed |
Use these State options: Needs clarification, Ready for decision, Accepted, In progress, Ready for review, Closed, Declined. These are suggested labels for your database, rather than a required Notion workflow.
For the Project relation, follow how to connect two databases in Notion. Connect feedback to existing projects instead of creating a second project list.
2. Preserve the original wording
Inside each feedback page, keep a short record:
- Original comment: what the client actually said.
- Working interpretation: what you understand the request to mean.
- Clarification needed: any question that must be answered before deciding.
- Decision: what was accepted, declined or deferred, and where that decision was recorded.
Keep interpretation separate from the original comment. Otherwise, a vague suggestion can gradually become an instruction that the client never gave. Use a source link where access permits. If you summarize a conversation, identify the conversation and record the summary as your note.
3. Check whether the request changes the agreed work
Before moving a request to Accepted, compare it with the agreed deliverable.
- Does it concern the version currently under review?
- Does it fit the agreed deliverable and revision process?
- Does it add a new output or dependency?
- Does it require a separate decision about timing or price?
| Feedback | Next step |
|---|---|
| Correct a typo in the current draft | Check and process within the existing workflow |
| Replace an image in the agreed homepage | Confirm the replacement and assess the revision |
| Add three pages that were not included | Record a potential scope change for a separate decision |
| “The design feels wrong” | Ask a specific clarification question |
| “Approved” without identifying the version | Confirm which deliverable and version were approved |
A tracker records the decision; it does not decide the commercial terms for you. Use the revision versus new scope guide when a request crosses that boundary.
4. Create three operational views
Clarification needed
Filter State to Needs clarification. Show Request, Project, Owner, Next Action and Follow-up Date. Every visible record should contain a question someone can send or resolve. Avoid leaving “ask client” as the entire next action.
A better next action is: “Ask whether more examples means replacing the two existing examples or adding a new section.”
Accepted work
Include State Accepted or In progress. This is the execution queue. Requests awaiting a decision should stay outside it.
Ready for review
Filter State to Ready for review. Show the version being submitted and what the reviewer needs to check. Do not close a request merely because you finished editing. Keep an All feedback view available for history and diagnosis.
5. Test the complete path with one example
Create a fictional request: “Replace the homepage introduction with a shorter version.” Record the current version, source comment and project.
If the requested wording is unclear, use Needs clarification. After clarification, move it to Ready for decision. Once the change is accepted, assign an owner and begin work.
When the updated version is ready, move the request to Ready for review and identify that version. Close it after recording the agreed outcome. For approval evidence, follow how to document client approval.
The test is successful when another person can identify the request, its current state and the next action without reading the whole message history.
When reviewers give incompatible instructions, use the conflicting feedback workflow to preserve both sources and obtain one clear decision.
Common mistakes
- Mixing several independent requests in one row. One unresolved question can make everything else look unfinished.
- Treating received feedback as accepted work. Capture first, clarify and decide, then execute.
- Using a date without an owner. A reminder cannot establish who will act.
- Closing a request without identifying the reviewed version. Keep the outcome connected to the actual deliverable.
Frequently asked questions
Should every client comment become a separate record?
No. Create a record when the comment requires clarification, a decision or work. Combine comments that describe the same request, while preserving their sources.
Can I keep the feedback in the project page instead?
Yes, for a small project with very little feedback. A related database becomes useful when you need to review requests across projects, assign owners or filter by state.
What is the difference between Accepted and Closed?
Accepted means the request has been agreed for execution. Closed means the request has reached its recorded outcome. Work can still remain between those stages.
How should I handle contradictory comments?
Keep both sources, identify the conflict and move the request to Needs clarification. Ask the appropriate decision-maker to resolve it before implementing competing instructions.
Does client feedback automatically count as a scope change?
No. Compare it with the agreed work. Some feedback fits the existing revision process; other requests require a separate scope decision.
Want this already built?
This guide shows you how to build this workflow yourself. For the wider client and project workflow, take a look at Freelancer CRM and compare its structure with how you work before adapting this process.