A connected catalog does not begin with a row of attractive product cards. It begins with a clear answer to three questions: what should a visitor see, where does each value come from, and who owns its accuracy? Without that answer, a website becomes a second product list that someone has to update by hand.
Fluw can assemble a website, catalog, or storefront using information a company already keeps in a spreadsheet, file, CRM, or accounting system. That does not remove the need to prepare the data. A site can only publish fields that exist, have a shared meaning, and are approved for publication. A short inventory before the project saves more time than correcting every card later.
Start with the catalog job
The same product list can support very different customer journeys. An equipment catalog may help someone choose a model and send an enquiry. A storefront may show a price while a sales team confirms availability. An assortment page may lead to a consultation rather than a checkout.
Write one sentence describing the visitor’s next action:
- choose a suitable model and send a request;
- compare options and open specifications;
- see availability and place an order;
- find a product and contact sales.
That decision determines required fields, price visibility, button copy, and the treatment of unavailable items. The connected catalog example is useful because it separates the source, field mapping, final card, and limits of the demonstration.
Define one source of truth
List the systems involved and give each one a role. An accounting system may own SKU and stock, a price file may own commercial prices, and a content table may own descriptions and images. That arrangement can work, but conflicts need an explicit rule: which value wins when two sources disagree?
Before copying columns, record:
- the source of every field;
- the person or team responsible for it;
- the expected update frequency;
- the condition that hides a product or marks it unavailable.
Do not assume that a system name means a ready connector exists. A new connection needs an assessment of API access, permissions, limits, and data scope. The Business.ru integration page shows how to state a connection’s boundaries and label demonstration data without presenting it as a live customer feed.
Build a minimum useful product model
Each product normally needs a stable identifier, a useful name, and a clear availability state. An SKU should be unique and should not change because a product moved to another category. A name should help a person understand the item, not repeat an internal code.
Depending on the journey, the model may also include:
- category and brand;
- short description and specifications;
- unit of measure;
- price, currency, and a “price on request” state;
- stock or availability;
- images and image captions;
- variants such as size, color, or configuration;
- delivery or collection terms;
- a link to a manual or technical sheet.
Do not publish a field simply because it appears in an export. A buyer should not see an internal note, purchase cost, or warehouse code. Give every column a status: public, used inside the process, or not connected yet.
A concrete row
Imagine a company selling pumps. Instead of one cell reading “Pump 04 / 1.5 / old price,” use separate values such as `sku`, `name`, `flowRate`, `pressure`, `material`, `price`, `currency`, `availability`, and `image`. Visitors can then filter by flow and pressure, while the site can show suitable models and an enquiry form. Units must be consistent: do not mix litres per minute with cubic metres per hour unless the conversion is explicit and tested.
Make price rules visible
Price is more than a number. It may need a currency, tax note, validity period, and condition for display. If a product is priced only after configuration, “Price on request” is more honest than an old amount that looks final.
Check the following before publishing:
- negative, zero, or accidentally inflated values;
- rounding rules and decimal precision;
- retail, wholesale, and regional price confusion;
- whether delivery or installation is included;
- what happens when a price is temporarily missing.
If the price depends on a customer role, do not hide that rule behind one public number. Explain whether visitors see a public price, request a quotation, or need to sign in. A clear rule prevents the card from promising terms that only apply after a sales review.
Define stock and availability states
Stock can be an exact quantity, a range, or a business status. For many visitors, “In stock,” “Made to order,” and “Unavailable” are more useful than an internal number such as 3. Any conversion from a number to a status must be agreed with the data owner.
Write down edge cases:
- stock is zero;
- inventory is reserved;
- a warehouse is temporarily unavailable;
- multiple locations report different values;
- a shipment is expected but not confirmed.
When the source is unavailable, the site should not silently present yesterday’s stock as current. Depending on the process, it could hide the exact quantity, show the last checked time, or switch to an enquiry state. The important part is to make the choice explicit and include it in acceptance testing.
Prepare images and descriptions
An image must match the SKU and variant it represents. File names like `img_001.jpg` make review harder; a product identifier and purpose are easier to audit. Check that images do not contain personal data, internal notes, or marks that are not cleared for publication.
Write descriptions for selection, not for an internal archive. Start with the use case, then add important specifications, limitations, and what is included. When a value is unknown, leave it empty or use an approved “to be confirmed” state. Do not guess simply to make every card look complete.
Pre-connection checklist
- The catalog job and primary visitor action are written down.
- Every field has a source and an owner.
- SKU values are unique, stable, and never reused.
- Categories, units, and variants are normalized.
- Price includes a currency and a clear display condition.
- Rules for zero, unknown, and stale stock are documented.
- Public images and documents have been reviewed.
- Internal fields are excluded from the public model.
- Update timing and last-checked behavior are defined.
- A test set includes normal products and edge cases.
Common failure modes
Duplicate products. The same SKU appears in two files or differs only by spaces. Enforce uniqueness and normalize identifiers before loading data.
A field changes meaning. “Stock” first means warehouse quantity and later means available-to-sell quantity. Keep a field dictionary and review meaning changes before publishing.
New price, old stock. Different sources update on different schedules. Show a checked time where it matters and do not call the combination “current” without a process that supports that claim.
Too many fields. The card becomes an internal reference table. Keep fields that help a visitor choose, compare, or send a request; use the rest inside the project.
A demo looks live. Example numbers are presented without a label. Mark demonstration data clearly and separate a proof flow from a working source.
Frequently asked questions
Can we start with an Excel file?
Yes, if the file has stable columns, unique identifiers, and a known update rule. A regular exchange may later need another delivery method, but a small file is a useful way to test the model and journey first.
Do we need to import the full assortment?
No. Start with the products that answer the catalog’s job. A small set can reveal problems in cards, filters, prices, stock states, and enquiry handling before you expand coverage.
Should we show an exact quantity?
Only when the source is reliable enough for that precision and the business is prepared to support the promise. Otherwise, use agreed availability states and explain what they mean.
What if our CRM or accounting system is not connected?
Describe the access, API, fields, limits, and update expectations first. A system name alone is not proof of a ready connector. See how Fluw works for the broader path from a task to a reviewable result.
Who changes data after launch?
The answer follows the source-of-truth decision. If the main system owns prices, editors should not maintain a competing copy in website cards. Assign an owner and an error-correction path before launch.
Start with a testable slice
Good catalog preparation is not a perfect export with hundreds of columns. It is a clear model of what visitors need, where the values come from, and what happens when a value is late or missing. Build a small test set, check it against real business rules, and expand only after the journey is understood.
When the task is clear, you can start with a task in Fluw and describe the website, catalog, or storefront you need. Before choosing the implementation, use pricing to understand the available scope and remember that an integration is a means to a customer journey, not the goal by itself.