Your client introduces a Customer Marketing Manager and a Content Lead. Both will review the case study. That still leaves an important question unanswered: which decisions can each person make?
This article starts after a project has an internal sponsor. It is about delivering the work, rather than finding a prospect. Use an approval map to agree who checks the customer account, who changes the narrative and who can release each asset. A role title is a starting point for a conversation, not confirmation of authority.
Split the decisions before naming people
A single “approver” field can hide several jobs. The writer needs someone to resolve editorial feedback. The customer needs an opportunity to check its statements. The client’s team may need another person to confirm that a number has adequate support or that a particular use has been permitted.
List those decisions separately before adding names. Ask the project sponsor to confirm the person responsible for each one and the basis for that assignment. If an answer is unknown, give that decision an owner to resolve it. Do not silently place every unassigned task with the most senior person in the meeting.
For an example of an explicit company process, GitLab’s public handbook describes maintained customer-reference records and final review through its program team. That is GitLab’s arrangement. Your client may organise the same decisions differently.
A completed approval map
Fictional exercise: a writer is producing one written customer story and one website quote card for a SaaS supplier. The people below are invented project participants. Their authority has been confirmed within this exercise; it is not inferred from their titles.
| Decision | Confirmed person | What they review | Completion record |
|---|---|---|---|
| Narrative and audience | Maya, Content Lead | Structure, language and relevance to the agreed audience | Consolidated editorial comments on draft 1 |
| Customer experience | Eli, customer operations manager | Their account of the rollout and the accuracy of attributed statements | Response against the numbered fact list |
| Quantitative claim | Noor, supplier analytics lead | Definition, period and supporting calculation | Evidence entry accepted or claim removed |
| Customer publication permission | Eli’s nominated communications contact | Named customer, logo, quotation and specified website uses | Written confirmation linked to final versions |
| Release of the two agreed assets | Maya, authorised by the project sponsor | Closed comments and completed permission checks | Release record naming both file versions |
The map does not make Eli responsible for approving a colleague’s quotation or grant Maya permission to use the customer logo. Those are separate decisions. Where a person cannot answer, the next action is to identify the right reviewer, not to interpret silence as agreement.
Give reviewers a precise question
“Please approve” often gives a reviewer too little context. Send the version, the decision required, the relevant section and a clear route for returning comments. Explain which changes remain open.
For Maya, the request might be: “Please consolidate the editorial comments on draft 1 against the agreed audience. The customer fact check follows that pass.” For the customer, it might be: “Please check the statements attributed to your team and confirm whether the two listed website uses can proceed.” These requests ask different people to do different work.
Agree review dates with the reviewers. A date written in your schedule is only a planning assumption until they accept it. If a reviewer is unavailable, record who may substitute and which decisions that substitute can make.
Keep contradictory comments visible
Suppose Content wants a simpler explanation while the customer says the simpler sentence changes the meaning. Record the conflict as a decision, rather than accepting whichever comment arrived last.
In the fictional project, the writer proposes two accurate alternatives and Maya chooses the clearer one after Eli confirms its factual meaning. The decision log records the wording and both checks. If no acceptable wording emerges, the writer removes or narrows the passage. Approval is not a reason to keep a statement that cannot be supported.
Nominate one person to consolidate the client’s feedback. This is a workflow choice for the project, not permission for that person to overrule the customer on its own experience. Use a claims and evidence register when a dispute concerns what the source actually supports.
Treat another asset as another release decision
A written story and a quote card are different objects, even when they share a sentence. The quote card can lose the qualification that was visible in the article. It may also use a logo or appear in a channel that was never discussed.
Add a row when the use changes. The new row should identify the asset, context, requested use and person who can confirm it. Link the relevant final file. Do not describe a general “customer approved” status as permission for every edit, advertisement, translation or future campaign.
Close the project with a readable release record
The final record can be short: asset names and versions, closed factual questions, editorial decision, confirmed uses and the person authorising release. Keep unresolved items marked as unresolved; publication should not depend on someone remembering a side conversation.
When a reviewer asks for a new deliverable after agreement, use the change-request log. When the work is a reuse of the interview, move into the sales-asset handoff. The approval map is doing its job when the next person knows exactly what can move forward and what still needs a decision.