An E-commerce Development Brief Checklist for Retail Businesses

Start with the business outcome, then set out the requirements

A useful e-commerce development brief explains what the retail business wants to improve and what its online shop must support. It gives suppliers enough context to propose an approach that fits the business, rather than asking them to price a technical solution before they understand the need. Include the work customers and staff need to complete, the reason it matters and how you will recognise a successful result.

Use the brief as a working checklist, not just a description of the finished website. For each requirement, record its business reason, priority and evidence of completion. This helps suppliers distinguish essential capabilities from preferences and gives you a clearer basis for reviewing their proposals.

Give every item one of three priorities:

• Must-have: the shop or supporting process needs this to meet a business need.
• Desirable: it would be useful, but the business can proceed without it.
• Undecided: you need a supplier’s advice or an internal decision before confirming the requirement.

Keep non-essential improvements in a possible later phase rather than treating them as launch requirements. If something is undecided, state what needs to be resolved and who will make the decision. Suppliers can then explain assumptions, options and the effect of that open question on their proposal.

For each item, use this simple structure:

• Requirement: what the shop or process needs to do.
• Business reason: why it matters to customers or staff.
• Priority: must-have, desirable or undecided.
• Evidence of completion: what you would be able to see or do to confirm it is met.
• Open questions: decisions, dependencies or details still to settle.

Describe the business goals, customers and sales channels

Give suppliers the context behind the change before describing features. Explain what is not working, who the shop needs to serve and how online sales fit alongside the rest of the business. Use examples from your own processes or evidence where available, and mark plans that still need agreement as undecided.

• Reason for the change: Describe the specific friction or limitation in the current shop or sales process. For example, identify a task staff handle manually, a point where customers struggle, or a sales process the current setup cannot support. Say who is affected and what happens as a result; avoid assuming the solution before suppliers have assessed the need.
• Business outcomes: State what the project should make possible or easier, such as managing catalogue changes more effectively or supporting a new way of selling. Keep these as intended outcomes, not promised results. Where you have relevant evidence, such as recurring customer enquiries or internal process notes, include it and explain what it shows.
• Customer groups: Name the main audiences and what each needs to do on the shop. A retailer serving both consumers and trade buyers could explain whether trade customers need different product information, pricing, ordering steps or account handling. Note any differences that suppliers should account for, and distinguish confirmed needs from assumptions.
• Sales channels: List the channels you use now and those you are considering, such as the online shop, physical retail or other routes to market. Explain where orders, stock information and customer service are handled in each channel, and identify any processes currently managed separately. This helps suppliers understand whether the shop must fit an established way of working or support a change to it.
• Who sells the products: Clarify whether the business sells its own stock or wants independent third-party sellers to list and sell through the site. If that model is being considered, identify it clearly and scope marketplace requirements separately.
• Open decisions: Flag customer groups, channel plans or selling models that have not been agreed internally. Record who needs to decide and what information would help them settle it, rather than presenting an unresolved assumption as a firm requirement.

This context lets suppliers respond to the business problem, rather than simply price a list of features without understanding how the shop is expected to work.

Set out the catalogue, shopping journey and trading rules

Use this part of the brief to show how products are organised and how an order moves through the shop and your business. For each item, record the requirement, mark it must-have, desirable or undecided, and state how you would recognise that it has been met.

• Catalogue structure: Describe the kinds of products you sell and how customers should browse or search for them. Note categories, filters, product relationships and any distinction between items sold online and elsewhere. Acceptance check: a supplier can show how a representative product would be found.
• Product records and variations: List the information needed for each product, such as descriptions, images, dimensions, options, sizes, colours or bundles. Explain which details vary by product and what a shopper needs to choose before ordering. Identify who creates and updates product records, where information comes from and how often it changes. Include any review or approval steps, and what should happen when information is missing.
• Stock and availability: Explain how staff know whether an item can be sold, including any differences between stock held in different places or channels. Describe what shoppers should see when an item is unavailable, has limited availability or is expected later. Note who updates availability and how staff handle a mismatch between the shop and actual stock.
• Prices and customer groups: State whether prices or product access differ by customer group, channel or product type. Describe any trade or account-based journey, including what a customer must do before seeing prices or placing an order. If a rule is unresolved, mark it undecided rather than asking suppliers to guess.
• Shopping and checkout: Map the journey from finding an item to receiving an order confirmation. Record the information customers must provide, any account or guest-checkout needs, and where the journey differs for trade customers or other groups. Acceptance check: complete a sample journey for each important customer type using representative products.
• Payment, delivery and collection: List the payment choices the business needs to support, delivery options, how charges are determined, and whether collection is offered. Explain who handles fulfilment and what information they need from an order. Include changes after an order is placed, and how staff deal with failed payments, delivery problems, cancellations, returns and refunds.
• Promotions and exceptions: Describe discounts and offers in business terms, including eligibility, dates or other conditions, and whether offers can be combined or excluded from particular products or customers. Identify unusual cases that affect staff workflows. Acceptance check: apply an agreed example promotion to an eligible order and check that an excluded case is handled as intended.

