Connected catalog example

How a spreadsheet row becomes a product card and a useful request

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.

See the complete path Open the interactive demo

Demonstration using test dataOne product — from source row to request

1. Source table

`name`	N-240 pump
`sku`	N-240
`flow_rate`	24 m³/h
`price`	$480 · demo

2. Catalog fields

nameProduct name

flow_rateFlow rate

pricePrice

3. What the buyer sees

Flow rate: 20+ m³/hMedium: water

N-240 pump24 m³/h · SKU N-240

$480 · demonstration price

4. What sales receives

N-240 pump · quantity 2
Flow rate 20+ m³/h · water
New York · delivery date needed

Example customer action · Send request to sales

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.

Step-by-step walkthrough

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.
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.
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

Value for buyers and sales

Fewer clarification rounds before a useful first response

Buyer

filters products using familiar specifications
sees which values are confirmed by the source
sends the selection together with project conditions

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

Demonstration boundaries

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

FAQ

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.

Start with your source

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.