How to write an ecommerce website brief that covers the whole order

1. Describe the trading model and the first release

Begin with what you sell, who buys it and how the order is fulfilled. Physical products, items made to order and downloadable goods involve different decisions. A business selling to consumers and trade customers may need distinct account and pricing rules. State those differences directly. A long list of desired features is difficult to interpret without the trading model behind it.

Explain the current process before describing the future one. Orders may arrive through a shop, telephone calls, emailed spreadsheets or sales representatives. Note where information is entered again and where staff use judgement. An ecommerce website can change that workflow, but the brief must identify which decisions should become rules and which should remain a staff responsibility.

Separate the first release from later ambitions. If trade ordering is essential at launch, it belongs in the core scope. If overseas selling is an untested idea, record it as a future consideration rather than asking suppliers to price every possible territory. Include the business reasons for the sequence, such as staff capacity or a need to clean product data before expanding the catalogue.

When comparing suppliers for ecommerce web design in Belfast, give each shortlisted team the same brief so its proposal addresses the same trading requirements. The same applies when looking more widely for ecommerce website development in Northern Ireland. Being nearby may make meetings easier, but the proposal still needs to explain how the store will handle your catalogue, orders and staff responsibilities. Use those details to judge whether the team understands how your business sells.

Name the decision maker and the people responsible for product data, finance, dispatch and customer service. These colleagues may spot different risks. A checkout can look complete to a designer while leaving the warehouse without a usable picking list. Getting advice from the people handling orders early is usually easier than discovering the missing requirement during training.

• State the customer types, products and fulfilment model.
• Describe current order entry and manual decisions.
• List essentials for the first release and later possibilities separately.
• Name an internal owner for each part of the ordering process.

2. Supply representative catalogue data

A product count is useful, but it does not explain catalogue complexity. Include examples of a straightforward item, a variant product and the most awkward product you sell. For each, supply the identifier, description, images, options, price, stock behaviour and delivery implications. A store with a modest number of products can still require substantial work if the rules differ between them.

Explain what an option changes. A colour may change only the image, while pack size may change weight, price and stock. A custom measurement may require validation or a quotation rather than immediate purchase. These distinctions affect the product page, the basket, stock handling and the information passed to staff. They should not be buried in a note added after development.

Identify the source material and its condition. Product information might be spread across spreadsheets, supplier feeds and printed catalogues. State who will clean names, remove duplicates, check images and approve descriptions. Ask whether the project includes preparing data, importing it or both. “Product upload included” leaves too much room for different interpretations.

Plan categories and filters around questions customers actually ask. A technical buyer may need dimensions or compatibility; a gift shopper may need occasion and delivery timing. Avoid adding a filter for every column in a spreadsheet. Test a small representative catalogue with someone who has not organised it, and see whether the labels help them narrow the choice.

Include downloads and evidence where they matter. Specifications, fitting instructions and care information need a source, an owner and a sensible update process. Explain whether a document applies to one product, a product family or the whole store. This prevents repeated manual uploads from becoming another source of inconsistent information.

3. Define customer groups and pricing rules

List the groups that can buy and the differences between them. A public customer might pay the displayed price immediately. An approved trade account may see a different catalogue, minimum quantity or agreed pricing. A sales representative might create an order on a customer’s behalf. Do not assume these are simple switches available in every proposed platform or subscription.

For wholesale, describe account approval. Who can apply, what information is collected and who decides? What can an applicant see before approval? What happens when a customer is suspended or a member of staff changes company? Explain these states in plain language, then ask the supplier to demonstrate the intended experience for each one.

Be specific about quantities. A minimum order value, a minimum number of units and a carton multiple are different rules. If a product must be ordered in sixes, test what happens when someone enters seven. If a minimum applies only to one group, explain whether other groups can buy a single item. Include mixed baskets containing products with different pack rules.

Pricing also needs a clear authority. State whether prices are maintained in the website, an accounting system or another source. Explain scheduled changes and how staff should handle orders placed while an update is in progress. Ask how the proposed system prevents private prices from appearing to the wrong customer group.

