Create a Marketing Request Brief That Prevents Missing Information

Executive summary

Marketing work often stalls before the first draft because the requester has supplied a deadline but not the offer details, audience, destination, approval owner or desired action. The designer or writer then becomes an investigator, chasing facts across chat messages. A short intake brief prevents avoidable back-and-forth while allowing genuinely urgent corrections to bypass the normal queue.

Allow 30–45 minutes to create the first template and 10 minutes to agree who reviews incomplete requests. This process suits small businesses where one or two people handle marketing alongside other duties.

Ask for decisions, not a long creative essay

An intake brief should help the team decide what to make, why it matters, what facts must be correct and who can approve it. Keep it short enough that busy staff will use it. For a routine request, collect:

• Business outcome: what should change after the work is published?
• Audience and context: who needs the message, and what do they already know?
• Core facts: offer, dates, price, eligibility, location, availability and exclusions.
• Required action: call, visit, enquire, book, read or another observable next step.
• Destination: the exact page, profile, form, phone number or other endpoint.
• Deadline and reason: the real external date, not simply “urgent.”
• Approver: the person authorised to verify facts and approve publication.
• Inputs: approved logo, photos, language versions, links and any mandatory wording.

Do not require every field for every task. A broken-link fix does not need the same brief as a new paid campaign. Mark fields as required, conditional or optional.

Make the outcome measurable enough to guide the work

“Make a creative post” describes an output, not the reason for creating it. Better outcomes include helping customers understand a new service, directing existing customers to a changed booking process, or answering a recurring pre-appointment question.

The outcome does not need a guaranteed numerical target. If reliable baseline data does not exist, say that the first release will establish a baseline. Avoid inventing a conversion target simply to make the brief look complete.

A useful test is whether two different people could read the brief and agree what a successful deliverable should contain. If not, ask the requester one clarifying question before assigning production time.

Use a readiness gate

Give requests three statuses:

• Ready: required facts, destination, owner and approval route are supplied.
• Waiting for input: one or more critical details are missing.
• Exception: a customer-impacting defect or time-critical operational update needs immediate triage.

The gate should not be a punishment. It protects the team from starting work that will likely be redone. When a request is waiting, reply with the exact missing items and the person who must supply them. Avoid vague messages such as “please provide more details.”

An exception still needs a minimum fact check. A wrong phone number can be urgent, but staff should confirm the correct number before changing public information.

Separate request ownership from approval authority

The requester explains the need and provides context. The production owner creates the asset. The subject-matter approver verifies claims, prices, availability and terms. The publisher checks the final public version. One person may perform several roles in a small business, but the responsibilities should remain clear.

If a request changes after approval—for example, the offer end date moves—record the change and send the affected facts back for reapproval. Do not assume that approval of the visual layout also approves a new price or eligibility rule.

Set realistic lead times

Estimate lead time from the complete workflow, including missing inputs, translation, approval, link testing and publication. A simple image with supplied copy may need a shorter lead time than a multilingual campaign involving several branches.

Publish a service expectation for routine requests and a separate route for urgent corrections. Do not promise a fixed turnaround unless the team has capacity to meet it. If the requester submits an incomplete brief close to the deadline, make the trade-off explicit: reduce scope, move the deadline or assign more resources.

Copyable intake template

request_id | requester | business outcome | audience | key facts/source | required action | destination | format/language | deadline/reason | approver | supplied assets | readiness status

Keep source documents linked rather than copying large blocks of unverified text into the brief. For important facts, name the person or system that confirms them.

Review the intake process after one month

Count how many requests arrive ready, how often work is paused for missing information, and which fields are most commonly absent. If nobody can answer a field or it never affects a decision, remove or simplify it. If the same missing fact repeatedly causes rework, make that field required for the relevant request type.

Do not measure success by how many fields the form contains. The objective is fewer preventable delays, not a longer form.

Conclusion and next steps

Start with the five or six fields that prevent the most rework, then add conditional questions for higher-risk work. Give incomplete requests a clear status and an actionable response. A good intake brief improves the quality of decisions before production begins while keeping the process lightweight enough for a small team.