Keep the brief focused on what the shop must do, not a preferred platform or technical design. Suppliers can propose an approach once they understand the rules and the cases they will need to demonstrate.

List the systems, integrations and data that must move

List each system that supports trading and explain the job it does, rather than assuming a supplier will know what needs to connect. For every requirement, record whether it is a must-have, desirable or undecided, how you would recognise it has been met, and who can answer questions about it.

• Inventory and product information: Name where product details, prices and stock levels are maintained. State whether the new shop should read or update these records, which system should be treated as the source of truth, and what should happen when stock changes or a product is amended.
• Orders, payments and fulfilment: List the services or staff processes that receive orders, take payment, prepare parcels, arrange collection or send dispatch updates. Describe what information needs to pass between them and who handles an order if a connection fails or a detail is missing.
• Accounting, customer and marketing tools: Identify any systems used for invoices, customer records, email communications or other routine work. Explain which records staff need to see or update, and whether the same information is currently entered in more than one place.
• Data to transfer: Note whether products, customer records, order history, images, written content or other records need to move. Include approximate quantities only if you have reliable information. Say who owns each dataset and who will confirm what should be transferred.
• Data quality and retention decisions: Flag duplicate products or customers, incomplete addresses, inconsistent product details and records that should not be carried forward. Name the person who will decide how to resolve or exclude them; do not leave the supplier to infer business policy from messy data.
• Access and ownership: Record who can provide access to each existing service, explain its current setup and approve changes. Mark unknown permissions, technical capabilities or supplier contacts as open questions to resolve before the proposal is finalised.
• Changeover and staff work: Describe any need for staff training, revised routines or a period in which old and new processes run alongside one another. Identify who will check orders and stock during the transition, and what must be ready before the new shop takes over.

Keep this at the level of business outcomes, not a prescribed technical design. If you do not know whether a system can connect or how its data can be exported, state that plainly and ask suppliers to identify what they need to investigate, the assumptions in their proposal and any decisions you must make.

Explain the design, content and reporting the shop needs

Give suppliers enough detail to understand the experience the shop should create, what material is ready to use and what the business needs to see after launch. Use examples where possible, and separate firm requirements from preferences.

• Brand and customer experience: Share brand guidance, existing design materials or examples of websites that illustrate what works for your customers. Explain what you want to preserve or change, and describe the experience customers should have when browsing, choosing products and completing an order. Note which devices and ways of navigating the shop matter to your customers.
• Content and assets: List what you can supply, such as product descriptions, photography, category copy, policies and brand files. For each type, note whether it is ready, needs review, needs creating or must be moved from the current shop. Identify who will provide, approve and maintain it. If product information is incomplete or inconsistent, describe the issue rather than assuming it will be resolved as part of the build.
• Accessibility and practical checks: Record any applicable accessibility or content requirements you have identified, and ask suppliers how they would address them and demonstrate the result. If you are unsure which requirements apply, seek advice from an appropriate adviser. State how you expect the shop to work for customers using different devices and any particular navigation needs relevant to your audience.
• Reporting and decisions: Name the people who will use shop information and the decisions they need to make. For example, specify whether they need to review orders, product performance or stock-related activity, and what views or reports would help them act. Distinguish information needed routinely from analysis that could remain in another system.
• Promotional content: Note whether staff need to create or update campaign landing pages, promotions or other shop content, and who will do this. Describe any approval steps or timing dependencies that affect the work, without turning the brief into a full marketing plan.

For each priority, add a practical way to recognise that the requirement has been met, such as reviewing supplied pages or checking that the intended staff can find the information they need. This gives suppliers a clearer basis for proposing and discussing the work.

Clarify security, operational ownership and ongoing support

