Selling on WhatsApp: turning chats into a system

Customers prefer a message over a form or a call. The problem is not WhatsApp — it is running it without any structure.

Common mistakes

• Using a personal number instead of WhatsApp Business, losing catalogue and quick replies.
• No saved replies, so you type the same answer ten times a day.
• Orders living only in chat — once messages pile up, one gets lost.
• Replying hours later. Customers message three businesses and buy from whoever answers first.

The right setup

• Switch to WhatsApp Business and set up the catalogue and quick replies.
• Put a WhatsApp button on every page, with the message pre-filled for that page.
• Record orders in a system or at least a sheet, not the chat alone.
• A chatbot for the repeated questions: hours, prices, location.

Pre-filled messages matter more than they sound. If someone taps from your pharmacy page and the message already says so, you both skip five messages.

Measure it

Track how many people tap WhatsApp from each page. Without that number you cannot tell which page is doing the work.

Measure growth as a business result

Traffic, followers and impressions are diagnostic numbers, not the final result. Choose the event closest to revenue—qualified lead, booked appointment, completed order or repeat purchase—and make it a key event in analytics. Record the current baseline before changing the site or campaign.

Review performance by channel, landing page and customer segment. Keep tests long enough to collect a useful sample and change one major variable at a time. Growth work also needs operational follow-through: fast replies, accurate stock and a clear offer can matter more than another increase in ad spend.

• Choose one revenue-linked key event and verify that it fires.
• Record cost, qualified conversions and resulting revenue by channel.
• Change one major variable per test and write the result down.
• Check response time, stock and sales follow-up before raising spend.

A topic-specific field checklist

• Use catalogue links, short product codes and saved replies so an order can be reconstructed accurately.
• Capture customer name, phone, address, variant, quantity, payment and consent in structured fields—not scattered chat messages.
• Set response hours and an escalation rule for complaints and refunds.
• Move confirmed orders into the store or CRM to protect reporting and stock.

Details most proposals miss

Commerce is a chain of records: product, price, stock, customer, payment, shipment, return and refund. A polished storefront is not enough if those records disagree. The implementation should make exceptions visible and reconcile money and stock every day.

• One authoritative product and stock record with controlled updates.
• Order states that separate confirmation, payment, fulfilment, delivery, return and refund.
• Idempotent payment and shipping callbacks so retries do not duplicate work.
• Address, variant and total-cost confirmation before fulfilment.
• Daily exception queues for failed payments, delayed shipments and mismatched settlements.

The TechMate implementation layer

TechMate designs the storefront and the operational trail together. The customer gets clear status, while the team gets searchable orders, timestamps, responsibility and reports that can explain where margin or delivery performance was lost.

• Egyptian-pound totals shown consistently from product to receipt.
• Cash-on-delivery and electronic-payment journeys reported separately.
• Courier and gateway reference IDs stored against the order.
• Return and refund rules visible before checkout and enforceable in operations.
• Analytics connected to confirmed revenue, not button clicks alone.

Delivery phases that reduce risk

Release commerce in a controlled loop from product setup to settlement. Do not scale traffic until exceptions can be detected, owned and resolved without editing records by hand.

• Clean product, variant, price and stock masters.
• Test success, failure, cancellation, return and refund.
• Pilot payment and courier flows with real references.
• Reconcile order, money and stock totals daily.
• Automate only after exception patterns are understood.

Questions that reveal implementation quality

• Which system is authoritative for stock?
• What happens when a callback arrives twice?
• How is a partial return represented?
• Who owns a delayed shipment or settlement difference?
• Can margin be reported after delivery and returns?

A realistic scenario

Example: “I want the blue one” is not an order. A structured confirmation returns product code, variant, quantity, address, total in Egyptian pounds and payment method, then creates a searchable order before fulfilment starts.

Sources directly related to this guide

• Egypt Consumer Protection Agency — invoice, return and replacement FAQ
• Google Analytics — events and key events