Start with the sales rules
An ecommerce specification should describe what is sold, how customers choose a product and how the team handles an order. A list of pages is insufficient: product pages that look alike can conceal different pricing, stock and delivery rules. First agree these rules using concrete examples, then define the interface structure and integration requirements.
You can prepare a useful first document without specialist terminology. Take several representative products and follow their journey from catalog upload to order completion. Record both the normal scenario and questions the team has not yet answered. It is better to expose uncertainty in the brief than hide it behind the phrase “a standard online store.”
A store specification connects product selection, checkout and payment confirmation to verifiable customer and administrator scenarios.
Describe the catalog and first-release boundaries
For each product group, specify required attributes, variants, photographs, prices and the source of availability information. Separate physical goods, digital products and services: their delivery methods and required checkout information may differ. If color and size define a separate saleable item, the catalog structure should reflect that.
Record who creates product pages, where the source data comes from and how many distinct page types are needed. Agree rules for hiding unavailable products, search and categories. Do not automatically include every request in the first launch: identify what is essential, what can follow later and what still needs investigation. This makes budget discussions about the actual scope of work.
Work through the order journey with examples
Write a short scenario: a visitor selects a variant, changes the quantity, adds a product, checks the cart and places an order. Alongside it, list the information your team actually needs. A delivery address may be unnecessary for a consultation but required for shipping a physical product. Decide separately whether an account is required or guest checkout is available.
Next, check the exceptions. What happens if a price changes while a tab is open? Can a customer order an unavailable size? How do they correct an error in their contact details? What do they see after a failed payment? Answers should define the expected behavior, not just message wording. For product variants, see our guide to variants and options.
Agree payment handling and statuses
Record the chosen payment service, available payment methods and the people responsible for configuring the terminal. Describe the page after checkout, payment-result pages and customer notifications. Clarify which status an order receives before payment, after payment confirmation and when manual processing is needed. Agree receipt requirements with the people responsible for the cash register and accounting before enabling live payments.
Clicking a payment button and returning to the website do not, by themselves, establish whether money was received. The specification needs a separate payment-confirmation scenario based on the chosen service's documentation. The team should understand what to do when confirmation is delayed or an order is reopened. The implementation method is selected after checking the integration's capabilities.
Describe the administrator's work
The customer-facing interface is only half the process. Specify who edits products, who sees orders and who changes their state. List the necessary filters: for example, new orders, awaiting payment and requiring approval. Discuss which information should be visible immediately and which appears inside the order.
If you use an inventory system, identify the source of truth for price and availability. Data exchange should not remain a vague requirement to “connect an integration”: define transfer directions, data fields, update frequency and actions on failure. If a particular system has not yet been selected, flag that as a separate decision affecting the estimate.
Turn wishes into verifiable criteria
“Convenient on a phone” is too broad for acceptance. Make it specific: the size selector is visible next to the photo; the total changes when quantity changes; the customer can edit the cart before confirmation. Include examples of states and agree which devices and browsers will be used to test the first release.
Prepare safe test data and expected results for integrations. Assign an acceptance owner and a process for recording issues. Keep the specification current: if a sales rule changes, update the relevant scenario and assess the impact before implementation.
Questions before you start
Do we need finished designs for the specification? No. You can first agree scenarios and rules. Designs help clarify element placement but do not replace answers about prices, availability and order processing.
Can we start with a small table? Yes, if it covers product types, core operations, constraints and open questions. The document's size should match the store's complexity.
Do all integrations need to be connected immediately? Only those required for the agreed launch. Put the others into later phases with clear dependencies.
How should we compare developers' proposals? Give them identical source information and ask for an explicit list of included scenarios, exclusions and assumptions. Comparing only total prices conceals differences in scope.
A short checklist
- Product types and the first catalog release are described.
- Selection, cart, checkout and errors have been worked through with examples.
- Payment, cash-register handling and payment confirmation are agreed with their owners.
- Administrator workflows and data exchange are defined.
- Acceptance criteria and open questions are recorded.
Send a sample catalog and a description of how you process orders: this will help us discuss ecommerce development in concrete terms. If the store connects to partner accounts or complex roles, consider a web platform as well.