Make clear who will run the shop after launch and what help you expect from the supplier. For each responsibility, record an owner, whether it is a must-have, desirable or undecided, and how you will recognise that the arrangement is in place.

• Day-to-day ownership: Name the person or role responsible for adding and updating products, checking orders, handling customer enquiries and publishing content. Note who can approve changes and who will cover these tasks when the usual owner is unavailable.
• Staff access: List the business systems staff need to use, which roles need access and who approves or changes that access. Ask the supplier to explain how the proposed setup supports these arrangements and what your business must manage itself.
• Maintenance and support: Ask suppliers to describe the ongoing maintenance and support they propose, including what is included, excluded and dependent on your staff or other providers. Record the support arrangements you need and how you would assess whether they meet them.
• Payment responsibilities: Identify the payment provider and ask which parties store, process or transmit cardholder data. Clarify responsibilities directly with the provider, and ask the supplier to explain how its proposed setup affects the retailer’s tasks and who is responsible for protecting account data.
• Security and other requirements: Note any security or sector requirements your business may need to meet. Identify what remains undecided and who will check it, such as the relevant provider or adviser, rather than assuming the supplier’s proposal settles it.

These points help expose gaps before proposals are compared: for example, a supplier may assume your staff will maintain product information, while your team expects that work to be included. Ask each supplier to state its assumptions and responsibilities plainly.

Set priorities, decision points and ways to accept the work

Prioritise the requirements and agree how the finished shop will be assessed before asking suppliers to propose a solution. This helps keep the initial scope clear while showing what may depend on decisions or work that is not yet complete.

• Set a priority for each requirement. Mark it must-have for the initial release, desirable, or undecided. If something can wait, note whether it belongs in a later phase or is simply an idea to review.
• Explain the constraint behind the priority. Record known budget parameters and timing constraints, including any business dates the work must accommodate. If these are not settled, say so rather than asking suppliers to assume them. Note dependencies, such as a decision on product rules or access to existing data.
• Name the people involved. Identify who will review proposals, make scope decisions, supply or approve content and product data, and sign off completed work. If one person holds several roles, make that clear. Suppliers can then identify where they need input and whose approval is required.
• Describe how you will recognise completion. Turn each important requirement into an observable check. For example, specify what a staff member should be able to do when updating a product, or what a customer should see when an item cannot be supplied. Use representative products, orders or situations where they help make the check clear.
• Record unresolved decisions. List questions that could change the scope, such as whether third-party sellers are included, who owns content, or what needs to be corrected in the data. State who will decide and what information is needed, if known.
• Ask suppliers to expose their assumptions. Request a clear account of what their proposal includes and excludes, what they need from your business or other providers, and who is responsible for each dependency. Ask them to identify any undecided requirement that affects their proposed approach.

Keep the priority, evidence of completion, owner and open question beside each requirement in the brief. That gives you a practical basis for discussing scope and reviewing whether a proposal has addressed the needs you have recorded.

Use the brief to request and compare proposals

Send each supplier the same brief and supporting material so their proposals respond to the same business needs. Invite them to raise questions before they recommend an approach; their questions can expose missing information or decisions your team still needs to make.

Use a consistent checklist to review every response:

• Scope: Does it address the requirements you marked must-have, and does it distinguish those from desirable items or work proposed for a later phase?
• Assumptions and exclusions: What has the supplier assumed about your catalogue, processes, content, existing systems or team availability? What work is excluded?
• Recommendations and trade-offs: Ask the supplier to separate what you requested from what they recommend, and explain the consequences of any alternative in plain language.
• Migration and integrations: Is it clear who is responsible for preparing, transferring and checking data, and for coordinating changes to connected systems?
• Acceptance: Does the proposal explain how you and the supplier will check that agreed requirements work in practice, and who will take part in those checks?
• Ongoing support: What support and maintenance are included, what is handled by other providers, and what responsibilities remain with your business?

Compare how each proposal covers the same must-haves, dependencies and unresolved questions, as well as what it defers. A headline figure alone cannot show whether proposals include the same work or rely on the same assumptions. Ask suppliers to make differences explicit before you compare them.

Before commissioning, review open decisions with the people who own the relevant parts of the business, such as trading, fulfilment and finance. Resolve what you can; for anything still undecided, record the assumption you have agreed to use and ask how a different choice could affect the proposal.

When you are ready to approach suppliers, request an e-commerce quote and share the same brief with each one.