What should an ecommerce creative-request form include?

01

What is the difference between a creative request and a creative brief?

A creative request asks whether work should happen; an executable creative brief tells the team how approved work will be approached and produced.

The request captures the business need, audience, channel, product or offer, requested outputs, timing, dependencies, and responsible decision-makers. It provides comparable information for deciding whether to reject, return, merge, route, or prioritize the submission.

The brief comes later. It defines the approved problem, strategic direction, message hierarchy, concept or test plan, production requirements, evidence and claims, references, and review process. Use the creative brief template after intake approval—not as a substitute for qualification.

This separation prevents every Slack message, meeting idea, or speculative due date from becoming committed production work. Asana describes intake as converting unstructured demand into structured information that can be evaluated against criteria such as impact, scope, resources, time, and staffing. Atlassian similarly recommends centralized request channels, request-specific forms, qualification, routing, and queues.

02

Which fields should every creative request contain?

Make the following core fields mandatory for every request, regardless of channel. The wording is copy-ready for a form builder.

Avoid one large “describe your request” box. Separate fields make submissions easier to compare and stop requesters from hiding missing decisions inside a paragraph.

For dates, collect both the public launch or send date and the earlier date on which approved creative must be ready. The distinction exposes review, trafficking, page-build, and scheduling time that would otherwise disappear from the request.

1. Request name: Use [channel] — [product or offer] — [campaign or launch].
2. Requester: Who submitted this and can clarify the details?
3. Business owner: Who owns the intended outcome and can approve scope trade-offs?
4. Final approver: Name one person rather than a department.
5. Request type: Paid ad; email or SMS; PDP or site; creator or UGC; organic social; adaptation or resize; other.
6. Related work: Is similar work planned or in progress? Select no, yes with links, or unsure.
7. Business outcome: Product launch; revenue or conversion; acquisition; retention; promotion; creative testing; compliance or correction; other.
8. Customer problem or opportunity: Explain in two or three sentences. “We need fresh creative” is not sufficient.
9. Intended audience: Name a segment, customer state, use case, or awareness level. Do not accept “everyone.”
10. Product and offer: Identify the product, collection, SKU, promotion, price terms, or offer involved.
11. Primary message and proof: State the main message and link the approved product facts, demonstrations, reviews, research, guarantees, or other evidence supporting it.
12. Customer action and destination: What should the customer do, and where will the asset send them?
13. Deliverables: List the quantity, format, placement, dimensions or aspect ratio, and required variants for every output.
14. Timing: Provide the launch or send date, creative-ready date, and reason the timing is fixed.
15. Cost of delay: What happens if the requested date moves?
16. Inputs: Link product photography, footage, copy, brand guidance, offer terms, approved claims, and relevant previous work.
17. Dependencies and blockers: Identify missing products, approvals, contracts, landing pages, inventory decisions, or other prerequisites.
18. Review path: Select every required reviewer, then name the final decision-maker.

03

Which conditional fields should ads and email requests include?

Use branching logic to show channel-specific questions only when they apply. Atlassian documents conditional form sections as a way to reveal relevant questions based on earlier responses.

For a paid-ad request, ask for the platform and campaign, campaign objective, placements, aspect ratios, quantities by format, product, offer, landing page, and whether the request is a new concept, iteration, or resize. If it is a test, require the hypothesis, variable being changed, control or previous asset, primary success metric, and links to prior reporting or recorded learnings.

Google advises advertisers to choose a success metric before running an experiment and, where possible, test one variable at a time. Its Performance Max asset groups can combine text, images, video, logos, and final URLs, so “make Google ads” is not an actionable specification. The exact campaign, asset types, orientations, quantities, and destination still need to be defined.

For an email or SMS request, ask whether it is a campaign or automated flow, the recipient segment, suppressions, send date and time, offer terms and expiration, primary CTA, destination, required content modules, personalization requirements, subject-line and preview-text variants, tracking owner, QA owner, and final send approver. Return the request if the audience, offer, or destination is missing; a designer should not have to infer those commercial decisions.

Media performance remains in the ad platform. ATIYO can preserve the creative context and user-recorded learnings associated with a request, iteration, and brief, but it does not connect to ad accounts, calculate ROAS, or independently know campaign performance.

