An online store brief should explain how customers choose and buy, how the team fulfils orders and where product information comes from. You do not need to name a platform in advance. You need to show the actual sales process, including anything that remains uncertain.
A category list and a few stores as visual references are useful, but are not enough to assess the work. Start by describing a typical sale, then add the cases that differ from it.
What exactly will you sell online?
Clarify whether customers complete a purchase on the website, request a quote or reserve a product for further discussion. These options require different actions from visitors and your team.
Also specify whom you sell to: consumers, businesses or both. If some customers see agreed prices, describe how they receive that access. Do not assume an account is essential for every purchase; explain when one is actually needed.
In the Palisandar OOD platform, product variants and enquiries reflect how timber is sold. Customers may need to clarify quantities, applications and transport. This illustrates why a catalogue should follow the business, rather than reduce every sale to the same ordering and payment steps.
Prepare a small, representative product sample
The whole catalogue does not need to be ready for the first conversation. Choose real examples: a simple product, one with variants and one with special conditions, if applicable. For each, show the available data and note what is missing.
The sample should usefully include:
- name, product code, category and description;
- images and attributes customers use to choose;
- variants such as size, colour or packaging;
- unit of measure, price and discount rules;
- stock and ordering restrictions.
Explain what changes when a variant is selected. A different size may mean a different price, stock level or delivery time. The provider needs to understand those dependencies, beyond seeing a list of attributes.
Specify where products will come from: a spreadsheet, an existing store, inventory software or manual entry. Who will clean the data and prepare the images? Importing and preparing the catalogue are different tasks, and each needs a clear owner.
Follow the order from the customer to fulfilment
Describe what happens after a product is selected. What information does the buyer provide, how do they choose payment and delivery, when do they receive confirmation and who sees the order within the company?
For payments, list the intended methods and whether you already have an agreement with a provider. For delivery, describe territories, couriers or your own transport, including cases where the price is confirmed separately. You do not need to design the technical integration yourself.
Then describe the team’s work: who checks stock, who prepares the shipment and who changes the status? If an order needs manual approval, that should be clear in the brief.
Add a few exceptions. What happens when a product is out of stock, payment fails, only part of an order can be fulfilled or an order is cancelled? Describe your rule, including decisions that remain with a person. Not every exception needs to be automated in the first version.
Which system determines price and stock?
If you have an ERP or inventory system, provide its name, available documentation and a technical contact. Describe which data needs to be exchanged and in which direction. “ERP integration” does not define a scope by itself.
For example, clarify whether the store receives prices and stock levels and sends orders. Where are products edited? When is stock reserved for a customer? What should happen if the exchange stops temporarily?
Do not promise immediate synchronisation before understanding the other system’s capabilities. Record the desired behaviour and let the technical team check what is possible. Even without an integration, someone and a process must keep the information up to date.
Who will manage the store after launch?
Describe everyday tasks and the people performing them. One employee may process orders while another edits products. Establish whether different permissions are needed and what training you expect at handover.
Separate launch requirements from later phases. Agreed customer prices, a complex inventory connection or another market may matter, but it needs to be clear which of these are essential for the store to operate at all.
Provide the budget range, dependencies on external providers and the deadline for preparing products. Ask for recurring costs and maintenance to be described separately from development.
How to check that the brief is clear enough
Choose a sample order and walk through it with the provider. You should be able to explain where the price comes from, how stock is checked, who receives the order and how the customer learns the result. Repeat the discussion with one problem case.
Where there is a gap, record a question and who is responsible for resolving it. That is more useful than turning an assumption into a requirement. After this discussion, you can compare an existing platform, additional development and a custom solution against the process, budget and maintenance needs.
