Buyer
- filters products using familiar specifications
- sees which values are confirmed by the source
- sends the selection together with project conditions
Connected catalog example
See how a catalog works in Fluw
Follow one demonstration flow: which data comes from the source, how fields map to the catalog, what the buyer sees, and which details reach the sales team.
Open the interactive demo
Demonstration using test data
N-240 pump
24 m³/h · SKU N-240
Flow rate: 20+ m³/hMedium: water
$480 · demonstration price
4. What sales receives
- N-240 pump · quantity 2
- Flow rate 20+ m³/h · water
- New York · delivery date needed
Every product, price, stock value, and specification in this example is test data. The diagram shows the interface and request contents, not a ready connection to every ERP.
Each stage has specific data and a decision
A catalog is connected when the source, purpose of each field, and action after product selection are clear—not simply because it is called an integration.
- 01
Prepare the source
The company provides a spreadsheet or describes an accessible system. Each product needs a stable identifier, name, specifications, images, and rules for displaying commercial data.
- name
- N-240 pump
- sku
- N-240
- flow_rate
- 24 m³/h
- price
- $480 · demo
Output: available fields and an example record
- 02
Map the fields
Each source field gets a defined place in the catalog. Decide in advance what happens when price, image, or stock data is missing.
- name
- → Product name
- flow_rate
- → Flow rate
- price
- → Price
Output: a clear source-to-site mapping
- 03
Build the buyer’s selection path
Filters use specifications buyers actually recognize. The product card shows comparable details and does not invent availability when the source has not confirmed it.
Output: filters, product card, and selected-item list
- 04
Send a completed request
The request includes selected products, search parameters, quantity, region, contact details, and the buyer’s question. Its destination is configured separately.
Output: enough detail for sales to continue the conversation
Fewer clarification rounds before a useful first response
Sales team
- receives SKUs and quantities without retyping them
- sees the filters and conditions behind the selection
- knows which price, stock, or delivery detail still needs confirmation
What is shown here and what is configured for the company
In this demonstration
- a test product-data row
- a small field-mapping example
- filters, a product card, and a completed request
For a real project
- the specific source, API, and access rights are checked
- update frequency and failure behavior are agreed
- delivery to an inbox, CRM, or another system is configured
Price and stock
They are current only when the source and update frequency are known. If the source is unavailable, the interface should use the agreed fallback rather than present an old value as new.
What to clarify for your catalog
Can we start with a spreadsheet?
Yes. A spreadsheet is enough for the first version when it contains stable product IDs, specifications, and clear display rules. Assess the system connection after validating the catalog.
Can every system be connected immediately?
No. First check a ready connector or API, access rights, limits, and required fields. If no ready connection exists, it needs a separate assessment.
How often do prices and stock update?
Frequency depends on the source and connection method. Instant updates are not assumed automatically and are agreed before launch.
What happens when the source is unavailable?
Show the last-confirmed time, hide the commercial status, or let the buyer ask sales to confirm it. The project needs one agreed behavior.
Describe your products and one real buyer journey
Tell us where products live today, which fields buyers use, and what sales should receive. That is enough to build the first catalog version from prepared data.