04

Which conditional fields should PDP and creator requests include?

PDP requests need product-data and merchandising inputs; creator requests need relationship, rights, disclosure, delivery, and approval details.

For a PDP or ecommerce-site request, collect the product and SKU, page URL, launch date, inventory status, required page modules, approved product facts, specifications, variants, required product views, and image needs such as lifestyle, detail, scale, or demonstration shots. Also ask about claims requiring substantiation, feed dependencies, and ecommerce or legal approvers.

Separate clean product imagery from promotional campaign creative. Google Merchant Center says a primary product image should show the actual product and prohibits promotional elements such as calls to action, price information, watermarks, and free-shipping messaging. A request that says “use the launch graphics everywhere” may therefore need separate outputs.

For a creator or UGC request, collect the creator’s name and profile; whether the relationship is paid, gifted, affiliate, or organic; deliverables by platform; concept or talking points; prohibited statements; products being shipped; draft and publication dates; usage term, geography, and channels; paid-media or platform-specific authorization rights; raw-footage requirements; exclusivity; approval owner; contract; and usage-rights documentation.

Also require the disclosure language and applicable platform setting. The FTC says material relationships—including payment, free products, or discounts—should be disclosed clearly and conspicuously. For video endorsements, the disclosure should appear in the video rather than only in its description. TikTok also requires creators posting promotional content to activate its content-disclosure setting.

05

How should the team route each submission?

Run every submission through the same seven-stage gate: validate, return or reject, merge, route, prioritize, brief, and schedule.

One intake owner should manage the queue on a defined cadence. This prevents requesters from bypassing qualification by messaging individual designers. Atlassian’s service-request model likewise moves work through capture, assessment or approval, fulfillment or routing, and closure.

Priority should reflect business impact, deadline rigidity, strategic fit, effort, readiness, and required trade-offs. “The founder asked” and “ASAP” are not complete prioritization criteria. If urgent work will displace committed work, require the accountable owner to approve that trade-off explicitly.

1. Validate: Confirm that mandatory fields are complete, links work, inputs exist, and an owner and final approver are named.
2. Return or reject: Return incomplete requests for correction. Reject unsupported, out-of-scope, or unnecessary work with a recorded reason.
3. Merge: Link duplicates, adaptations, and channel extensions to one parent campaign or brief.
4. Route: Send resizes to production, net-new concepts to strategy and briefing, email to lifecycle, PDP work to ecommerce or merchandising, and creator work to partnerships plus compliance review.
5. Prioritize: Compare accepted submissions using the same criteria. Do not rank them only by arrival order or requester seniority.
6. Brief: Turn an accepted request into an executable brief with the approved strategy, requirements, evidence, and review path.
7. Schedule: Add the work to the roadmap and responsible person’s queue only after qualification. ATIYO can organize the roadmap, briefs, brand context, assets, iterations, and reusable learnings in one operating system.

06

Which rejection messages can the team copy?

Use specific, neutral rejection language that identifies what is missing and what the requester must do next.

A rejection should not become an argument about whether creative is helpful. It should show which admission criterion the request failed. Keep the submission in the intake queue until the missing information is supplied; do not quietly schedule it while waiting.

For a broader model covering what happens after acceptance, see Creative Workflow For Ecommerce. Accepted work can then be assigned and managed through a queue such as ATIYO’s My Queue view.

1. Missing scope: “This request has not entered the creative roadmap because the deliverables, quantities, or placements are incomplete. Update those fields and resubmit.”
2. Missing business case: “Fresh creative does not identify a customer problem or business outcome. Add the intended audience, desired outcome, and reason new work is required.”
3. Unsupported deadline: “The requested date has no stated launch, inventory, media, contract, or compliance dependency. Add the deadline rationale so it can be prioritized against committed work.”
4. Duplicate request: “This request overlaps with [linked request]. It has been merged so the team can manage one scope, brief, and approval path.”
5. Urgent trade-off: “Accepting this request requires moving committed work. Name the business owner approving the trade-off and identify which work should be displaced.”
6. Wrong destination: “This request does not require creative production. It has been routed to [team or owner] for resolution.”