After release verification, Agent Chat is intended to help an agency turn messy client feedback into an organized revision queue, but it should not silently choose which stakeholder wins. The useful job is normalization: preserve every raw comment, attach it to the correct asset and version, translate it into a specific change, expose contradictions and scope questions, and prepare one change set for human approval.
That turns “make it pop,” a forwarded email, three call notes, and a contradictory executive message into work a designer or generator can actually execute. The account or creative owner still decides priority, scope, conflicts, and final acceptance.
Until that release is verified, use the template below in your current review system. After verification, use Oakgen Agent Chat to structure the feedback round, then execute only the change set a named human has confirmed.
Client feedback normalization template
Start with one row per atomic request. If a comment asks for a darker background and a different headline, split it into two rows so each change can be accepted, rejected, or tested independently.
| ID | Raw feedback + source | Asset | Version | Preserve | Change | Rationale | Conflict/question | Scope | Owner | Due state | Approval status | |---|---|---|---|---|---|---|---|---|---|---|---| | F-01 | “The product disappears.” — Maya, email, 10:12 | Meta static A | NB_META_A_v02_review | Headline, offer, logo position | Increase product/background separation | Product must read at feed size | Does this mean contrast, scale, or both? | In scope | Art director | Ready after clarification | Needs client answer | | F-02 | “Make the bottle much bigger.” — Sales lead, call note | Meta static A | NB_META_A_v02_review | Offer and approved label artwork | Test product at 115% scale | Sales wants stronger product recognition | Conflicts with F-03 | In scope | Account lead | Blocked by conflict | Unresolved | | F-03 | “More whitespace; keep it premium.” — Brand lead, document comment | Meta static A | NB_META_A_v02_review | Calm composition and typography | Protect negative space | Brand system favors restraint | Conflicts with F-02 if scale removes space | In scope | Client decision owner | Blocked by conflict | Unresolved | | F-04 | “Can we also make six TikTok videos?” — Founder, message | Meta static A | NB_META_A_v02_review | Current static scope | Add new video deliverables | New channel opportunity | New brief, format, and budget required | Out of scope | Account lead | Estimate required | Commercial decision | | F-05 | “Approved except use the legal line from last month.” — Maya, email | Landing hero | NB_WEB_HERO_v04_review | Composition and approved copy | Replace disclosure after source check | Align with prior campaign | Which exact legal line and is it still approved? | Pending evidence | Compliance owner | Waiting for source | Conditional, not final |
The required fields do different jobs:
- Raw feedback + source: protects meaning and accountability.
- Asset: identifies the deliverable, placement, or component.
- Version: identifies the exact baseline the comment concerns.
- Preserve: prevents an unrelated approved element from drifting.
- Change: converts taste language into an observable revision.
- Rationale: records the business or creative reason, not just the instruction.
- Conflict/question: prevents the agent from guessing through ambiguity.
- Scope: separates contracted revisions from new work.
- Owner: names the person responsible for the next decision or action.
- Due state: says whether the row is ready, blocked, estimating, producing, or reviewing.
- Approval status: distinguishes proposed, clarified, approved for revision, rejected, and final.
This template is portable. You can paste it into a project document, ticket system, or approved client-review tool. This article does not claim native ingestion from email, Slack, Drive, meeting tools, or a client portal in Oakgen.
Template CTA after release verification: Open Agent Chat and turn one feedback round into atomic rows, while keeping the original messages in your verified source system.
Who this is for
This workflow is for agency account leads, creative directors, designers, editors, and performance teams who ship multiple assets through multiple review rounds.
The problem is rarely a shortage of comments. It is the loss of relationship between:
- the comment and the person who made it;
- the comment and the version they saw;
- the requested change and the reason behind it;
- the revision and the approved brief;
- the approval and the exact file that later shipped.
An agent is useful because it can rapidly structure language. It is dangerous when the team lets that summary replace the source or lets the system settle commercial and creative disagreements without authority.
Collect feedback without pretending every channel is integrated
Choose one review record for the round. Feedback may originate in email, messages, calls, documents, presentation notes, or a proofing tool, but the working change set should live in one controlled place.
If Oakgen has not been verified to connect to a source natively, copy or upload only the material you are authorized to use through the demonstrated input path. Do not write “check our Slack and pull the latest comments” unless that integration exists and has been tested.
Use an intake block like this:
FEEDBACK ROUND Campaign: Northbank Q3 launch Decision owner: Maya Chen, Brand Director Agency owner: Ravi, Account Lead Baseline asset set: NB_Q3_v02_review Included sources:
- Client email, 27 July, 10:12 IST
- Review call notes, 27 July, 14:00 IST
- Annotated PDF, exported 27 July, 15:30 IST
Instruction: Preserve every raw comment and its source. Split compound comments into atomic requests. Do not resolve contradictions. Flag missing asset or version references. Mark apparent new deliverables as scope questions. Return the normalization table and a list of decisions needed.
This is where Agent Chat can remove clerical effort: parsing, grouping, deduplicating, and drafting clarifying questions. The agency remains responsible for confirming that the normalized rows faithfully represent what the client meant.
The broader AI chat workflow for marketing teams covers campaign planning and asset creation. This guide owns a narrower job: change control after feedback arrives.
Attach every comment to an asset and version
“Make the logo smaller” is not actionable if the campaign has four formats and the client reviewed an old PDF.
Require:
- campaign or project;
- asset ID and placement;
- baseline version;
- source preview or link in the approved system;
- stakeholder and timestamp.
If any field is missing, the due state is blocked—needs identification. The agent can propose likely matches, but it should not attach the comment silently.
A version naming pattern that survives a busy week
Use:
campaign_asset_direction_vNN_state
Examples:
NB_META_STATIC_A_v02_reviewNB_META_STATIC_A_v03_internalNB_META_STATIC_A_v04_client-reviewNB_META_STATIC_A_v05_approved
The state describes the file’s current role; it does not rewrite history. Never replace v03 with a different file while keeping the name. Never label something “final-final.” Never treat a chat’s conversational memory as your version-control system.
This draft does not claim that Oakgen provides formal version history, immutable approvals, or a client-accessible review record. Keep the authoritative label and approval in the agency’s verified production system unless release evidence proves otherwise.
Normalize taste language into testable changes
Clients often describe a reaction rather than a production instruction:
- “Make it pop.”
- “It feels cheap.”
- “Can it be more premium?”
- “The video is slow.”
- “This does not feel like us.”
Do not dismiss these comments. They carry useful information, but the team needs to locate the variable.
Normalize each into:
- Observed reaction: what the stakeholder experiences.
- Possible variable: contrast, hierarchy, scale, spacing, material, pacing, shot duration, music, voice, or copy.
- Preserve list: approved elements that must not move.
- Proposed test: one bounded change or two named alternatives.
- Acceptance criterion: what will be observably better.
Example:
| Raw comment | Weak translation | Useful normalized request | |---|---|---| | “Make it pop.” | Add brighter colors | Preserve brand palette and offer. Test A: raise product/background luminance contrast. Test B: increase product scale 10%. Review at feed size. | | “More premium.” | Add gold | Preserve product truth and minimal typography. Replace the busy texture with restrained directional light and more negative space. Avoid new luxury claims. | | “The video is slow.” | Speed it up | Preserve the opening claim and end card. Compare a cut with the hook inside the first beat and shorter pauses in shots 2–4. Keep voice intelligible. | | “Not our brand.” | Use brand style | Identify which approved brand principle is missing; block revision until the client names the relevant reference or the owner selects one. |
The agent should propose translations as questions, not convert subjective language into hidden assumptions.
Revision CTA: When the change is clear, use the AI image generator for a labelled visual test set. Keep layout, export, and exact-preservation claims limited to what your tested workflow supports.
Deduplicate without erasing stakeholder intent
Three people may make the same request in different words. Combine duplicates for execution, but keep every source attached.
For example:
- “The bottle is too small.”
- “I cannot tell what we sell.”
- “Can product recognition be stronger?”
These may normalize to one change: “Increase product prominence.” Yet the rationales differ. One is a visual observation; another is a communication failure. Preserving both helps the creative owner choose whether scale alone will solve the problem.
Use three deduplication labels:
- Exact duplicate: same asset, version, change, and rationale.
- Related request: same problem, different proposed solution.
- Separate request: shares language but affects a different asset, version, or goal.
Do not let deduplication turn five stakeholder concerns into “make product bigger” if the actual issue is unclear positioning.
Surface contradictory feedback instead of averaging it
Contradictions are decisions, not text-cleaning problems.
Common patterns include:
- bigger product versus more whitespace;
- more energetic versus more premium;
- shorter copy versus add three claims;
- follow the brand system versus mimic a competitor;
- approve this version versus revert to an earlier direction.
Use this conflict record:
| Field | Example | |---|---| | Conflict ID | C-03 | | Asset/version | NB_META_STATIC_A_v02_review | | Request A | Increase product scale substantially | | Request B | Protect negative space and restraint | | Stakeholders | Sales lead / Brand lead | | Shared goal | Improve recognition without losing premium positioning | | Decision needed | Which goal has priority, or should the team test two bounded variants? | | Decision owner | Maya Chen, Brand Director | | Status | Awaiting explicit decision |
The agent may identify a possible synthesis, such as increased contrast without increased scale. It must label that as an option, not a resolution.
If two authorized stakeholders disagree, ask the named decision owner. If there is no decision owner, the account lead should establish one before production resumes.
Silence, an expired deadline, “looks fine,” or approval of a different version does not approve the current change set. Record an explicit decision tied to the exact asset/version and any conditions.
Separate revisions from scope changes
An agent can flag likely scope creep by comparing feedback with the approved brief, deliverable list, revision allowance, and channel plan. It cannot decide the commercial response.
Use four scope states:
- In scope: corrects or refines an approved deliverable.
- Needs clarification: relationship to the brief is unclear.
- Out of scope: adds a deliverable, channel, concept direction, or production requirement.
- Commercial decision: agency owner must estimate, waive, defer, or decline.
“Change the headline” may be a revision. “Write a new landing page,” “add six videos,” or “create a second campaign for another audience” is likely new work.
Respond with options:
- include the request under the current scope;
- provide a change estimate;
- defer it to a later phase;
- decline it with the reason.
The account owner chooses. The agent drafts the client-facing explanation.
Confirm one change set before producing
After normalization, send the decision owner a concise review:
REVISION ROUND R3 — DECISION REQUEST Baseline: NB_Q3_v02_review
Ready for approval: 11 changes Needs client clarification: 3 Conflicts requiring decision: 2 Possible out-of-scope requests: 1 Rejected duplicates: 4 (sources retained)
Please decide:
- C-03: larger product or protected whitespace, or approve two tests?
- C-04: energetic pacing or calm premium pacing?
- S-01: six new TikTok videos — estimate, defer, or decline?
Approval requested: "Approve rows F-01, F-06–F-15 for revision against v02. Rows F-02–F-05 remain blocked. No new deliverables are approved."
This is the gate between interpretation and production. Ask the owner to approve row IDs, baseline, and scope. If the change set changes, issue a new revision-round label.
For agencies producing many ad options, the ad creative variation workflow explains how to structure a batch. Feedback normalization should happen before multiplying the revised direction.
Approval CTA after release verification: Record the bounded change set in Agent Chat, then re-confirm the exact generation payload and authoritative quote immediately before every paid call. Do not treat the chat record as immutable, payload-bound, or cumulative-budget enforcement until release evidence proves those controls.
Execute revisions in controlled passes
Do not apply 18 changes in one prompt and hope every approved element survives.
Group revisions by dependency:
- Truth and compliance: correct facts, claims, disclosures, source material.
- Structure: message hierarchy, scene order, composition, pacing.
- Creative direction: lighting, palette, environment, music, voice.
- Finishing: crops, captions, safe areas, filenames, exports.
Inside each pass:
- name the baseline version;
- state what to preserve;
- state what to change;
- state what to remove;
- name acceptance criteria;
- label every output as a candidate, not approved.
For image work, generate controlled candidates through the Oakgen image generator only after the source rights, product facts, and change set are confirmed. Generative edits can drift; compare the result against the baseline instead of claiming exact preservation.
For motion deliverables, the same normalization record can feed an AI video workflow, but changes to timing, sound, text, and visuals may need separate passes. This article does not claim that one conversation maintains perfect state across tools or media.
Label the output and run acceptance review
Every revised candidate should point back to:
- baseline version;
- approved feedback row IDs;
- production instruction;
- generated or edited output;
- reviewer;
- open defects;
- next state.
Use an acceptance table:
| Check | Question | Result | |---|---|---| | Change coverage | Were all approved rows addressed? | Pass / fail / partial | | Preserve coverage | Did protected elements remain acceptable? | Pass / fail / changed with approval | | Unrequested drift | Did anything else materially change? | None / describe | | Fact and claim check | Does final wording and imagery match approved evidence? | Pass / escalate | | Brand review | Does the result satisfy the stated brand rationale? | Pass / revise | | Format QA | Does it work in the intended placement? | Pass / revise | | Scope | Did production introduce new work? | No / review | | Approval | Is this exact version accepted for its named destination? | Explicit decision required |
Approval can be:
- approved for internal use;
- approved for client presentation;
- approved for a named organic placement;
- approved for a named paid placement;
- approved with conditions;
- rejected;
- superseded.
“Approved” without a destination can be too broad. A visual accepted for a client deck may not be approved as a live advertisement.
The version-approval workflow
Use this state flow for every round:
COLLECTED → NORMALIZED → BLOCKED/READY → CHANGE SET APPROVED → IN REVISION → INTERNAL REVIEW → CLIENT REVIEW → APPROVED FOR DESTINATION or RETURNED
Rules:
- A comment cannot become ready without an asset and baseline version.
- A conflict cannot become ready without a human decision.
- An out-of-scope request cannot enter production without a commercial decision.
- Revision starts only from the approved change set.
- A changed output receives a new version label.
- Client review refers to one exact version.
- Silence never advances an item to approved.
- Any post-approval change returns the asset to review.
This state model is the article’s recommended operating process. It is not a claim that Oakgen currently supplies formal version control, client collaboration, or an immutable approval history.
What I would do for a real feedback round: normalize every comment, then hold a ten-minute conflict pass with the account lead before anyone generates a revision. Pick the most representative asset, test the approved change set once, and send that exact labelled version back. If the client cannot approve the representative test, producing the remaining variants only creates a larger mess.
Common mistakes
Summarizing away the source
A clean bullet list is useless if nobody can recover the client’s wording or identify who asked. Keep raw feedback beside normalized feedback.
Mixing versions in one review
When stakeholders comment on different baselines, apparent contradictions may not be contradictions at all. Identify the version before debating the direction.
Solving ambiguity with more generation
Ten variants do not answer whether “premium” means quieter typography or darker photography. Ask the decision owner first.
Accepting every suggestion as in scope
Feedback is input, not automatic authorization. New deliverables and directions need a commercial decision.
Letting the loudest stakeholder become the owner
Authority should be explicit. A senior title, repeated message, or urgent tone does not necessarily override the named approver.
Calling an output final before destination approval
“Final” hides state. Name the version and the approved destination.
Claiming integrations or history that have not been tested
Do not promise that a system reads every client channel, remembers every round, or preserves a formal approval record without release evidence. Use controlled copy/paste or upload paths and your existing record system.
Frequently asked questions
Can AI combine feedback from several sources?
Yes, if the team supplies those sources through an authorized, tested path and preserves source mapping. The agent should normalize, not silently decide.
How do I prevent lost context?
Keep raw comment, stakeholder, channel, timestamp, asset, version, rationale, and acceptance criterion in the same row.
Who resolves contradictory comments?
The named agency owner coordinates with the authorized client decision-maker. The agent should surface the conflict and draft a precise decision question.
How should versions be named?
Use stable project, asset, direction, version, and state labels. Never overwrite a changed asset under the same version.
Can an agent detect scope creep?
It can compare requests with the supplied brief and flag likely additions. The account owner decides whether to include, estimate, defer, or decline them.
What counts as approval?
An explicit decision by an authorized person tied to the exact version, destination, scope, and conditions. Silence and approval of another version do not count.
Can clients collaborate directly inside Oakgen?
Do not assume that capability. Use your verified client-review channel unless a release-candidate test proves a native collaboration workflow.
Sources and further reading
- NIST AI RMF Playbook: Govern
- NIST AI RMF Playbook: Audit Log
- Workzone: Client Approval Process for Agencies
- Sagely: Client Feedback Handbook
- Cadenus: Client Approval Workflow
The workflow above is an editorial operating model. Before publishing product-specific claims, complete the required release-candidate exercise with multiple source formats, conflict cases, scope questions, labelled outputs, and an explicit sign-off record.
Test One Approved Revision
Take the clearest bounded change, generate one labelled visual test, and send that exact version back through client review.



