Module 4: Sales Automation · 20 min

Building a Product Catalog Flow Inside WhatsApp

// sabak

Turn this lesson into one checked practice output

By the end, you should be able to explain the core idea behind “Building a Product Catalog Flow Inside WhatsApp” in your own words, apply it to one small real or sample task, and identify what still needs human review.

  1. 1

    Learn

    Read the 20-minute lesson without copying an output blindly.

  2. 2

    Try

    Use a small, non-sensitive example that you can inspect line by line.

  3. 3

    Review

    Check facts, fit, and risk; save one improvement note for next time.

A catalog flow helps a customer find and request an eligible product. It does not replace product truth, inventory, pricing, tax, delivery, refund, or commerce-policy controls. WhatsApp states that businesses remain responsible for their transactions and that catalog commerce must follow Meta commerce policy and applicable law.

After this lesson, you can design a catalog flow backed by authoritative product data and a reviewable order summary.

Create the Product Contract

For every sellable item store:

product_id
approved_title
current_description
price_pkr
tax_and_delivery_rule
availability_state
eligible_locations
image_rights_owner
variant_options
return_or_cancellation_link
last_verified_at

The commerce system or governed catalog is authoritative. The chatbot retrieves values; it does not generate price or availability. Mark unknown, limited, preorder, made-to-order, or out-of-stock states explicitly.

Before listing an item, check WhatsApp’s current business messaging and commerce restrictions. Do not attempt to sell prohibited or restricted goods through a clever category name.

Design Browse-to-Request States

CATEGORY → PRODUCT → VARIANT → QUANTITY → LOCATION → SUMMARY → REQUEST
                 ↘ unavailable → alternative or human

At SUMMARY show product ID, variant, quantity, subtotal, delivery/tax status, fulfillment estimate, and policies. Use REQUEST ORDER if inventory or payment still needs verification. Use CONFIRM ORDER only when the underlying system actually reserves or creates the order.

Keep a back/edit route. If price changes between browse and confirmation, show the new price and require fresh confirmation.

Worked Example

A Sialkot sports-goods seller offers custom footballs. The customer selects Training Ball, size 5, quantity 10, and Lahore delivery. The catalog returns a sample subtotal of PKR 35,000, while customization and delivery are pending quotation. The flow cannot display PKR 35,000 as the final total.

The summary says:

10 × Training Ball TB-05: PKR 35,000
Logo customization: pending artwork review
Delivery to Lahore: pending quotation
Final total: not confirmed
Action: REQUEST QUOTE / EDIT / HUMAN

The request reaches an agent with product IDs and the customer-approved summary. The agent verifies artwork rights, production capacity, delivery, total, deposit, and terms. The order system creates the final reference.

Failure Cases to Diagnose

  • AI invents features from the product image: use approved catalog fields only.
  • Old price cached in the bot: re-fetch before confirmation and version the quote.
  • Unavailable variant appears orderable: validate variant combinations server-side.
  • Delivery hidden until after confirmation: disclose rule or pending amount clearly.
  • Image copied without rights: record permission or ownership.
  • Catalog contains restricted goods: remove them and review policy eligibility.
  • Chat message becomes the only order record: create a durable order or quotation reference.

🇵🇰 Pakistan Angle

Show PKR with separators and state whether tax, delivery, customization, and COD charges are included. For imported goods, do not promise customs, warranty, or delivery outcomes without current supplier and legal evidence. For handmade products, distinguish sample imagery from the exact delivered item.

Address handling should collect only fulfillment needs: recipient name, reachable phone, city, area, street/location detail, and landmark when required. Show it back for confirmation and restrict access. Do not request a CNIC image for ordinary catalog browsing or COD merely because it might reduce fake orders.

Hands-On Exercise

  1. Build product contracts for five sample items.
  2. Verify policy eligibility and image rights.
  3. Draw category-to-request states with edit and unavailable branches.
  4. Create a summary that separates known and pending amounts.
  5. Test price change, stock change, invalid variant, and unsupported city.

Done means: the customer sees current approved facts and cannot create a false order state when inventory, delivery, or total remains unverified.

Completion Rubric

  • Catalog facts come from an authoritative source.
  • Policy eligibility and media rights are recorded.
  • Price, fees, tax, and pending amounts are distinct.
  • Variants and availability are revalidated.
  • Edit and human routes exist.
  • A durable order/quote record follows the conversation.

Sources

Key takeaway: let chat navigate a governed catalog, but let authoritative systems decide eligibility, current price, availability, and final order state.

Self-check

Before you mark Lesson 4.1 complete

  • Can I explain “Building a Product Catalog Flow Inside WhatsApp” without reading the lesson back word for word?
  • Did I complete the lesson’s practice step on a real or clearly labelled sample task?
  • Did I check the result for invented facts, private data, unsafe actions, and mismatch with the brief?