For tax presentation and selling across borders, record the territories and customer types so the appropriate specialist can confirm the rules. This brief is an operational planning tool, not tax advice. The website should implement confirmed decisions rather than ask the developer to infer them. Keep a record of who approves those decisions and the examples used to test them.

• Describe public, approved trade and orders placed with staff assistance separately.
• Provide examples of account approval and suspension.
• State minimum order values, quantities and pack multiples precisely.
• Name the source of price and tax decisions.

4. Decide which system owns stock and order information

List every system that needs to exchange information with the store. This may include stock software, accounting, a warehouse service, a till or a shipping provider. For each connection, describe the information moving in each direction and how quickly it needs to arrive. “Connect to our accounts” is not enough to establish whether the scope involves invoices, customer records, prices or all three.

Choose an agreed main source for each important field. If both the website and a warehouse spreadsheet can independently change stock, you need a conflict rule. If a retail counter sells the final unit while an online customer is checking out, the business must decide how that situation should be handled. A platform recommendation should be assessed against these real constraints.

Ask what happens when a connection stops working. Who is alerted? Can the store continue taking orders? How does someone identify records that did not transfer? Does a retry create a duplicate order? Ask to see how staff handle a failed transfer as well as how the connection works when everything goes to plan.

Explain stock reservations and unavailable items as business rules. Should an item be held while payment is attempted? Can customers order it while it is out of stock? Is the expected availability date reliable enough to publish? Avoid showing an estimated date simply because the interface provides a field. Someone in the business must own the accuracy of that promise.

Where no connection is planned, describe the manual process honestly. A daily stock import may be proportionate for one business and risky for another. State who prepares it, who checks it and what happens at weekends or during staff absence. Manual work is still part of the system and needs to be included in the brief.

Ask who can inspect a failed transfer without changing the record. Access that allows staff to view records without changing them can help customer service investigate while reserving corrective actions for an authorised person. Agree how long the business needs operational records for troubleshooting and who controls that policy. The developer should implement the agreed approach rather than retain unnecessary copies indefinitely. Include the person responsible for reviewing access when staff change roles or leave the business.

5. Explain checkout and payment as separate states

List the information needed to fulfil an order and remove fields that serve no clear purpose. Decide whether customers can check out without an account, how returning customers sign in and what happens if they forget their password. Test the flow on a phone with a realistic address and a product that has options. The information must remain clear when the basket is more complicated than the demonstration.

Name the proposed payment provider if one is already selected, but avoid treating a provider logo as a complete payment plan. Ask how successful, failed, cancelled and pending payments appear to the customer and staff. Clarify when the order is created, when stock changes and which status permits picking or dispatch. Those events may not occur simultaneously.

For example, Stripe’s Checkout fulfilment documentation explains that a customer may pay and then lose their connection before reaching the confirmation page. Its automated fulfilment guidance relies on server notifications and requires repeated notifications to be handled safely. The practical brief question is straightforward: how will a paid order still reach staff if the buyer closes the page?

Include a recovery route. A customer whose payment attempt fails should understand whether an order exists and what to do next. Staff should have a reliable way to distinguish a genuine paid order from an abandoned attempt. A confirmation email helps communication, but it should not be the only evidence used to decide whether goods are sent.

Ask for test scenarios covering refunds and partial changes too. If one line is unavailable, who authorises a partial refund and how are stock and customer messages updated? The brief does not need to prescribe the underlying code. It needs to make the expected business outcome clear enough to demonstrate.

• Successful payment with the customer returning to the website.
• Successful payment with the browser closed before confirmation.
• Failed or cancelled payment followed by a retry.
• A repeated payment notification without duplicate fulfilment.
• A partial refund and the resulting order and stock records.

6. Write delivery and collection rules with exceptions

List where you deliver, the services available and the information needed to calculate the correct option. Weight, dimensions, product type and destination can all matter. Include addresses that are easy to overlook, such as a remote destination or a location outside the standard delivery area. Ask the agency to explain how the proposed shipping rules handle them.

Do not assume a postcode boundary matches your part of the ordering process. If the business makes local deliveries, supply a realistic zone map or postcode list and describe ambiguous addresses. Decide what customers see when you cannot automatically offer a service. A clear quotation route may be more useful than a misleading flat delivery charge.

