The furniture brand digital asset checklist: what to have before you go to market
A buyer asks for your "product files." You send a Drive folder. It has some renders, a catalog PDF, and three STEP files named FINAL_v2_REAL.step. The buyer can't tell which version is current, can't preview the STEP on their phone, and emails back asking for a spec sheet. You've just added a week to your sales cycle for a file organization problem.
Minimum viable digital asset set
Before any product goes to market, these are the files that should exist and be ready to send:
| File | Format | Purpose | Buyer type |
|---|---|---|---|
| Silo render (front) | WebP or JPEG, 2048×2048 | Catalog, e-commerce grid | All buyers |
| Silo render (3-quarter) | WebP or JPEG, 2048×2048 | Product detail, comparison | All buyers |
| 3D viewer link | Fenicher workspace link | Interactive preview, AR | All buyers |
| Spec sheet | PDF, max 2 pages | Dimensions, materials, MOQ, lead time | Import buyers |
| GLB file | .glb, under 5 MB optimized | Web viewer, AR preview | Platforms, developers |
| STEP file | .step or .stp | Factory, interior designers with CAD | Production partners |
| Scene render | WebP or JPEG, 3840×2160 | Instagram, editorial, showroom | Brand / retail buyers |
What you need per SKU
"SKU" here means a unique product + colorway combination. A sofa available in 3 fabric colors is 3 SKUs.
- One STEP file per shape variant. The geometry is the same across colorways; the STEP doesn't change when fabric changes. One STEP per shape is enough.
- One GLB per colorway. Material maps change per fabric/finish. Each colorway needs its own GLB with the correct PBR textures baked in.
- Silo renders per colorway. Front + 3-quarter minimum. Buyers comparing two fabric options need to see both.
- One spec sheet per shape family. If the same frame comes in 2-seat and 3-seat variants, one spec sheet covering both (with the dimension variation clearly labeled) is cleaner than two identical sheets.
File naming conventions
A naming convention that works across teams, agencies, and buyers:
{product-code}-{variant}-{type}-{angle}.{ext}
Examples:
SOF-OSLO-01-NAT-silo-front.webp # Oslo sofa, natural oak, silo, front view
SOF-OSLO-01-NAT-silo-3q.webp # same, 3-quarter
SOF-OSLO-01-NAT-scene-living-01.webp # scene render, living room set, first shot
SOF-OSLO-01.step # STEP file (no variant needed — same geometry)
SOF-OSLO-01-NAT.glb # GLB (variant-specific for textures)
SOF-OSLO-01-spec.pdf # spec sheetThe key rules: product code first (so files sort together), variant second, type (silo/scene/spec) third. Never use spaces — they break URLs and command lines. Never use "FINAL" in a filename — there's always another final.
Version control for 3D files
3D files change during production: dimensions get corrected, materials get revised, new colorways are added. Without a version system, buyers get old files and order to the wrong spec.
- Use a version suffix on working files:
SOF-OSLO-01_v3.step. Only the current production version gets published to the buyer workspace — without the version suffix. - Archive, don't delete. When a new version supersedes an old one, move the old file to an
_archive/folder rather than deleting it. You may need to trace back what a factory was given. - Revoke outdated buyer links. When you update a product, revoke the old workspace link and send a new one. Buyers who still have the old link will share the old spec. Fenicher's revoke feature handles this in one click.
We had a factory produce 200 units to an old STEP file because the buyer forwarded a link we hadn't revoked. The fix cost us more than the entire 3D production budget for that quarter. We revoke every link as a routine step now.