A client brief can contain answers that are individually clear but inconsistent together. One response asks for a single page, another lists five page sections as separate deliverables, and a later note assumes a different launch arrangement. Choosing the most convenient interpretation does not resolve the conflict.
Keep the source answers visible, identify the decision they affect, and ask a focused clarification. Record the resulting requirement and any remaining assumption in a distinguishable brief version.
This guide provides an original conflict-resolution worksheet and fictional intake examples. It does not interpret contracts or determine decision authority. Use the client project brief template for the underlying structure.
Identify the brief edition under review
Record the project, brief identifier, current working edition, and purpose of the review. A draft for estimating may need different unresolved items made visible from a later production reference.
Keep prior versions identifiable. A later answer can clarify a question without making the earlier brief appear to have contained that information from the start.
Use the current source set deliberately. An old exported copy or outdated questionnaire can remain useful history while no longer being the working reference for the next decision.
Keep the original answers separate
Retain the relevant source wording or a reliable reference to it. Distinguish a client response, meeting note, studio interpretation, and later clarification.
A clean brief can summarize information, but the summary should not hide which source created a consequential assumption. Keep enough context to inspect the original question and answer.
If the wording was paraphrased, identify that role. Do not present a reconstructed sentence as an exact quotation or a proposed interpretation as an already confirmed requirement.
Name the actual conflict
Write the two statements and explain why their relationship needs clarification. A conflict may concern quantity, audience, delivery format, dependency, timing, or the intended meaning of a term.
Distinguish a contradiction from a difference in level. “One website” and “five pages” may fit together, while “one page” and “five separately delivered pages” may require another question.
Keep the next task focused on the consequential ambiguity. A long list of unrelated questions can make it harder for the responsible person to answer the issue that affects the estimate.
Use a requirements-conflict worksheet
Useful fields are brief reference, topic, source A, source B, exact or summarized wording, affected decision, alternative interpretations, clarification question, responsible contact, current answer, and next action.
Keep the interpretation and the source in separate fields. The worksheet should show where judgment entered the brief rather than making every conclusion appear to have come directly from the client.
Add a status such as open, clarified for the stated purpose, or awaiting another decision. These are proposed working labels, not a promise about an app’s exact interface.
Work through a fictional page-count conflict
Imagine brief B52 for a small website. An initial answer requests one page, while a later deliverable list names five separately navigable pages. The studio has not yet established which structure the client intends.
The worksheet preserves both sources and identifies the estimating question. A proposed clarification asks whether the five entries are sections within one page or separate pages, and which content belongs to each.
The studio does not silently choose the smaller scope to fit an estimate or the larger scope to appear thorough. It records the answer when established through the actual project process.
Ask for a decision in concrete terms
Use a question that names the relevant brief and the alternatives. Keep the wording neutral and focused on the information needed for the next stage.
For B52, a fictional question can say: “The first answer describes one page, while the later list describes five separate pages. Which structure should we use for the estimate? Please identify which content belongs in each page or section.”
This is example wording for review, not an instruction to send a message automatically. The responsible person should verify the context and choose the actual communication method.
Identify who can resolve the requirement
The intake contact may gather answers from several colleagues without deciding every underlying issue. Record the source person or role and the responsibility relevant to the question.
If a response says another person must confirm, keep that dependency visible. Do not turn the intake contact’s receipt acknowledgment into a decision they explicitly left open.
Use the actual project arrangement to establish authority and next steps. The brief record should describe that arrangement rather than invent it through a software field.
Keep timing proposals distinct from commitments
A desired launch date can be a planning input while its dependencies remain unresolved. Record the source and what needs to be established before relying on it.
If one answer assumes content is ready and another says it will arrive later, identify the dependency rather than moving a date to make the brief look consistent.
Keep a proposed schedule distinguishable from a confirmed arrangement under the actual process. This worksheet does not determine contractual commitments.
Record assumptions when an answer is still pending
A provisional estimate can use explicit assumptions if that fits the project process. State the purpose, assumed value, source limitation, and decision still needed.
Do not make the assumption disappear after it has been used. A later reviewer should be able to explain why the estimate or plan was prepared on that basis.
When the answer arrives, compare it with the assumption and record any resulting change. Preserve the earlier reference instead of making the new information appear timeless.
Check dependencies across fields
A page-count answer may affect content responsibility, review stages, navigation, and delivery timing. Identify the affected fields rather than correcting one sentence and leaving related assumptions unchanged.
Use a common issue reference where several rows depend on the same clarification. This helps the team understand that the changes are connected.
Do not automatically expand every part of the brief. Record the actual effect established by the answer and identify any separate decision still required.
Prepare a successor version deliberately
After clarification, create a distinguishable working version through the actual tool’s supported workflow. Keep the source answer and explanation connected to the revised requirement.
Use a readable version reference in the next handoff. A colleague should be able to identify the edition used for the estimate or production discussion.
For the difference between a reference version and an acknowledgment, see client receipt, review, and the project brief baseline.
Inspect the actual shared brief
Open the exported or shared copy intended for the recipient. Check the revised requirement, related fields, version reference, and visible open questions.
A correct working record can still be represented by an old attachment. Identify the current copy and what changed through the actual communication process.
Keep private preparation notes outside the intended copy where appropriate. Preserve required source context through an authorized access arrangement rather than exposing unrelated client material.
Test the resolved requirement with a colleague
Ask someone to explain the page structure, source answer, and remaining decision for B52 from the record. The explanation should not depend on the original writer reconstructing the discussion aloud.
If they still infer a different number of deliverables, improve the wording or field relationships. A short label can remain ambiguous even when a detailed source is available elsewhere.
Record what was checked and any limitation. This tests whether the brief is usable for its stated purpose; it does not certify every project requirement.
Complete the B52 clarification record
Suppose the responsible client contact confirms that the five listed entries are separate pages for the estimate. The studio records the response reference, the brief topic it resolves, and the exact purpose of the clarification. The original one-page answer remains identifiable as earlier input.
The next working brief states the five-page structure and maps the relevant content to each page. The estimate reference can then identify the revised edition rather than pointing to an old export whose quantity remains ambiguous. Any timing or content question still open is listed separately.
The handoff note explains what changed: page structure clarified for estimating, relevant source retained, related fields reviewed, and remaining questions assigned. This allows another colleague to use the current requirement without treating every topic in the brief as automatically settled by that one answer.
Check the actual portable copy after the update. The page list, summary, and any repeated deliverable count should agree. A corrected answer in one field can still leave an old quantity in the introductory paragraph or source note. Resolve those internal mismatches before the next stage relies on the document.
Check a content-responsibility conflict
In another fictional brief, one answer says the client will provide finished copy while a later note asks the studio to write the page text. The practical question is who supplies which content and what review or editing work is intended.
The worksheet keeps both source statements and asks a focused clarification. It can identify page by page whether the expected input is finished text, a rough draft, source notes, or another agreed starting point. Those labels describe the proposed workflow rather than a universal service package.
When an answer is established, record its scope and relevant dependencies. A decision about the home-page introduction should not automatically assign every other page’s copy. Keep the remaining fields open where the source did not answer them.
The estimate or plan can then state the actual entered assumption. If the responsibility changes later, preserve a distinguishable successor and review its effect through the project’s normal process. The source trail helps explain the change without turning the intake tool into a contract interpreter.
Write a compact resolution handoff
A useful filled entry can read: “B52 working edition 3; conflict between initial one-page response and later five-page list. Clarification source C7 identifies five separate pages for the estimate. Related content and navigation fields reviewed. Content delivery timing remains open with the named responsible contact. Earlier edition 2 retained as the prior reference.”
Keep actual source locations behind the summary and identify the cutoff. The recipient should be able to locate the answer, understand the requirement it resolves, and name the remaining question. This is more useful than a broad statement that the brief is now fully approved.
Read the summary back against the current brief before sharing it. A polished sentence should not omit an open dependency that affects the next decision. Where a question remains, keep its owner and next action visible in the same handoff arrangement.
Use recurring conflicts to improve future intake questions. If “pages” repeatedly means sections to one participant and separate deliverables to another, ask for a concrete structure earlier. That improvement follows from the observed ambiguity without claiming that any template can eliminate every misunderstanding.
Before closing the review, check the question list against the stated purpose of the next stage. Record which answers are established, which values remain assumptions, and who owns the remaining decisions. A brief can be useful with open questions when its limitations are visible. Keep that state in the actual handoff instead of relying on a readiness label or a remembered conversation to carry the nuance.
Use Brievra for a versioned intake record
Brievra supports local brief editing, source-response intake through optional Pro client links, gap review, version history, and Pro frozen evidence or Markdown export. Its current listing distinguishes version evidence from an electronic-signature service.
Use the actual project process to resolve conflicting requirements. Check current capabilities and plan details in the official Brievra App Store listing, and keep original answers and later decisions traceable.