The difficult step after customer research is deciding what the evidence permits you to say. A customer might describe a frustrating task in vivid language, while your product addresses only part of it. Copying the complaint into an ad can accidentally imply that you solve the whole problem. A useful translation process keeps the original observation, your interpretation and the proposed promise visible together.
This article covers that editorial translation. It assumes you already have interview notes. If you are still gathering them, start with the customer interview questions. The output here is a defensible message brief, not a targeting setting or a prediction about ad delivery.
Start with one recorded incident
Choose a short passage about a specific event. Avoid lifting the most dramatic sentence from an interview without its surrounding qualification. “We were completely stuck” might describe one afternoon before an internal workaround, rather than a persistent problem that justifies switching suppliers.
Keep enough context to understand who was acting, what task they attempted and why the outcome mattered. Remove personal identifiers that the writer does not need. Retain a reference to the original record so a reviewer can check whether the paraphrase is fair.
A fictional interview with a design studio might contain this observation: “When a client asks which file is approved, I search the email thread before answering. The team knows the folder structure, but the client does not.” That passage contains at least two possible problems: locating the approval and communicating status externally. Do not merge them automatically.
Separate observation from interpretation
Use three columns before drafting a headline:
| Original evidence | Working interpretation | What remains to check |
|---|---|---|
| Coordinator searches email for approval | Approval status is not readily visible in the current workflow | Whether the proposed product records explicit approval |
| Client does not know the folder structure | Internal organisation does not explain status to outsiders | Whether clients can access a suitable view |
| Team already understands the folders | Reorganising all files may be unnecessary | Whether a smaller workflow change addresses the task |
This format prevents a leap from “searches email” to “needs an all-in-one platform.” The broader claim may be commercially attractive, but the evidence has not established it. You might discover that a modest approval feature is relevant while the rest of your platform distracts from the decision.
Connect the need to an actual capability
Ask a person who knows the offer to identify the capability that addresses each interpretation. Request a concrete demonstration or current specification. A roadmap item, sales aspiration or workaround requiring unmentioned services is not the same as an available feature.
In the example, suppose the product has a shared approval status and an external review link. The defensible message could explain those capabilities. “Keep client approval status visible” may be supportable if the workflow does that. “Never chase a client again” reaches beyond the capability because client behaviour remains outside the tool’s control.
Record dependencies beside the draft. Perhaps external links require a particular plan, or approval status appears only after someone completes a review action. Those details affect how much the ad can imply. If a qualification makes the short copy confusing, choose a narrower promise that does not require the missing explanation.
Test another explanation before choosing the message
The same interview passage can lead to different messages. In the fictional studio example, the central need could be finding a decision, showing the client the correct file, or preventing work on the wrong version. The observation does not yet establish which need should lead the ad. A verified product statement can still be the wrong response to the interview.
Read the surrounding account and write two possible interpretations. For “approval is difficult to find”, look for details about the coordinator’s search and the missing information. For “the client needs to understand status”, look at what the client actually asked. If the client had already received a clear decision but could not find the file, making status more visible may not address the problem.
| Possible reading of the interview | Supporting detail to look for | Implication for the message |
|---|---|---|
| The team loses track of decisions | Several people search for the same approval | Describe a shared place for recorded status |
| The client cannot find the correct version | The client receives incorrect or competing file links | Describe how the intended version is shared |
| Internal responsibility is unclear | Nobody knows who should request approval | Investigate ownership before drafting copy |
This table continues the fictional example. Choose the reading supported by the material, rather than the one that fits a preferred headline. If the record is insufficient, flag the question for follow-up and choose a narrower message. An uncertain motive does not become established simply because the sentence sounds natural.
This check differs from ordinary ad-copy fact-checking. Fact-checking asks whether the capability exists. Here you first ask whether that particular capability responds to the situation the participant described.
Separate observation from promise
- Observation
The coordinator searches an email thread for the approved version.
- Interpretation
Approval status seems difficult to find. This is an inference.
- Alternative explanation
Is the missing piece the decision, the correct file or an owner? Return to the record.
Checkpoint - Supported message
Describe visible status only after checking the capability.
Preserve the customer’s constraint
A message becomes less useful when editing removes the condition that made the need distinctive. If a participant needs external review without creating another account, “easy collaboration” loses the central requirement. If the product does require an account, the research cannot justify advertising it as the solution to that constraint.
Keep constraints in the brief even when they do not fit in the headline. The copywriter can then select a suitable audience situation or decide that a different feature deserves the lead. This is also where you separate two briefs if their requirements conflict.
When using the message brief to write context hints, describe supported use cases rather than treating interview phrases as guaranteed triggers. OpenAI’s documentation identifies hints as contextual information, not exact-match keywords. Official targeting documentation
Finish with a reviewable handoff
The handoff should contain the chosen message, the evidence reference, the verified capability, essential conditions and an unresolved-question list. Give the reviewer a decision to make. “Can we substantiate the external approval view on this plan?” is more useful than “Does this sound good?”
Retain rejected wording with a short reason in the working document. This stops the same unsupported promise returning during a later edit. Do not publish private interview excerpts as social proof merely because they supported the internal reasoning.
Your finished brief should make it possible for another person to reconstruct the claim without attending the interview. For a broader inventory of promises, use a claim evidence matrix. That matrix tracks the advertising claims; this workflow explains how a particular customer observation becomes one of them.
Place the resulting message brief in context with the targeting and relevance overview. A fairly interpreted interview informs campaign planning, but does not by itself establish every situation the offer should address.
Sources and scope
Turning a particular customer observation into one verifiable message in a ChatGPT ad.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.