In this guide 6 sections
Buy for the style, not the single product. A clothing brand needs variants with their own stock, collections that open and close on set dates, lookbooks tied to live inventory and exchanges that run before refunds. Test every one with your own awkward styles.
Can the catalogue hold a style with sizes and colours?
Ask the vendor to build one of your real styles on screen, such as a jacket in four colourways and seven sizes, with extended sizes priced higher. Count every click it takes. Then swap the photos on one colourway, and watch whether the other three keep their pictures or quietly inherit the new ones from the system.
A weak system treats every size and colour as its own product, so Navy medium and Navy large become pages that compete in search and drift apart on price. The better design is simple. It keeps one style code, one description and one size guide, with every size and colour listed underneath as a row that carries its own barcode and stock count.
Then test the data entry. Time a merchandiser adding a new colourway to an existing style, because slow entry means the team will quietly skip colours at launch.
- One parent record per style code
- A child row for each size and colour pairing
- Extended sizes priced differently without a second product
- Photos shared at colourway level
- A size guide attached once, to the parent
Collections need dates, not just tags
Fashion sells in drops. A capsule goes live on a Thursday, a pre-order window closes three weeks later and last season’s styles slide to a markdown shelf on a fixed day. Tags alone leave someone flipping switches at midnight.
Ask for collections that carry a start date, an end date and a rule for what happens afterwards, such as moving unsold styles to an outlet shelf. Carry-over styles, such as a plain white shirt, should sit in two collections at once without a duplicate record behind either one. Pre-orders need a visible dispatch date.
Look at the end date too. A closed collection should redirect its old address to the new one, so campaign emails sent weeks earlier do not end on an error page.
Lookbooks should read from live stock
In a lookbook, campaign photos carry product tags, and if those tags point to a frozen page, a shopper taps the linen dress and meets a sold-out size grid. That looks careless to a buyer.
Run three quick checks. Each tag should open the style with the colourway already chosen, and a sold-out size should grey out instead of vanishing from the grid. Last, the lookbook should read its prices from the catalogue, so a markdown reaches every hotspot without anyone editing the image.
Exchanges are a fashion feature, not an afterthought
Most fashion returns come down to fit, so the shopper often wants a different size and not a refund, and the software should treat that as normal. Have the vendor walk through one exchange: the request, the reason, the reverse pickup, the check-in at your warehouse and the dispatch of the replacement.
The order of steps matters. A good flow holds the replacement size before the return lands and releases the refund or store credit only after someone has inspected the garment and graded it. Reasons should come from a fixed list that you can count later, such as runs small, wrong colour or arrived marked.
- Reason codes you can report on by style and size
- Inspection grades that decide restock, outlet or write-off
- Store credit and refund to the original card as separate paths
- A reverse pickup label printed from the order screen
How to test each claim in a vendor demo
Before the demo, send the vendor a spreadsheet of your twelve messiest styles, with odd sizes, a colour that has no photo and a style sold in two collections. Then ask them to import it live. Read out every row that fails.
Run the same five scenes with every vendor so the results can be compared side by side, and score each scene as pass, partial or fail. Write down what you saw. A partial usually means a paid plugin from another company, or a manual workaround that lands on your merchandiser every Monday morning before the drop goes live.
- Build a style with seven sizes and four colourways
- Close one collection on a date and open the next
- Tag a lookbook photo, then sell out one size
- Raise a size exchange and receive the garment
- Change one price and watch it reach the lookbook
Fashion platform demo scorecard
The scorecard runs to a single page with five rows: style and variants, dated collections, lookbooks, exchanges and file import, each scored on the same scale. Four columns sit beside each row: what to ask, what you saw, a pass or partial or fail verdict, and the recording time of the answer. The foot lists your test styles.
Open a blank worksheet to printQuestions owners ask
Do we need a separate product information system as well?
Not at first. A catalogue that holds styles, colourways and variants properly covers most labels until several teams start editing descriptions, translations and images for many sales channels at once.
Can a general store builder handle a fashion catalogue?
Often yes, for a small range. Trouble starts with long size runs, dated collections and exchanges, so run the five scenes on the builder first and note which ones depend on a plugin.
Who should attend the vendor demo?
Bring the person who uploads products, the one who answers return emails and whoever packs the parcels, because they spot gaps that a manager misses. The merchandiser checks the dates.
When does custom development make sense?
It makes sense when two or more scenes fail in every demo and the workarounds cost more staff time than the licence saves. GullySystem builds fashion catalogues with style-level records, dated collections and exchange flows for brands that reach that point after a few demos.