For collection, state the location, opening times and the point at which an order is ready. Payment confirmation is not necessarily a collection invitation. Explain whether the customer selects a slot, waits for a staff message or collects within a published window. Include closure days and the person responsible for updating availability.

Consider mixed baskets. A small parcel and an oversized item may require different delivery services or separate consignments. A product made to order may hold up an otherwise available order. Decide whether the store splits deliveries, presents a single promise or asks staff to quote. The wording customers see should reflect that decision before payment.

Write a small destination test set rather than leaving testing to whatever address a developer happens to know. Include a standard local order, a boundary address, a collection order and a basket with an exception item. The dispatch team should review the results, because it will have to honour the options shown.

7. Describe the work after an order is placed

Follow an order through the business. Who checks it, who picks it, who packs it and who confirms dispatch? Explain the documents or screens each person needs. If a picker needs the product code and pack quantity rather than the marketing product name, make that explicit. If a customer service colleague needs payment status, give them appropriate access without unnecessarily exposing unrelated controls.

Account for exceptions. An incorrect address, damaged item or customer cancellation can create more work than a routine order. Decide who can amend details, which changes require confirmation and how the customer is informed. Keep a clear distinction between changing a delivery address and changing the financial record of the order.

Email messages also need an owner. List the points at which customers hear from the business and check that the wording describes the actual state. “We have received your order” and “Your order is ready for collection” are different promises. Include reply handling so a customer responding to a message reaches someone who can act.

Prepare for staff absence. A process that works only while one experienced person is present is difficult to rely on. Identify a backup owner for order review, stock correction and customer queries. Provide short instructions for common tasks and a route for escalating a situation staff should not attempt to resolve themselves.

Finally, decide what management information is genuinely useful. Orders requiring action, unsuccessful transfers and products with low availability may be more actionable than a decorative dashboard of totals. Ask for access and reports that support decisions, while keeping customer data access proportionate to each role.

8. Ask suppliers to justify the platform and scope

Only compare platforms after describing the trading rules. A familiar platform may still need extra software or custom work for your account pricing, stock source or delivery exceptions. Ask each supplier to map its recommendation to the same requirements and identify where standard features end and additional dependencies begin.

Ask for a clear distinction between configuration, custom development, data preparation and integration work. These carry different delivery risks and ongoing responsibilities. A proposal may include installing an extension without including the work needed to clean the data it depends on. Make the assumptions visible before comparing totals.

Review recurring dependencies alongside the initial project. Identify hosting, licences, payment services, integration services and support. Avoid relying on a quoted price in an article or an old proposal, because availability and commercial terms change. Ask the supplier to confirm the current arrangement directly and explain who owns each account and renewal.

Ownership and portability matter. Ask how you can obtain product data, orders and other business information in usable formats. Clarify which parts of the store are licensed and what a future handover would involve. A downloadable export is useful, but it does not necessarily reproduce every pricing rule or external connection elsewhere.

Leave room for suppliers to ask questions. If an agency needs to investigate your existing stock system, agree a limited piece of work and the answer it should produce. For example, showing one product update and one order transfer may answer an important question before you commit to the full build. Ask what the test will prove, what it will leave untested and who will review the result. That gives the investigation a clear purpose and a sensible stopping point.

Our Shopify development and WooCommerce development pages explain the work around each platform, including the operational details to settle before a build.

9. A hypothetical wholesale brief, worked through

Hypothetical example: a confectionery wholesaler wants approved retailers to order cartons online while the public can browse product information. This example is invented to illustrate briefing decisions. It does not describe a Podium client, and none of the quantities or outcomes should be read as published project evidence.

The first draft says “trade login, stock integration and checkout”. The useful version explains that applicants can browse but cannot order until staff approve them; approved accounts see their permitted catalogue; products have carton multiples; and the dispatch team needs carton counts and individual product codes. Those statements give suppliers concrete behaviour to assess.

The business adds four sample products: a straightforward carton, a product with two pack sizes, a seasonal line with limited stock and an item sold only to a particular customer group. It supplies sample accounts representing approved, unapproved and suspended buyers. The samples expose rules that an demonstration of an ordinary retail shop would miss.

