“Looks good” is hard to use later if nobody recorded which deliverable, version or part of the work it referred to.
This guide builds an approval register around the actual decision and its source. It is an operational record, rather than a substitute for the approval process agreed with your client.
1. Define what each record represents
Use one record for one approval decision about a defined deliverable version. If an email covers several independent decisions, separate them when their outcomes differ.
Reuse an existing decisions database if it already supports this. You do not need a separate register solely to follow the recipe.
2. Add the practical fields
| Property | Type | Meaning |
|---|---|---|
| Decision | Title | Specific decision being recorded |
| Project | Relation | Existing project connection |
| Deliverable Version | Text | Exact reviewed reference |
| Outcome | Select | Pending, Approved, Partial or Changes requested |
| Decision Date | Date | When the decision was provided |
| Source | URL | Original message or document reference |
In the page body, record who provided the decision, what it covers, any exclusions and the next action. If the source has no usable URL, preserve its reference in the body rather than inventing a link.
3. Separate receipt from approval
Receiving a message does not by itself establish an approved outcome. Read the actual instruction and identify the deliverable version.
| Message | Record or action |
|---|---|
| “Received, thanks” | Receipt; approval remains pending |
| “Homepage copy v3 approved as sent” | Check authority and scope, then record the explicit decision |
| “Layout approved, images still need work” | Partial outcome; record the unresolved image work |
| “Looks good” with no version context | Clarify the reference before using it as direction |
These are workflow examples, not conclusions about a particular client’s agreement. Use your agreed process to identify who can authorize the decision.
4. Preserve the exact reference
- Open the original response.
- Identify the deliverable and version reviewed.
- Record the relevant decision accurately.
- Link the original source where possible.
- State approved elements and exclusions separately.
- Record the next action for the project.
Use the document version guide when several drafts have similar filenames. A live document can change while its URL stays the same.
5. Create a decision review view
Add a Table view called Approval needs review. Include outcomes Pending and Partial. Show Project, Deliverable Version, Outcome and Source.
Keep a separate check for empty Outcome values so incomplete records do not fall outside your review. A blank is not the same as an explicit pending decision.
For a partial approval, identify exactly what still needs a response. Use the follow-up queue to assign the next check rather than repeatedly changing the decision date.
6. Process the next revision deliberately
If the client requests revisions, record the new reviewed version separately when a new decision arrives. Preserve the earlier decision and its reference.
Do not turn approval of v2 into apparent approval of v3 by replacing the version label in the old record.
If the response introduces a new deliverable or changes agreed work, review it through the scope-change tracker before treating it as authorized production work.
7. Test with fictional decisions
Create one pending decision, one explicit approval and one partial approval. Confirm only the pending and partial records appear in Approval needs review.
Then add a record with empty Outcome and verify it appears in your incomplete-record check. The register should expose uncertainty rather than hide it behind a tidy view.
Common mistakes
- Treating receipt or politeness as an explicit decision.
- Recording an approval without the version it covers.
- Overwriting earlier approval records when a revision arrives.
- Calling the whole deliverable approved when the source excludes part of it.
Frequently asked questions
Is a received message automatically approval?
No. Inspect the decision, its context and the client’s agreed approval process.
How should partial approval be recorded?
Use a Partial outcome and state what is approved, what remains unresolved and the next clarification action.
Should Decision Date be a reminder date?
No. Keep the decision’s date separate from the date you plan to follow up.
Can I replace an old version label when a revision arrives?
Preserve the original decision and record the new version’s decision separately so their histories remain clear.
Does approval automatically authorize added scope?
Do not assume so. Review changes to agreed work through the separate scope and authorization process.
Explore the wider workflow
You can build this process in your existing workspace. For a broader client and project system, explore Freelancer CRM and compare its structure with your workflow.