Improve Product Listings, Prices, and Inventory With AI

A supplier file says an item is available. A product page says there are twelve in stock. A customer buys it. Only afterward does someone discover that the supplier's field was a yes-or-no flag, not a quantity.

AI can make catalog work faster, but fluent descriptions cannot repair misunderstood source data. Start by defining what each field means, which record is authoritative, and what needs review before a change reaches customers.

Your work product is a proposed product update with a source ledger, a price calculation, and an availability check. Cedar Desk Studio and its supplier, Pine Supply, are fictional. No Salars.net product, supplier record, price, inventory, or sales channel is accessed or changed in this exercise.

Give every product a stable identity

A stock keeping unit, or SKU, is your identifier for a sellable item or variant. Map it to the supplier's identifier explicitly. Similar names are not sufficient evidence that two records describe the same product.

For fictional BOX-12, the approved practice source says:

Notice that one sellable unit is a pack of five boxes. Inventory, cost, price, and the buyer's quantity selector must use that same unit. A price per box accidentally attached to a five-box listing can create a loss even when the arithmetic itself is correct.

Separate each variant that changes the actual offer. Do not combine different sizes, pack counts, conditions, or materials because their titles look alike. Leave uncertain matches for review.

Draft descriptions from verified attributes

Give AI the source fields and the intended reader. Ask it to explain the useful facts without completing missing specifications:

Draft a product title and concise description using the supplied record.
Preserve SKU mapping, pack quantity, units, dimensions, and condition.
Distinguish external dimensions from internal usable space.

Return a claim ledger with the source field for each factual statement.
List missing attributes separately. Do not invent compatibility,
certifications, provenance, materials, warranties, stock quantities,
shipping dates, or customer reviews.
Produce a proposed update only; do not publish or change business data.

An acceptable title is “Document Storage Boxes — Pack of 5 — 12 × 9 × 4 in External Size.” A supporting description can state that the dimensions are external and that internal dimensions are not supplied in the record.

“Archival-quality boxes that protect every valuable document” is unsupported. So is a claim that a particular binder fits when only external dimensions are known. Useful copy can tell the buyer what to verify rather than claiming universal suitability.

Keep product images equally accurate. An illustrative scene must not show additional included items, a different size, or a condition the customer will not receive. Check image and supplier-copy permissions separately from whether the product facts are correct.

Calculate contribution before recommending a price

Use a complete, explicit cost model. For BOX-12, assume a $29 selling price per pack, shipping paid by the seller, and these fictional costs:

The transaction fee at $29 is $1.17. Total specified costs are $21.87, leaving $7.13 contribution per order. This excludes advertising, fixed overhead, initial work, and any other unlisted costs. Taxes are outside this simplified example; do not copy its model into a real tax calculation.

The assumed fee is a teaching input, not a quoted payment provider's current price. Verify your actual contract and fee basis, including whether shipping or taxes affect the charge.

Suppose the proposed rule is to retain at least $8 contribution under these assumptions. Non-percentage costs total $21, including the fixed $0.30 fee. The price must therefore satisfy:

Price × 0.97 − $21 ≥ $8.

That gives a price of at least $29.8969 before cent rounding. At $29.90, the assumed percentage-plus-fixed fee rounds to $1.20, and the specified contribution is exactly $8.00. Recheck the rounded result instead of assuming a rounded price always meets the target.

This is a cost-based candidate price. It does not prove customers will accept it or that it is competitive. Compare the proposed offer and its actual value with the evidence gathered in Chapter 22.

Distinguish markup from margin

A markup is measured against a cost base; a margin is measured against selling price. If someone reports a “50% profit” because a $10 item sells for $15, they have described a 50% markup on that item cost, not a 50% margin and not necessarily any profit after other costs.

For catalog decisions, name the measure and included costs. “Contribution after the listed per-order costs” is more useful than an unlabeled profitability score. Keep currency, exchange assumptions, source dates, and rounding rules with the calculation.

Use AI to explain unusual changes and flag missing inputs. Use deterministic arithmetic for the actual calculation. A model should not supply an invented shipping charge or silently replace a missing cost with zero.

Evaluate a proposed bundle as its own sellable unit: list the included SKUs, quantities, combined costs, and actual price. Confirm that stock rules reserve every component. Recommend an add-on only when it fits the buyer’s stated task, and show its extra cost clearly. Any limited-stock or deadline claim must reflect a verified constraint; generated urgency does not create one.

Count stock that can actually be sold

The fictional warehouse record has ten packs physically on hand. Of those, three are reserved, one is damaged, and two are held as an operating buffer. These categories are non-overlapping in this exercise.

Available-to-promise stock is four packs: 10 − 3 − 1 − 2. Five more packs are on an incoming purchase order but have not been received. They are not part of current physical stock.

If your system's “available” field already subtracts reservations, do not subtract them a second time. Document the field definition. Negative results, overlapping categories, and mismatched units should create an exception, not a cosmetically improved number.

The separate Pine supplier feed says “available” and has an older timestamp. It supplies no quantity. Do not convert that flag into one unit, twelve units, or unlimited availability. A supplier promise and your own warehouse count also need distinct locations and fulfillment rules; adding them together may double-count stock or promise delivery you cannot support.

For Google Merchant Center, submitted availability must match the website. Its in-stock definition concerns accepting orders and being able to fulfill them; preorder and backorder have different meanings and additional requirements. See Google's availability attribute guidance.

Review changes as a batch of proposals

A useful change review shows the old value, proposed value, reason, source date, and expected effect. Include exceptions beside the proposed changes.

Before applying an approved batch, check that the underlying values have not changed since review. A fresh order may consume stock; a supplier may update cost. Use an implementation that prevents simultaneous sales from overselling the same units and can report partial failures across channels.

Google also requires price consistency between submitted product information and the landing page and checkout, subject to its detailed rules. Fix the actual source and synchronization problem rather than repeatedly submitting conflicting values. See Google's price attribute guidance.

Maintain the decision after publication

Assign owners to supplier feeds, product content, pricing, and fulfillment. Define when a stale feed should stop automatic changes or require review. Choose that interval from supplier reliability and business risk; no universal freshness threshold fits every product.

If a product becomes unavailable after an order, route the actual customer obligation through the fulfillment and support process. A changed inventory number does not notify a buyer or resolve a delayed shipment.

Measure listing corrections, order cancellations caused by stock errors, contribution after actual costs, and the time required to review proposed changes. Track errors by cause: wrong mapping, stale data, unsupported copy, cost omission, or failed channel update. That makes the next improvement concrete.

Keep a history of approved changes and verified results. A proposal, a submitted update, and a successfully reflected customer-facing value are three different states. AI is most useful when it makes those decisions easier to inspect.

Next: Build a small digital product with the same attention to evidence and usability in Chapter 24.