The brief then follows one order. A retailer adds the minimum permitted cartons, sees the agreed delivery option and pays. Staff receive a usable picking record. If the browser closes after payment, the order still appears correctly. If a connection is retried, it does not create a second dispatch instruction. An unavailable line follows a named exception process rather than being silently replaced.

Podium’s published 3D Candy case study provides related wholesale work to explore. The example above is invented for this guide and does not describe that client’s features or results. Keep the two separate when preparing your own brief: use the hypothetical order to think through your requirements, and use the published project to ask about Podium’s experience. That lets you discuss relevant work without assuming every wholesale business needs the same catalogue, account rules or checkout.

Add a sample exception sheet to the hypothetical brief. One row describes an approved retailer attempting to buy a restricted line; another describes a stock change after an item entered the basket. A third covers a customer asking staff to alter an order already sent for picking. For each, the business records the intended decision and the staff role allowed to make it. The supplier then explains which behaviour can be configured, which needs additional work and which is better handled through a clear manual process.

Include the source data beside each example. An account group should have an approved meaning, a product code should match the catalogue and a delivery rule should refer to the same destination list used elsewhere. This sounds basic, but examples assembled from different spreadsheets can contradict one another. Resolve contradictions before using the brief as an acceptance document. A developer should not have to guess which of two apparently approved prices the business intended to use for the demonstration.

Prepare an ownership sheet with four columns: information, agreed main source, person responsible and correction route. Fill it in for product details, stock, customer approval, price changes, delivery rules and order status. The correction route matters because a colleague may notice a problem without being authorised to change it. For example, customer service might report an incorrect pack size to the catalogue owner rather than altering a warehouse record directly. This makes the brief useful to staff as well as the agency.

Use the completed sheet during a small practice order review. Ask finance, dispatch and customer service to follow the same sample order and identify the information each needs. Resolve disagreements about status names and documents before approving the interface. Keep the walkthrough focused on the first release; record later ideas separately. The resulting brief should explain a workable current process, with enough context for future improvement, rather than becoming an wish list without clear limits that no supplier can confidently estimate or deliver.

10. Turn the brief into a launch and handover checklist

Convert the most important rules into acceptance scenarios. Each scenario should name the customer or staff role, starting conditions, action and expected result. Use approved sample data and record who checks the result. A screenshot of a nice product page is not evidence that trade prices, delivery exceptions and payment handling work together.

Plan a controlled launch that matches the business’s capacity to respond. Confirm who checks the first orders, who can pause ordering if needed and who resolves a failed transfer. Keep the previous trading process available where that is practical and agreed. Do not improvise recovery responsibilities after a live order becomes uncertain.

Handover should include routine tasks, access ownership and exception handling. Ask staff to add a product, correct stock, process a refund within their role and find an order requiring attention. Let them perform the tasks rather than merely watching a demonstration. Their questions are useful evidence about gaps in training or the interface.

Book an early review after real orders have passed through the system. Look at practical issues such as confusing product options, staff workarounds and failed notifications. Prioritise corrections based on the effect on buyers and fulfilment. Do not claim that a short initial period proves a commercial improvement; use it to make the operation more reliable.

Podium’s ecommerce service is the next step for discussing a scoped shop or project for trade orders. Bring representative product data and the uncomfortable exceptions as well as the ideal order. They are often the most valuable parts of the brief.

A useful final question is whether a new colleague could manage an ordinary order using the handover material alone. Ask someone who was not closely involved in the build to try. Watch where they need a verbal explanation and improve the instructions or interface accordingly. This does not replace specialist training for sensitive financial or account actions. It checks whether routine order handling has become an undocumented skill possessed by only one person.

Bring the brief to our ecommerce team for Belfast businesses to discuss the first release, connected systems and handover.

• Test public and trade customer visibility with separate accounts.
• Check stock and prices against the agreed source.
• Run successful, failed, interrupted and repeated payment scenarios.
• Review local, collection and exception delivery baskets.
• Confirm staff access, account ownership and recovery contacts.
• Record known limitations, training material and the review after launch owner.