E-Commerce Website Intake Checklist
Everything specific to selling online that a client needs to supply before an online store can launch, grouped by category, with the reason and timing for each.
What this checklist adds to a regular website build
An online store needs everything a normal website needs — logo, brand colors, homepage copy, domain access — plus a layer that only exists because the site takes payments and ships or fulfills orders. That layer is what this page covers. For the shared basics every website project needs, see the website project intake checklist; do not ask for those items twice.
As with any intake, sort items into what blocks the build from starting and what can follow with a placeholder. A missing product photo rarely stops development; a missing decision on which payment provider to integrate usually does, because it changes what code gets written. For how to actually get all of this out of a client — which collection method fits which situation — see the best way to request files from clients.
Products and catalogue
| Item | Why | Timing |
|---|---|---|
| Full product list with names and short descriptions | Shapes the catalogue structure before a single template is built. | Before kickoff |
| Categories and how they nest | Changes navigation and URL structure — guessing it means rebuilding both later. | Before kickoff |
| Variants (size, color, material) and their structure | A shirt in four sizes and three colors is one product with twelve variants, not twelve products — but only if built that way from the start. | Before kickoff |
| SKU or another unique product identifier | Without one, matching a spreadsheet row to a product across import rounds is guesswork by name alone. | Before kickoff |
| Product photos, per product or variant | The most commonly late item here — see launch blockers below. | Hero/bestsellers before kickoff, rest can come later |
| Full product count, even an estimate | Twenty products and two thousand need different import methods and catalogue features from day one. | Before kickoff |
Pricing and tax
| Item | Why | Timing |
|---|---|---|
| Price per product, gross or net of tax | Changes what's stored and displayed — confirm once, explicitly, rather than assume from spreadsheet formatting. | Before kickoff |
| VAT rate per product or category, if it varies | A single global rate breaks the moment one product line differs (books, food, digital goods are common exceptions). | Before kickoff |
| Currency and which countries are served | Determines whether multi-currency support is needed from launch — a bigger scope difference than it sounds. | Before kickoff |
| Discount and promotion rules, if planned at launch | A percentage code is simple; tiered bulk discounts are a different feature and need scoping, not mid-build discovery. | Can come later unless launch depends on it |
| Business registration details for invoices | The fields a valid invoice needs are set by the seller's own registration, not by design preference. | Before kickoff |
Media
| Item | Why | Timing |
|---|---|---|
| Product photos meeting a stated minimum resolution | State size and background style up front — mismatched phone photos are a common, avoidable revision round. | Key products before kickoff |
| Category or banner images for homepage/landing pages | Marketing images, distinct from catalogue photos, and often forgotten since they map to no database row. | Can come later |
| Size charts or fit guides, for apparel and similar goods | A support-ticket reducer, not a launch blocker — flag early so it isn't missed entirely. | Can come later |
| Product videos, if used | Confirm the platform actually supports video before treating it as a requirement. | Can come later |
Logistics and payments
| Item | Why | Timing |
|---|---|---|
| Payment methods to accept | Determines which gateway integration gets built — expensive to change after checkout code exists. | Before kickoff |
| Payment gateway account, verified and approved | Most gateways require the merchant's own verification before processing live payments — usually the slowest step on this list. | Before kickoff — see launch blockers |
| Shipping carriers and rate structure | Shapes checkout flow and, if rates are live, which carrier API gets integrated. | Before kickoff |
| Carrier account credentials, if rates or labels are fetched live | Needs the client's own carrier account, not a generic one — this is a credential from their existing supplier, not from you. | Before kickoff if live rates are in scope |
| Product weights and dimensions | Required for weight-based shipping; missing it for even a few products breaks checkout for those items. | Before kickoff |
| Fulfillment process (in-house, third-party warehouse, dropshipping) | Changes what happens after payment — notify a warehouse, generate a picking list, or just email the client. | Before kickoff |
| Return and exchange policy specifics | Feeds the legal return page and any in-store return-request feature. | Can come later, but before launch |
Legal and compliance
| Item | Why | Timing |
|---|---|---|
| Terms of service and a return/withdrawal policy | Consumer sales typically require a stated right of withdrawal — content from the client or their lawyer, not invented for them. | Can come later, but before launch |
| Privacy policy and cookie consent | A store collecting names, addresses, and payment data discloses more than a brochure site and needs consent for tracking. | Can come later, but before launch |
| Industry-specific restrictions (age-restricted or regulated goods) | Some categories carry disclosure or age-verification rules a generic template won't cover. | Before kickoff if the catalogue needs it |
| Complaints/claims process, where locally required | Often a separate published requirement from the general return policy. | Can come later, but before launch |
Accounts and access
| Item | Why | Timing |
|---|---|---|
| Domain, hosting, and DNS access | Launch-critical here specifically — a live store can't reschedule a domain cutover the way a brochure site can. | Before kickoff |
| Payment gateway API keys, once approved | A credential, and should never travel by email — see the note on secrets below. | Arrives once the gateway account clears verification |
| Shipping carrier account access, if integrated | Same handling as gateway keys: a credential, not a document. | Before kickoff if live shipping is in scope |
| ERP, accounting, or inventory-system access, if syncing is needed | Needs that system's API credentials and usually a contact who understands its data model. | Before kickoff if in scope, otherwise later |
| Marketplace or social-commerce accounts, if products list elsewhere | Relevant only if inventory or orders sync across channels — confirm scope first. | Can come later |
Marketing
| Item | Why | Timing |
|---|---|---|
| Analytics and ad-tracking IDs | Best wired in before launch so first sales are measured; a short gap causes no lasting damage. | Can come later |
| Email marketing or abandoned-cart tool details | Usually a post-launch connection, not a structural requirement. | Can come later |
| Planned launch promotions or discount codes | If a promotion is meant to go live at launch, its logic has to be built in, not bolted on the day before. | Before kickoff if planned |
The product-data spreadsheet
For any catalogue beyond a handful of items, product data usually arrives as a spreadsheet, and its quality decides how much manual cleanup the import needs. Ask the client to fill in a template with these columns rather than accepting whatever format they already have:
- SKU or unique ID — one per sellable variant, not one per product name
- Product name and short description
- Category, and subcategory if the catalogue nests
- Price, with a column noting gross or net of tax
- VAT rate, if it varies across the catalogue
- Variant attributes (size, color, material), one column per attribute, one row per variant
- Stock quantity
- Weight and dimensions, for shipping calculation
- Image filename(s), matched exactly to the files actually supplied
- Barcode/EAN, if the client's existing systems use one
Common mistakes to flag before import: variants crammed into one free-text field instead of one row each; prices silently mixing gross and net in the same column; image filenames that don't match what was actually uploaded, byte for byte; and a "category" column that's really a comma-separated list of tags — a different structure that needs modeling as one.
What tends to block e-shop launches
A handful of items above cause a disproportionate share of delays, and none are things the developer controls directly:
- Payment gateway verification. Most gateways require business documents and banking details, with approval taking days to weeks, entirely on the client's side. Start this on day one, not the week before launch.
- Tax and invoicing setup. Wrong VAT rates or invoice numbering are invisible during development and expensive to unwind once real orders have gone out.
- Product photography and copy for the full catalogue, not just the hero products used in mockups. Three good photos out of twenty products is not launch-ready.
- Legal pages drafted by the wrong person. A copied terms-of-service template is a liability, not a shortcut, and needs the client's own review.
- A live shipping or fulfillment integration with no working carrier account behind it. The code can be finished with nothing to connect to.
Starting these five on day one, rather than waiting for the "content" phase, moves the actual bottleneck earlier, while there's still time to absorb it.
Where BriefGate fits
Collecting this list is a bigger version of the problem BriefGate solves for any website project: someone has to ask for each item precisely, track what's come back across a longer, more mixed list than a brochure site needs, and keep payment and carrier credentials out of an inbox. An AI coding agent — or you, from the dashboard — can declare this checklist as typed items, with constraints like minimum photo resolution or a required VAT field built into the request, and let BriefGate's chase engine follow up on what's outstanding while the secrets vault handles gateway and carrier credentials with a one-time reveal instead of email. There is no pre-built e-commerce template yet — the built-in ones cover restaurant, advisor, and club sites — so an e-commerce intake is built from the item list above rather than a single preset.