An ecommerce project becomes much easier to plan when the brief explains how the business sells, not just how the new website should look. The useful detail sits in the products, customers, payments, delivery rules and day-to-day work behind each order.
A finished specification is not required before speaking to a developer. A short, practical outline is enough to begin a useful conversation about ecommerce website development. The questions below help turn that outline into a brief that can be scoped properly.
Start with the business and the customer
Begin with a plain-English description of the business, what it sells and who normally buys from it. Explain whether the store is for consumers, trade customers or both, and whether customers already know exactly what they need or require help comparing options.
It also helps to state what the website needs to improve. That might be clearer product information, simpler catalogue management, support for a new range or a better connection between online orders and the way they are fulfilled.
Define the product catalogue
The catalogue usually shapes more of the build than the visual style. Give an approximate number of products and explain how they are organised.
Useful details include:
- The main product categories and any subcategories.
- Variants such as size, colour, finish, pack quantity or specification.
- Whether different variants have their own stock, images, product codes or availability.
- Products that are made to order, personalised, bundled or only available by enquiry.
- Any compatibility rules or filters customers use to find the right item.
- Whether the catalogue already exists in another platform, spreadsheet or stock system.
A small sample of representative products is often more useful than a long feature list. Include one simple product and one of the most complicated products so that the range of requirements is visible.
List the information each product needs
Decide what a customer must understand before ordering. Product names and descriptions are only the beginning. Depending on the catalogue, the store may also need dimensions, materials, technical specifications, care information, compatibility, lead times, downloads or several image types.
Record which information already exists, where it is stored and who will prepare anything missing. This separates the website build from the content work and makes it easier to plan product setup and migration.
Google documents specific product data that can be supplied through structured data, including product identity, offers, availability and variants. The exact fields needed will depend on the catalogue, but thinking about consistent product information early supports both customers and the technical setup.
Describe the buying journey
Explain the route a customer should take from discovering a product to receiving an order confirmation. Include anything that changes the ordinary add-to-basket and checkout journey.
Questions worth answering include:
- Can every product be purchased online, or do some require a quotation?
- Can customers order as guests, create an account or use either option?
- Are discount codes, gift cards, subscriptions or repeat orders genuinely required?
- Which payment methods must be supported?
- Does an order require additional information, uploaded files or customer approval?
- What should happen after payment, including confirmation emails and internal notifications?
Payment providers offer different checkout configurations and payment options. The brief does not need to prescribe the technical integration, but it should state the customer experience and business process that the payment stage must support.
Explain delivery, collection and fulfilment
Delivery rules can affect the catalogue, basket and checkout. Set out where the business delivers, how charges are calculated and whether any products have restrictions based on size, weight, location or availability.
If collection is offered, describe the locations, collection times and how the business confirms that an order is ready. If orders are fulfilled through a warehouse, supplier or delivery platform, include that system in the brief even if the exact integration has not yet been decided.
Cover customer accounts and trade requirements
A consumer account might only need order history and saved addresses. A trade customer may need approval, account-specific products, purchase orders, minimum quantities or different access to information. These are distinct workflows and should be described clearly.
Avoid adding accounts simply because ecommerce websites often have them. If guest checkout and email confirmations meet the real requirement, a simpler journey may be more appropriate.
Identify systems that need to connect
List the services involved in running the store today. These may include stock control, accounting, email marketing, customer service, fulfilment, analytics or an existing point-of-sale system.
For each connection, describe what information needs to move, in which direction and how quickly. It is also useful to identify which system remains the main source of truth for products, stock, customers and orders.
Plan existing content and search migration
If an existing ecommerce website is being replaced, include what needs to move. This may cover products, categories, customer accounts, order history, editorial content, reviews and files.
Provide a list of important existing page addresses and any Search Console or analytics information available to the business. That gives the migration a factual starting point and allows redirects, metadata and page structure to be considered before launch.
Describe how the store will be managed
The brief should identify who will add products, update stock information, process orders, handle refunds, change delivery rules and publish content. Different people may need different access.
Include any approval process and the level of training or documentation required. A storefront can be clear for customers while still creating unnecessary work behind the scenes, so the administrative workflow deserves the same attention as the public pages.
Set out testing and launch responsibilities
A useful launch plan covers the complete purchase journey rather than only checking that pages load. Representative products, variants, payments, delivery options, confirmation messages and order handling should all be tested.
The brief should also identify who signs off product information, who performs test orders, who controls the domain and which people need access to payment, analytics or other connected services.
A concise ecommerce website brief template
A first brief can fit into a short document with these headings:
- Business, customers and the reason for the project.
- Catalogue size, categories, variants and unusual product rules.
- Product information, imagery and content that already exists.
- Customer journey, accounts, basket, checkout and payment requirements.
- Delivery, collection, fulfilment and order-management process.
- Trade, wholesale or customer-specific requirements.
- Existing platforms, integrations and data to migrate.
- Internal users, permissions and day-to-day responsibilities.
- Testing, launch, training and ongoing support needs.
- Known timescales, decision-makers and any fixed operational constraints.
The aim is clarity, not technical completeness. A good brief gives the developer enough context to ask better questions and recommend an appropriate structure, platform and first release.
Ecommerce website development in Derby
CH Digital provides ecommerce development for businesses in Derby and elsewhere in the UK. The work starts with the real catalogue, customer journey and operation behind the store, then shapes the design and technology around those requirements.
Sources
https://developers.google.com/search/docs/appearance/structured-data/product-snippet
https://stripe.com/payments/checkout
https://woocommerce.com/posts/ecommerce-website-launch-checklist/