How To Build A Revenue-Recovering Cart Abandonment Engine On WhatsApp: A Technical Playbook For Nigerian E-Commerce 

Global cart abandonment benchmarks assume a stable path from cart to checkout.

The customer adds items. The customer proceeds to payment. The customer completes the transaction. When abandonment occurs, it is usually a matter of hesitation, shipping-cost shock, or decision deferral.

Nigerian e-commerce does not operate on this assumption. The path from cart to completion in Nigeria is interrupted by at least three structural friction points that global averages do not account for:

Network Interruptions: A customer initiates checkout, the payment gateway times out during OTP delivery, and the session dies. The customer intended to pay. The infrastructure did not complete the handshake. The cart is now abandoned, not by choice but by connection failure.

Payment Gateway Friction: Bank transfer details are displayed. The customer switches to their banking app. The payment is made, but the webhook from the payment gateway to the storefront takes anywhere from thirty seconds to thirty minutes and even sometimes never arrives. The customer sees no confirmation and assumes something went wrong. The store sees an abandoned cart.

WhatsApp-first Price Comparison Behavior: A customer adds items to cart, then screenshots the cart and sends it to three vendors on WhatsApp asking for a better price. This is not cart abandonment in the traditional sense. It is an active price negotiation that happens entirely outside the storefront. The cart sits abandoned while the conversation moves to WhatsApp.

Social Buying Culture: Purchasing decisions, particularly for considered purchases above ₦30,000, are frequently deferred until a family member or friend gives approval. The customer adds items to cart, leaves to consult, and may return hours or days later, if they remember.

These are not edge cases; they are the normal operating conditions of Nigerian e-commerce. A recovery engine that does not account for them will misclassify behavior, mistime messages, and ultimately recover far less revenue than is actually available. This is why effective WhatsApp Cart Abandonment Recovery for E-commerce must be built on local behavioral data, not global benchmarks.

How Nigerian Brands Currently Handle Abandonment

When asked how they recover abandoned carts, most growth-stage Nigerian  e-commerce operators describe one of three approaches:

Mass Blasts: A broadcast list is created from phone numbers collected at checkout initiation. Every contact receives the same message: “You left something behind.” This is sent on a schedule, every Tuesday or every other day, regardless of when the cart was abandoned. The result is that customers who converted yesterday receive an abandonment message today. Customers who abandoned three weeks ago receive the same urgency framing as customers who abandoned three hours ago.

Manual Agent Follow-up: Agents scroll through the store’s backend or order management system, identify carts that did not convert, and send WhatsApp messages individually or in small batches. This works at low volume. At five hundred cart initiations per month, an agent can manage this. At two thousand per month, the system breaks. Agents prioritize recent carts; older carts are never recovered, and the same customers receive follow-ups from different agents who do not know the other agent already messaged.

Silence: This is the largest category, where most brands simply do nothing. The operational cost of building recovery infrastructure feels higher than the expected return, so the revenue sits unrecovered.

Unfortunately all of these approaches fail, one way or the other and here are some reasons why:

The mass blast approach fails because it has no state awareness. It cannot distinguish between a customer who abandoned ten minutes ago and a customer who abandoned ten days ago. It cannot stop itself from messaging a customer who already purchased. The suppression failure alone, messaging customers after conversion, damages customer experience and increases opt-out rates faster than any other single mistake.

The manual agent approach fails because it does not scale and because it introduces timing inconsistency. The recovery rate of a WhatsApp message sent within thirty minutes of abandonment is meaningfully higher than the same message sent within three hours. Manual follow-up cannot consistently achieve sub-hour response times at volume. The revenue loss compounds with every hour of delay.

Silence fails by definition. Recoverable revenue sits untouched.

The problem is not that Nigerian brands do not want to recover abandoned carts. It is that the tools they have access to have been built for mass communication, not event-driven recovery. And the custom solutions they might build require engineering resources that lean teams do not have. What these brands need is a dedicated WhatsApp Cart Abandonment Recovery for E-commerce infrastructure that works with their existing workflows, not against them.

A Concrete Revenue Example

Let us put numbers on what is being left behind.

Assume a brand receives 800 cart initiations per month. Not completed checkouts, but initiations. Customers who added items and at least began the checkout process. Assume an average order value of ₦45,000 and the brand currently recovers 2% of these carts through existing methods, mass blasts or manual follow-up.

That is 16 recovered carts per month, generating ₦720,000 in recovered revenue.

Now assume the brand builds the event-driven, segmented, suppression-aware engine described in this playbook. A realistic recovery rate for this architecture in the Nigerian context, starting from a proper baseline, is 12%, six times higher than the 2% baseline. That is 96 recovered carts per month, generating ₦4,320,000 in recovered revenue.

The difference between 2% and 12% on this volume is ₦3,600,000 per month. Per year, assuming no growth in cart initiations, that is ₦43,200,000 in additional revenue from the exact same traffic.

This is not theoretical. Operators running stateful, segmented recovery on WhatsApp regularly achieve recovery rates in this range. The gap between what most brands recover and what is actually available is not a gap in traffic or product-market fit. It is a gap in infrastructure.

The Core Reframe

If you take one idea from this introduction, take this:

The question is not what message should we send to abandoned carts?

The question is how do we orchestrate cart events, contact identity, segmentation logic, delay timing, conversion detection, and suppression conditions so that the right message, whatever it is, reaches the right person at the right time and stops immediately when it should?

Messaging is the visible part. Any copywriter can write a recovery message. What separates a working engine from a broken one is everything that happens before the message sends and everything that happens after. The rest of this playbook walks through each component of that orchestration layer, from trigger architecture to suppression logic to vertical-specific benchmarks, and ends with a step-by-step implementation blueprint for Siteti.

The Anatomy Of A WhatsApp Cart Abandonment Engine

The Full Component Map Of A Functioning Engine

A cart abandonment engine is not a single workflow. It is a system of eight interconnected components, each of which must be present and correctly configured for the engine to recover revenue at scale. When properly assembled, these components form the backbone of any serious WhatsApp Cart Abandonment Recovery for E-commerce operation.

The eight components are:

Event Capture: The storefront must detect when a cart becomes abandoned and send that event to your automation platform via webhook. Without event capture, you are broadcasting reminders, not triggering recovery.

We wrote you a detailed guide on how to bridge your core database and webhooks here

Identity Matching: The incoming event must be matched to an existing WhatsApp contact in your contact database. If the customer’s phone number is not connected to their website session, you cannot message them.

Eligibility Check: Before any message is sent, the engine must confirm that the contact is eligible to receive recovery messages. This includes opt-out status, active suppression flags, and frequency recency checks.

Cart Classification: The engine must read the cart value and category from the incoming event and assign it to a recovery tier. Impulse, considered, high-value, and premium carts receive different logic.

Sequence Routing: Based on the cart classification, the engine routes the contact into the appropriate sequence with the correct delay timing, message cadence, and incentive budget.

Delay Execution: The engine waits for the specified period after abandonment before sending the first message, then waits between subsequent messages according to the sequence configuration.

Conversion Monitoring: The engine listens for conversion events, completed checkouts, from any channel: web, bank transfer, USSD, or agent-assisted completion.

Suppression Trigger: The moment a conversion event is detected for that contact, the engine must immediately exit the contact from any active abandonment sequence and prevent any queued messages from sending.

How The Components Connect And Depend On Each Other

These components are not optional add-ons. They are dependencies. If event capture works but identity matching fails, the engine receives cart events but cannot message the customer. The revenue sits unrecovered.

If identity matching works but eligibility checks are missing, the engine messages customers who have opted out or converted hours ago; the customer experience degrades, and the opt-out rates rise.

If cart classification works but sequence routing is misconfigured, a premium cart receives impulse-level messaging. The offer is too small to motivate recovery, or worse, the discount amount signals that the product is not worth full price.

If conversion monitoring works but suppression trigger fails, the customer receives an abandonment message after they have already paid. This is the most damaging failure pattern in WhatsApp cart recovery. It is also the most common.

What Breaks When Any Single Component Is Missing Or Misconfigured

Missing components do not cause graceful degradation. They cause specific, predictable failure modes.

Without event capture, you default to scheduled broadcasts. Customers receive messages regardless of when they abandoned. Fresh carts and old carts are treated identically. Recovery rates fall below 3%, and without identity matching, you cannot message anyone. The engine becomes a data collection system with no output channel.

Without eligibility checks, you message opted-out contacts. WhatsApp opt-out rates increase, and the deliverability for all your campaigns degrades over time, while without cart classification, you send the same message to a ₦9,000 cosmetics cart and a ₦250,000 electronics cart. The cosmetics customer receives an offer that is larger than necessary, compressing margins. The electronics customer receives an offer that is too small to matter, recovering nothing.

Without sequence routing, delays are uniform across all cart types. High-value carts that need longer consideration windows receive the same urgency framing as FMCG carts that need sub-hour recovery; then both perform poorly.

Without delay execution, messages send immediately upon abandonment or not at all. Immediate messages interrupt the customer mid-consultation. Late messages arrive after the customer has already purchased elsewhere.

Without conversion monitoring, the engine never knows when a customer completes checkout. The suppression trigger never fires, and without suppression trigger, the engine messages customers after conversion. This is the failure mode that turns customers off WhatsApp commerce entirely. It signals that your systems do not know what your customers have done. Trust erodes quickly.

The Difference Between A Stateful Engine And A Stateless Broadcast

A stateless broadcast fires when a trigger condition is met. It has no memory of what came before. It does not check whether the contact has already received three messages this week. It does not check whether the contact converted through another channel. It fires, sends, and ends.

A stateful engine checks the contact’s history before every action. It knows:

• When the last cart event occurred
• Whether the contact has converted since that event
• What other sequences the contact is currently in
• Whether the contact has opted out of marketing messages
• When the last message was sent to this contact across any campaign

The non-negotiable requirement for cart abandonment recovery on WhatsApp is statefulness. Without it, you cannot build suppression. Without suppression, you cannot scale. Without scale, you are running a reminder broadcast, not a revenue engine. Statefulness is what transforms basic messaging into true WhatsApp Cart Abandonment Recovery for E-commerce.

Visual Overview: The End-To-End Flow From Abandonment To Recovery Or Suppression Exit

Customer adds items to cart and begins checkout.

Customer leaves before completing payment.

Storefront detects abandonment after configured waiting period (typically 15–30 minutes).

Storefront sends cart abandonment event to Siteti via webhook containing: customer phone number (if captured), cart value, cart items, checkout step reached.

Siteti receives event and attempts identity match against existing WhatsApp contacts.

If match succeeds, Siteti runs eligibility check: opt-out status, conversion recency, active suppression flags.

If eligible, Siteti classifies cart by value tier and category.

Siteti routes contact into sequence configured for that tier with specified delay timing.

First message sends after delay period.

Customer either converts or does not.

If customer converts via any channel, storefront sends conversion webhook to Siteti.

Siteti receives conversion event, matches to contact, triggers suppression, exits contact from active sequence, cancels any queued messages.

If customer does not convert, sequence continues to next scheduled message based on tier timing.

Sequence ends after final message. Contact is not re-entered into abandonment recovery unless a new cart abandonment event occurs.

This is the loop. Every component matters. Missing any one breaks the loop.

Trigger Architecture: Event-Based Recovery Workflows Explained

What A Cart Abandonment Event Actually Is At The Data Layer

A cart abandonment event is not a vague concept. It is a structured data payload that your storefront sends to your automation platform when a customer leaves items in cart without completing checkout. The payload contains the information your engine needs to decide whether, when, and how to attempt recovery.

From a Shopify store, the typical webhook payload for cart abandonment includes:

• Cart ID and token
• Customer email address (if captured)
• Customer phone number (if captured at checkout initiation)
• Line items with product IDs, titles, quantities, and individual prices
• Total cart value
• Checkout URL
• Abandonment timestamp

From a WooCommerce store with a cart tracking plugin, the payload includes similar fields but often requires additional configuration to capture phone numbers, as WooCommerce does not natively collect phone numbers at the cart stage.

From a custom storefront, you control the payload structure. The minimum required fields for a functional recovery engine are: customer phone number, cart value, and abandonment timestamp. Without these three fields, your engine cannot identify who to message, what recovery logic to apply, or when the abandonment occurred.

The Three Abandonment Trigger Types

Not all abandonments are the same. Your engine must distinguish between three distinct trigger types because each requires different recovery logic.

Add-to-cart Without Checkout Initiation: The customer added items to cart but never clicked the checkout button. This abandonment occurs early in the funnel. The customer has expressed interest but has not committed to the purchasing process. Recovery messages for this trigger type should focus on removing friction and answering objections, not on urgency or payment completion. The customer has not failed to pay. The customer has not yet decided to try.

Checkout Initiation Without Payment: The customer clicked checkout, entered contact information, and may have reached the payment selection page but did not complete payment. This abandonment occurs late in the funnel. The customer intended to buy but encountered friction at payment. Recovery messages for this trigger type should focus on payment completion specifically: reminding the customer of the payment method they selected, providing bank transfer details again, or offering alternative payment assistance.

Payment Attempt Without Completion: The customer selected a payment method, initiated the transaction, and the payment failed, timed out, or was cancelled. This abandonment occurs at the very end of the funnel. The customer tried to pay and could not. Recovery messages for this trigger type should be immediate, practical, and solution-oriented. Do not ask why they left. Ask what payment issue occurred and offer to help resolve it.

Most storefronts do not distinguish between these three trigger types by default. They send a single “cart abandoned” event regardless of how far the customer progressed. To build proper recovery logic, you need to configure your storefront or use a plugin that passes the checkout step reached as part of the webhook payload.

Why Each Trigger Type Requires Different Recovery Logic And Different Urgency Framing

An add-to-cart abandonment that occurred thirty minutes ago is not an emergency. The customer is likely still browsing, comparing prices, or consulting with family. Sending a high-urgency message — “Your cart will expire!” — to this customer feels aggressive and misaligned. The customer never intended to complete checkout immediately. The urgency framing creates friction.

A payment attempt abandonment that occurred thirty minutes ago is an emergency. The customer tried to pay and could not. Every minute that passes without resolution increases the likelihood that the customer purchases from a competitor or abandons the purchase entirely. The urgency framing here is appropriate and helpful.

Your engine must map trigger type to urgency level. A simple three-tier framework works:

• Add-to-cart: low urgency, educational tone, extended delay window
• Checkout initiation: medium urgency, facilitative tone, standard delay window
• Payment attempt: high urgency, solution-oriented tone, shortened delay window

Without this mapping, you send the same message to customers at completely different stages of intent. Performance across all segments suffers.

How To Connect Your Storefront’s Cart Events To Siteti Via Webhook

In Siteti, webhook configuration follows this pattern:

1. Navigate to the Automation section and select Webhook Receiver.
2. Generate a unique webhook URL specific to your cart abandonment workflow.
3. Copy this URL into your storefront’s webhook configuration settings.

For Shopify: Settings > Notifications > Webhooks > Create webhook. Select “Cart updated” or “Checkout updated” as the event. Set format to JSON. Paste your Siteti webhook URL.

For WooCommerce: Install a webhook plugin such as Webhook for WooCommerce or use WooCommerce’s native webhook system under WooCommerce > Settings > Advanced > Webhooks. Set the topic to “Cart updated.” Set the delivery URL to your Siteti webhook URL.

For custom storefronts: Make a POST request from your backend to your Siteti webhook URL whenever your abandonment detection logic triggers.

Once the webhook is configured, test it by initiating a cart abandonment on your storefront and confirming that Siteti receives the event in the Activity Log.

Identity Resolution: Matching A Website Session To A Known WhatsApp Contact

The hardest problem in WhatsApp cart recovery is not sending messages. It is knowing which phone number to send to.

Your storefront collects phone numbers at different stages. If you require phone number entry before checkout, you capture it reliably but may lose customers who abandon at the very first step. If you collect phone numbers later, you capture fewer abandonments but the ones you capture are higher intent.

The methods that work for identity resolution in the Nigerian context:

Phone number collection at cart page: The most reliable method. Add a phone number field to your cart page before the customer clicks checkout. This captures the number even if the customer abandons at the first step. Conversion rate on cart to checkout may decrease slightly, but recovery rate on abandonments increases substantially.

WhatsApp Click-to-Chat from product pages: When customers initiate WhatsApp conversations from product pages, capture their phone number and associate it with their website session ID. If they later add items to cart and abandon, you can match the session ID to the previously captured phone number.

Customer account matching: For returning customers who have accounts, match the logged-in email or phone number across sessions. This requires customers to be logged in, which many are not, but for those who are, resolution is perfect.

The gap problem: For customers who abandon without providing a phone number anywhere in the journey, identity resolution is impossible. You cannot message them. Accept this gap. Build your recovery engine for the customers you can reach, and optimize your storefront to capture phone numbers earlier to shrink the gap over time.

Delay Logic And Timing Windows For African Buying Behavior

Global e-commerce best practices teach that cart abandonment messages should send at one hour, twenty-four hours, and seventy-two hours after abandonment. These benchmarks come from markets where payment infrastructure is reliable, network connectivity is stable, and the primary reason for abandonment is genuine reconsideration or shipping cost shock.

Nigerian consumer behavior does not follow this pattern.

The one-hour window assumes the customer has stable internet access for the entire hour. Mobile data dropouts, battery changes, and network fluctuations mean that a Nigerian customer may abandon a cart not because they decided against purchasing but because they lost connectivity mid-process and could not return before the session expired.

The twenty-four-hour window assumes that payment methods process within minutes. Bank transfers, USSD payments, and agent-assisted transactions can take hours to reflect, and webhooks can take additional hours to arrive. A customer who paid six hours ago may still appear as an abandoned cart in your storefront.

The seventy-two-hour window assumes that the customer’s decision timeline is independent of external financial constraints. Many Nigerian consumers time purchases around salary dates, bill payment cycles, and airtime availability. A cart abandoned on the twenty-eighth of the month may convert on the first of the next month regardless of any message you send.

Using global timing benchmarks in the Nigerian context produces messages that arrive too late, too early, or completely misaligned with the customer’s actual situation. This is why localized WhatsApp Cart Abandonment Recovery for E-commerce requires delay logic built specifically for African buying behavior.

The Four Behavioral Patterns That Shape Nigerian Abandonment Timing

To build delay logic that works, you must understand why Nigerian customers abandon carts when they do.

USSD And Bank Transfer Payment Interruption: The customer selects bank transfer as payment method. The storefront displays account details. The customer opens their banking app or dials the USSD code. Somewhere in this transition, the customer loses their place. The session times out. The cart is abandoned. The customer may have already sent the payment. This pattern requires an immediate, short first-touch window. If payment succeeded but the webhook is delayed, the customer needs reassurance. If payment failed, they need alternative options within minutes, not hours.

Mobile Data Dropout: The customer is in a location with unstable data coverage. They add items to cart. The connection drops before checkout completes. By the time connectivity returns, they have moved on to another task. This pattern requires a longer first-touch window than payment interruption but shorter than genuine reconsideration. Two to three hours is appropriate. Enough time for the customer to be back in a stable connectivity zone, not so long that they have forgotten what they added.

Decision deferral to payday windows. The customer adds items to cart, reaches checkout, and realizes they have insufficient funds until payday. This is not abandonment by hesitation. This is abandonment by cash flow timing. Recovery messages for this pattern should acknowledge the constraint and offer a pathway: payment links that remain valid for days, layaway options, or simply a reminder closer to typical payday windows. The delay window should be measured in days, not hours.

Family consultation before high-value purchases. The customer adds a television, refrigerator, or laptop to cart. Before completing payment, they need approval from a spouse, parent, or sibling. The consultation can take hours or days depending on availability and time zones. Recovery messages sent within one hour will find the customer still in consultation. Messages sent within twenty-four hours may find them still waiting for a response. The appropriate delay window for high-value carts is twenty-four to forty-eight hours, with a longer sequence and softer tone.

Recommended Delay Windows By Cart Value Tier And Product Category

Based on observed behavior across Nigerian e-commerce operators using Siteti, the following delay windows have produced the strongest recovery rates.

Impulse Tier (under ₦15,000): First message at two hours. Second message at twenty-four hours. Third message at seventy-two hours. Do not send beyond third message. The margin on impulse purchases does not justify extended sequences.

Considered Tier (₦15,000 to ₦60,000): First message at four hours. Second message at twenty-four hours. Third message at forty-eight hours. Final message at ninety-six hours. Customers in this tier often need one to two days of consideration or consultation.

High-value tier (₦60,000 to ₦150,000): First message at twenty-four hours. Second message at forty-eight hours. Third message at ninety-six hours. Agent escalation after third message if the customer has responded to any message. The extended first-touch window respects the consultation and cash flow constraints common at this price point.

Premium tier (above ₦150,000): First message at forty-eight hours. Second message at ninety-six hours. No automated third message. Agent escalation on first response. At this value level, automated messages cannot replace human conversation. The engine should initiate contact, but the recovery conversation belongs to an agent.

Category-specific adjustments apply within these tiers. Fashion at ₦40,000 behaves differently from electronics at ₦40,000. Use the tier as your starting point and adjust based on category performance data over time.

The Difference Between A Delay And A Dead End

A delay is a waiting period after which the engine sends the next scheduled message. A dead end is the absence of further messaging when the customer has not converted but also has not been suppressed.

Many operators confuse the two. They build sequences with gaps between messages but no logical exit. Contacts who do not convert within the sequence window simply stop receiving messages. The sequence ends silently.

This is acceptable when the sequence reaches its configured terminal step. A contact who receives four messages over six days and converts on day seven is a successful recovery, even if the conversion happens after the sequence ended. The engine did its job. The timing expectations were exceeded.

The unacceptable dead end is when the engine stops messaging because of a configuration error, not because the sequence reached its terminal step. Common errors include:

• Delay values set too high, causing the sequence to exceed a platform timeout
• Missing fallback logic when an API call fails
• Incorrect suppression conditions that exit the contact prematurely

Test your delay execution by simulating abandonment events and confirming that messages send at the expected intervals. If messages stop sending without a suppression event, you have a dead end, not a delay.

How Network And Payment Failure Recoveries Require A Shorter First-Touch Window

Network interruptions and payment failures are not consideration problems. The customer has already decided to buy. The only thing standing between cart and conversion is a technical or infrastructure issue.

For abandonments flagged as payment attempt failures, shorten the first-touch window to fifteen minutes. The message should be practical and direct:

“We noticed your payment didn’t go through. Here’s the bank transfer details again: [account details]. Or reply PAY to receive a payment link.”

For abandonments where the customer reached checkout initiation but network conditions may have caused the dropout, use a thirty-minute window. The message should acknowledge the possibility of interruption:

“It looks like you may have lost connection during checkout. Your cart with [items] is still waiting. Click here to complete your payment: [checkout URL].”

Do not use extended delays for these trigger types. Every minute of waiting reduces the likelihood of recovery. The customer who tried to pay and could not is not coming back tomorrow. They are coming back now or going to a competitor now.

Building Delay Logic In Siteti: The Sequence Configuration With Specific Timing Parameters By Cart Type

In Siteti, delay logic is configured within the sequence builder using the Wait node.

To build a four-message sequence for the considered tier (₦15,000 to ₦60,000):

1. After cart classification and routing, add a Wait node configured for 4 hours.
2. Connect the Wait node to a Send Message node containing the first recovery template.
3. Add a second Wait node configured for 20 hours (cumulative 24 hours from abandonment).
4. Connect to a Send Message node containing the second recovery template.
5. Add a third Wait node configured for 24 hours (cumulative 48 hours from abandonment).
6. Connect to a Send Message node containing the third recovery template.
7. Add a fourth Wait node configured for 48 hours (cumulative 96 hours from abandonment).
8. Connect to a Send Message node containing the final recovery template.
9. Add a terminal node that exits the contact from the sequence.

For the impulse tier, use shorter cumulative windows: 2 hours, 24 hours, 72 hours. Only three Wait nodes.

For the premium tier, use extended windows: 48 hours, 96 hours. Only two automated Wait nodes before agent escalation.

For payment failure events, override the tier-based delay with a 15-minute first Wait node regardless of cart value.

To override based on trigger type, add a conditional branch before the delay logic that checks the checkout_step value from the webhook payload. If the value equals “payment_attempt_failed”, route to the short-delay workflow. If not, route to the tier-based delay workflow.

Cart-Value Segmentation: Why ₦8,000 And ₦280,000 Carts Require Different Recovery Logic

A single recovery message sent to every abandoned cart feels efficient. One template. One sequence. One offer. No complex routing logic to maintain.

The efficiency is an illusion.

When you send the same message to a ₦8,000 cart and a ₦280,000 cart, you are making two mistakes simultaneously.

The first mistake is under-recovering on the high-value cart. A message designed for impulse purchases does not address the concerns of a premium buyer. It does not acknowledge the weight of the decision. It does not offer the right incentives or escalation paths. The high-value customer reads the message, feels unseen, and ignores it. Revenue that could have been recovered walks away.

The second mistake is over-spending on the low-value cart. If your recovery message includes a discount or incentive, you are giving away margin that you did not need to lose. A 10% discount on an ₦8,000 cart costs you ₦800 per recovered sale. Apply that same discount to an ₦8,000 cart that would have converted with a simple reminder and no discount, and you have burned margin for no reason.

The most expensive mistake, however, is neither of these. It is the opportunity cost of running one sequence for all carts while your competitors run four sequences optimized by value tier. They recover more revenue from your shared customer base because they are speaking to each customer’s actual situation. You are speaking to an average that does not exist.

The Four Value Tiers Worth Building Distinct Logic For

Not every cart value needs its own sequence. Eight tiers is too many. Two tiers is too few. Four tiers is the sweet spot where the incremental revenue from additional segmentation no longer justifies the additional complexity.

Impulse tier: These purchases are low-friction, low-consideration decisions. The customer saw something they wanted and added it to cart. If they did not complete checkout, the reason is rarely financial. It is usually distraction, connectivity, or a minor objection. Recovery messages for this tier should be light, fast, and single-step. Do not ask questions. Do not offer multiple pathways. Send a simple reminder with a direct checkout link. If they do not convert after three messages, stop. The margin does not support extended sequences.

Considered tier: At this price point, the customer thinks before buying. They compare options. They check reviews. They may consult a friend or family member. Recovery messages for this tier should acknowledge the consideration. Use phrases like “still thinking about it?” rather than “you left something behind.” Provide information that helps the decision: customer reviews, product specifications, or styling recommendations. A small incentive may help, but do not lead with it. Lead with value. Use the discount only if the first two messages do not convert.

High-value tier: This is serious money for most Nigerian consumers. The customer is not casually browsing at this price point. They have a genuine need and a genuine budget constraint. Recovery messages for this tier should be respectful of both. Do not pretend that ₦120,000 is an impulse purchase. Acknowledge the investment. Offer to answer questions. Provide agent escalation as a clear option. Incentives at this tier should be structured as value-adds rather than discounts: free delivery, extended warranty, payment plan options. A percentage discount at this tier is expensive and often less effective than a well-framed value-add.

Premium tier: At this level, automated messaging is a handshake, not a conversation. The engine’s job is to initiate contact and then step aside for a human agent. Your first message should introduce an agent by name and invite a conversation. Your second message, if no response, should reinforce the agent’s availability. Do not send a third automated message. Do not send discount offers. Premium buyers are not price-driven. They are trust-driven, convenience-driven, and relationship-driven. Your engine cannot replace the relationship. It can only start it.

What Changes At Each Tier: Message Tone, Offer Strategy, Sequence Length, Agent Escalation Threshold, And Incentive Budget

Each tier requires a distinct configuration across five dimensions.

Dimension	Impulse Tier (Under ₦15,000)	Considered Tier (₦15,000 – ₦60,000)	High-Value Tier (₦60,000 – ₦150,000)	Premium Tier (Above ₦150,000)
Message Tone	Casual, energetic, low-stakes. “Hey! Your cart is still waiting for you.”	Thoughtful, helpful, informative. “Not sure if you had more questions about this item.”	Respectful, confident, solution-oriented. “I understand this is an important purchase. Happy to help with any questions.”	Personal, warm, agent-led. “Hi [name], I’m [agent name]. I saw you were looking at [product]. Let me know if you’d like to discuss.”
Offer Strategy	No offer, reminder only	Offer on third message only, capped at 5-7%	Value-add offers only (free delivery, extended warranty), no percentage discounts	No offers, relationship and convenience as the value proposition
Sequence Length	Three messages maximum	Four messages maximum	Three automated messages plus agent escalation	Two automated messages then agent escalation with no further automation
Agent Escalation Threshold	Never	Never (automated only)	Escalate on third message if customer has responded to any previous message	Escalate on first response; offer escalation even without response by including agent name and direct contact in the second message
Incentive Budget	₦0	Up to 5% of cart value, capped at ₦2,500	Value-adds valued at 3-5% of cart value but delivered as non-discount benefits	₦0 on discount; budget allocated to agent time and relationship management instead

Why Discount Offers Appropriate For A ₦9,000 Cart Destroy Margin On A ₦200,000 Cart

A 10% discount on a ₦9,000 cart costs ₦900 in margin. The product’s unit economics likely absorb this cost comfortably. The customer feels rewarded. The recovery is profitable. The same 10% discount on a ₦200,000 cart costs ₦20,000 in margin. Few products in Nigerian e-commerce have enough margin to absorb a ₦20,000 discount and remain profitable after factoring in delivery, payment gateway fees, and operational costs.

The operator who offers a 10% discount on both carts either loses money on every high-value recovery or has priced their products to absorb a discount that most customers were willing to pay full price for. Neither outcome is optimal.

For high-value and premium carts, the appropriate “discount” is often no discount at all. The appropriate incentive is a benefit that costs you little but provides the customer genuine value. Free delivery on a ₦200,000 cart costs you perhaps ₦5,000 to ₦10,000 depending on location. Extended warranty costs you nothing if the product has a low defect rate. A complimentary accessory costs you wholesale price plus storage.

These incentives preserve margin while still motivating recovery. More importantly, they signal to the premium customer that you understand the nature of their purchase. A percentage discount on a high-value item can feel cheap. A thoughtful value-add feels premium.

Category-Specific Segmentation Logic Within Value Tiers

Value tier is your primary segmentation axis. Category is your secondary axis. Two carts at the same price point may need different recovery logic if they belong to different categories.

Fashion at ₦40,000: The primary abandonment driver is size and fit anxiety. Recovery messages should address this directly: “Not sure about sizing? Our size guide is here, and returns are easy.” A secondary driver is style consultation: “Would you like to see how this looks styled with other pieces?” Agent escalation is useful here but not urgent.

Electronics at ₦40,000: The primary abandonment driver is specification comparison and price checking. Recovery messages should provide technical information: “Here is the full spec sheet compared to similar models.” Price-match assurance matters: “If you find this cheaper elsewhere, let us know.” Agent escalation is highly useful at this price point for electronics, more so than fashion at the same value.

Beauty at ₦40,000: The primary abandonment driver is ingredient research and review checking. Recovery messages should lead with social proof: “Here are reviews from customers with similar skin types.” Samples or travel sizes as an incentive work well. Agent escalation should connect the customer to a beauty advisor, not a general customer service agent.

Food at ₦40,000: This is a bulk order or special occasion purchase. The primary abandonment driver is delivery timing and freshness guarantees. Recovery messages should address both: “We can deliver on [date] and freshness is guaranteed.” The urgency window for food is compressed. Delay logic should be shorter than other categories at the same tier.

Stateful Customer Records Vs Stateless Automation Systems

Stateless automation fires when a trigger condition is met and does not remember what came before.

You configure a workflow. You set a trigger. When the trigger condition evaluates to true, the workflow executes its actions and ends. The system does not check whether this contact has triggered the same workflow six times this month. It does not check whether the contact converted five minutes ago through a different channel. It does not check whether the contact is currently active in another workflow.

It fires, sends, and forgets.

Stateless systems are simple to configure. They are also dangerous for cart abandonment recovery because the absence of memory produces damaging failure patterns at scale.

What Stateless Automation Cannot Do

A stateless system cannot answer these questions before sending a message:

• Has this contact already converted since this cart abandonment event occurred?
• Is this contact currently in an active conversation with a live agent?
• Did this contact receive a message from a different campaign thirty minutes ago?
• Has this contact already seen and ignored three abandonment sequences this month?
• Did this contact opt out of marketing messages yesterday?

Because stateless systems cannot answer these questions, they send messages when they should remain silent. The damage from these unnecessary messages accumulates over time. Each message sent to a customer who already converted erodes trust. Each message sent to an opted-out contact increases the likelihood of deliverability issues. Each message sent during an active agent conversation confuses the customer and undermines the agent.

What Stateful Automation Does

Stateful automation checks the contact’s history before every action.

When a cart abandonment event arrives, the stateful system looks at the contact record and asks:

• What is the timestamp of the last conversion event for this contact?
• Is that timestamp after the abandonment event timestamp?
• What is the current active sequence flag for this contact?
• What is the opt-out status for this contact?
• When was the last message sent to this contact across any campaign?

Only after evaluating these fields does the system decide whether to send a message.

Stateful systems are more complex to configure. They require careful design of contact record fields and conditional logic that checks those fields before every action. But for cart abandonment recovery at scale, statefulness is not optional. It is the difference between a system that respects your customers and a system that annoys them.

Why Stateless Systems Produce The Most Damaging WhatsApp Automation Failures

The failures caused by stateless automation follow predictable patterns. Each pattern is avoidable. Each pattern damages customer trust.

Messaging a customer who converted two hours ago through Instagram. The customer abandoned a cart on your website. They later purchased the same product through your Instagram store. Your website webhook never fired because the purchase happened off your storefront. A stateless system sees the abandonment event and sends the recovery message. The customer receives “You left something behind” two hours after they already paid. The message is incorrect, irritating, and signals that your systems are disconnected.

Re-entering a customer into abandonment recovery after they already completed checkout. The customer abandoned a cart on Monday. They returned on Tuesday and completed checkout through your website. The conversion webhook fired. Your system received it. But a stateless system has no mechanism to prevent re-entry if a second abandonment event arrives. If the customer adds a different item to cart on Wednesday and abandons it, a stateless system may treat them as a fresh abandonment without checking that they are already a confirmed customer. The recovery sequence sends. The customer is confused.

Sending a first-touch message to a contact who is already in a post-purchase sequence. The customer abandoned a cart. Before your recovery sequence sends, they complete a different purchase through a different channel. Your post-purchase sequence triggers, sending order confirmation and delivery updates. Your stateless abandonment system, unaware of the post-purchase sequence, sends its first recovery message. The customer now receives two streams of messages from your brand simultaneously. One assumes they have not purchased. One assumes they have. This contradiction damages credibility.

The Contact Record Fields That A Stateful Cart Recovery Engine Requires

To achieve statefulness, your contact records must store and update specific fields. These fields are the memory your engine relies on.

Last cart event timestamp: The timestamp of the most recent cart abandonment event for this contact. Used to determine whether a conversion event occurred before or after the abandonment.

Last conversion timestamp: The timestamp of the most recent completed purchase for this contact, regardless of channel. Updated whenever a conversion webhook arrives.

Active sequence flag: A boolean field indicating whether the contact is currently enrolled in any active sequence. Used to prevent concurrent enrollment in overlapping workflows.

Opt-out status: A boolean field indicating whether the contact has unsubscribed from marketing communications. Checked before every marketing message.

Last message sent timestamp: The timestamp of the most recent message sent to this contact across any campaign. Used for frequency suppression.

Lifetime order count: The total number of orders this contact has completed. Used to differentiate new customers from repeat customers for messaging strategy.

In Siteti, these fields are part of the standard contact record and are updated automatically when events are received. When building conditional logic, you can reference any of these fields to determine whether a message should send.

How Siteti Manages Contact State Across Concurrent Workflows

Siteti maintains contact state at the platform level, not the workflow level. This means that any workflow can access the same contact record and see updates made by any other workflow.

When a conversion webhook arrives, Siteti updates the last conversion timestamp on the contact record. Any active abandonment workflow that checks this field before sending its next message will see the update and can suppress further messaging.

When an agent marks a conversation as active, Siteti sets a flag on the contact record. Any automated workflow that checks for active agent conversations before sending will see the flag and wait.

This shared state layer is what enables concurrent workflows to operate without conflicting. Your cart abandonment workflow does not need to know about your post-purchase workflow. It only needs to check the contact record fields that the post-purchase workflow updates.

Building State Checks Into Your Siteti Automation: The Conditional Logic Configuration Before Any Abandonment Message Fires

In Siteti, every message send node should be preceded by a conditional logic node that evaluates the contact’s state. The condition checks, in order:

1. Is opt-out status false? If the contact has opted out, exit the sequence immediately. Do not send.
2. Is last conversion timestamp after last cart event timestamp? If yes, the contact has already converted since this abandonment occurred. Exit the sequence.
3. Is active agent conversation flag false? If the contact is currently in a live agent conversation, do not send automated messages. Wait or exit.
4. Is time since last message sent greater than frequency threshold? Set your frequency threshold based on your brand’s tolerance for messaging density. A common threshold is 6 hours for marketing messages. If the last message sent is within the threshold, delay or skip.

If all four conditions pass, the message sends.

Here is how this conditional logic is configured in Siteti:

Node 1: Condition Check

• If opt_out_status equals true → Exit sequence
• If last_conversion_timestamp is greater than last_cart_event_timestamp → Exit sequence
• If active_agent_conversation equals true → Wait 30 minutes and recheck
• If last_message_sent_timestamp is within last 6 hours → Wait 2 hours and recheck
• Else → Proceed to Send Message node

Node 2: Send Message (only reached if all conditions pass)

Node 3: Update Contact Record (after message sends, update last_message_sent_timestamp to current time)

This configuration ensures that no message sends unless the contact’s state makes sending appropriate. The checks run before every message, not only at sequence entry. This matters because a contact’s state can change between message one and message two of the same sequence.

 Multi-Session Attribution Across WhatsApp And Web Checkout Journeys

Standard web analytics operate on a simple assumption: the last channel that brought the customer to your website before conversion gets the credit.

The customer clicks a Google ad. They land on your site. They purchase. Google Ads gets the attribution credit.

This model breaks completely for WhatsApp cart recovery because the customer journey does not end with a click from WhatsApp to your website. It often continues through multiple sessions, multiple devices, and multiple channels before conversion finally occurs.

Consider this real journey:

The customer abandons a cart on your website on Monday evening. On Tuesday morning, they receive a WhatsApp recovery message. They click the link, return to the site, look at the cart, and close the tab without purchasing. On Tuesday afternoon, they open their banking app, initiate a transfer to your account using details they saved from a previous purchase, and complete payment without ever returning to your website.

Where does attribution belong?

The WhatsApp message assisted the conversion. The customer returned to the site because of the message, even though they did not purchase during that session. The final conversion happened through a bank transfer with no click from WhatsApp. Standard last-click attribution would give credit to Direct traffic or to nothing at all. The WhatsApp touchpoint would receive zero attribution credit despite being the reason the customer re-engaged with your brand.

This is why WhatsApp-assisted recovery requires multi-session attribution models that track influence across time, not just last click.  Proper attribution is the final piece of any mature WhatsApp Cart Abandonment Recovery for E-commerce strategy.

The Three Attribution Models Worth Understanding For WhatsApp Cart Recovery

Last-touch attribution gives 100% of conversion credit to the last channel the customer interacted with before converting. This model is simple and widely supported but systematically undervalues WhatsApp recovery because customers often convert through bank transfer, USSD, or direct site visits that do not register as a WhatsApp click in your analytics.

First-touch attribution gives 100% of conversion credit to the first channel that brought the customer into your ecosystem. This model overvalues top-of-funnel channels and cannot measure the specific contribution of recovery messages later in the customer journey.

Assisted conversion attribution gives partial credit to every touchpoint that influenced the customer before conversion. In Google Analytics 4, assisted conversions are tracked through the conversion path report. A WhatsApp recovery message that leads to a site visit, followed by a bank transfer conversion days later, would appear as an assisted conversion. The WhatsApp touchpoint receives credit for its role in re-engaging the customer, even though it was not the last click.

For WhatsApp cart recovery, the assisted conversion model is the most accurate. Your recovery messages are rarely the last click before purchase. They are the reason the customer returned to the purchase journey after abandoning. Attribution models that only reward last click will underreport your recovery ROI and lead you to underinvest in a channel that is actually driving substantial revenue.

How To Build UTM Parameters Into WhatsApp Recovery Message Links That Survive The Checkout Journey

UTM parameters are the standard way to track the source of traffic to your website. For WhatsApp recovery messages, the challenge is ensuring that UTM parameters persist through the entire checkout journey, including when customers leave and return.

The structure of a recovery message link with UTM parameters:

https://yourstore.com/cart/checkout?utm_source=whatsapp&utm_medium=crm&utm_campaign=cart_abandonment&utm_content=tier_considered_message_1

Each parameter serves a specific purpose:

• utm_source=whatsapp identifies the messaging platform
• utm_medium=crm identifies the automation type
• utm_campaign=cart_abandonment identifies the campaign family
• utm_content=tier_considered_message_1 identifies the specific message position and tier

To ensure these parameters survive the checkout journey, your website must be configured to preserve UTM parameters across page navigation and through the checkout funnel. Most modern e-commerce platforms preserve URL parameters by default, but bank transfer and USSD flows often drop them because the customer leaves your site entirely.

For bank transfer and USSD conversions where the customer leaves your site, include the UTM parameters in the payment instructions they see before leaving. If the customer must return to your site to confirm payment, the return URL should include the original UTM parameters. This requires custom implementation on your storefront but is essential for accurate attribution of WhatsApp-assisted conversions.

Connecting Siteti Message Delivery And Click Data To Your Web Analytics

Siteti tracks message delivery, read status, and link clicks at the individual contact level. To connect this data to your web analytics, you need to pass Siteti identifiers into your UTM parameters and ensure your analytics platform captures them.

The recommended integration approach:

1. In your Siteti message template, include dynamic UTM parameters that pull from the contact record. Example: utm_campaign=cart_abandonment&utm_siteti_contact={{contact.id}}&utm_siteti_message={{message.id}}
2. When the customer clicks the link, these parameters are passed to your website.
3. Your web analytics platform (Google Analytics 4 or Meta Pixel) captures the parameters as part of the pageview.
4. When conversion occurs, the conversion event includes the UTM parameters from the original click, even across multiple sessions.

For Google Analytics 4 specifically, enable cross-domain measurement and ensure that your checkout confirmation page is configured to capture UTM parameters from the original source. If the customer leaves and returns, the parameters should persist. If they do not, GA4 will attribute the conversion to Direct traffic and your WhatsApp recovery will appear less effective than it actually is.

What To Do When The Customer Converts Via Bank Transfer Or USSD

Bank transfer and USSD conversions present the hardest attribution problem because the customer never returns to your website after initiating payment.

The customer receives your WhatsApp recovery message, clicks the link, views their cart, selects bank transfer as payment method, sees your account details, opens their banking app, sends the payment, and closes both apps. The conversion happened entirely off your website. Your web analytics platform never saw a conversion event.

The solution is a manual or automated reconciliation layer that connects off-web payments to WhatsApp touchpoints.

In Siteti, you can build this reconciliation by:

1. Capturing the payment reference or transaction ID from the bank transfer confirmation (either through a webhook from your payment gateway or through manual entry by your finance team)
2. Matching that transaction to a contact record using the amount, approximate timestamp, and customer name
3. Manually or automatically marking that contact as converted and updating the last conversion timestamp
4. Ensuring that the suppression check references this manually updated conversion timestamp

Without this reconciliation layer, customers who convert via bank transfer or USSD will continue to receive abandonment messages after they have already paid. The post-conversion suppression described in Part Six depends on the conversion timestamp being accurate for all payment methods, not only web-based ones.

Building A Manual Reconciliation Layer That Does Not Require A Developer

For lean teams without dedicated engineering resources, manual reconciliation is the most practical approach.

Create a weekly process:

1. Export a list of all bank transfer and USSD payments received in the last seven days from your payment gateway or bank statement.
2. Export a list of all WhatsApp recovery messages sent in the same period from Siteti.
3. Match payments to contacts using amount, approximate timestamp, and customer phone number (if captured during the payment process).
4. For matched contacts, update the conversion timestamp in Siteti manually using the contact record edit interface.
5. Verify that the updated conversion timestamp is earlier than the abandonment timestamp for any carts that were recovered. If the conversion happened after the abandonment but before the first recovery message, that is a successful assisted conversion.

This manual process takes thirty to sixty minutes per week for a brand doing several hundred cart initiations per month. As volume grows, you will need to automate the reconciliation. But at growth-stage volume, manual reconciliation is viable and far better than no reconciliation at all.

The Attribution Metrics That Actually Matter For Recovery ROI

Attribution exists to answer one question: is my cart abandonment engine generating positive return on investment?

To answer that question, track these four metrics in Siteti and your analytics platform.

Recovered revenue per sequence: The total revenue from conversions attributed to each specific recovery sequence, divided by the number of contacts who entered that sequence. This tells you whether your tier-specific sequences are performing as expected.

Cost per recovered cart by value tier: The total cost of running the recovery engine (platform fees, agent time for escalations, incentives offered) divided by the number of carts recovered in each tier. This tells you whether the margin on recovered carts exceeds the cost of recovery.

Sequence drop-off rate by step: The percentage of contacts who receive each message in a sequence but do not proceed to the next message or convert. A high drop-off rate after message two suggests that message two is ineffective or that the delay between message one and message two is too long.

Suppression rate by condition: The percentage of potential messages that are suppressed by each suppression condition. A high post-conversion suppression rate tells you that your conversion webhook is working and catching conversions before messages send. A high frequency suppression rate suggests that you are messaging customers too often across your campaigns.

Review these metrics weekly: If recovered revenue per sequence declines, investigate your suppression rates and drop-off rates first. The problem is rarely the message copy. It is almost always timing, suppression, or segmentation.

Recovery Benchmarks Across Fashion, Food, Beauty, And Electronics Verticals

Why Vertical Benchmarks Matter More Than General E-Commerce Averages

A general e-commerce cart abandonment benchmark tells you very little. If an aggregate study says the average recovery rate is 12%, and your fashion brand is recovering 10%, you might think you are underperforming. But fashion recovery rates are typically lower than the e-commerce average because sizing anxiety and style hesitation create friction that a WhatsApp message cannot easily resolve.

If the same study says the average recovery rate is 12%, and your food brand is recovering 10%, you are actually significantly underperforming. Food recovery rates are typically higher than the e-commerce average because the purchase window is compressed and hunger is a persistent motivator.

Vertical benchmarks give you a realistic target. They tell you what good looks like for your specific category, not for e-commerce as a whole.

The benchmarks below are drawn from observed performance across Nigerian e-commerce operators using Siteti. Your actual recovery rates will vary based on your average order value, customer quality, message quality, and suppression configuration. Use these benchmarks as directional targets, not absolute promises.

Vertical Comparison Table

Dimension	Fashion	Food & FMCG	Beauty	Electronics
Primary Abandonment Driver	Size uncertainty, style hesitation	Short hunger window, delivery timing	Research behavior, ingredient checking, review reading	Comparison shopping, price anxiety, salary timing
Recovery Message Focus	Confidence building, size guides, easy returns, “still in stock”	Urgency (delivery slots, closing times), real-time relevance	Information provision, reviews, ingredients, influencer social proof	Price matching, specifications, agent introduction
Recommended Delay Windows	4hrs / 24hrs / 48hrs	1hr / 3hr / 6hrs (no fourth message)	6hrs / 24hrs / 48hrs / 96hrs	24hrs / 48hrs / 96hrs
Discount Offer Strategy	Avoid discounts above ₦30k; gentle scarcity works better	Highly effective; builds relationship for repeat orders	Use carefully; free samples better than discounts	Ineffective below 10%, destructive above 10%; use value-adds instead
Agent Escalation Role	Low; mostly automated	Low; window too short for meaningful agent intervention	Medium; beauty advisor conversations add value	High; primary recovery lever above ₦80k
Typical Recovery Rate	8-12% (under ₦30k); 5-8% (above ₦30k)	15-22% (under ₦15k); 10-15% (above ₦15k)	10-15% across all tiers	6-10% (under ₦100k); 3-6% (above ₦100k)
What Makes Recovery Hard	Confidence cannot be forced; customers need time	Window closes within hours; competitors are one click away	Research happens off your storefront; you cannot control it	Purchase is infrequent, high-stakes, and heavily compared

Cross-Vertical: The Universal First-Message Principle

Across every vertical, one principle holds: the first message should ask a question, not make an offer.

A first message that leads with a discount trains customers to wait for discounts before purchasing. They learn that abandoning a cart generates a coupon. This behavior spreads. Your recovery rates may initially look good, but your baseline conversion rates will decline as customers learn to game the system.

A first message that asks a question — “Was there something that stopped you from completing your order?” — opens a conversation. Some customers will reply. Those replies can be routed to agents who can resolve objections in real time.

The universal principle is this: question first, offer second, and only after the customer has shown they need an offer to convert.

Step-By-Step Siteti Workflow Implementation Blueprint

Before you build a single workflow node, confirm that the following components are installed, configured, and tested.

Storefront requirements:

• Your Shopify, WooCommerce, or custom storefront must be able to send webhooks for cart abandonment events
• Your storefront must capture customer phone numbers at or before checkout initiation
• Your storefront must be able to send conversion webhooks when a purchase is completed (including off-web payments if possible)

WhatsApp Business API requirements:

• An approved WhatsApp Business API provider with webhook reception capability
• Approved message templates for cart abandonment recovery (at least one template per value tier)
• Sufficient message quota for your expected recovery volume

Siteti requirements:

• A Siteti account with automation workflow access
• Webhook receiver configured and accessible
• Contact record fields populated with the state fields described in Part Five
• Suppression rules configured as described in Part Six

Do not proceed until each of these prerequisites is confirmed. The most common implementation failures come from missing prerequisites, not from incorrect workflow configuration.

Step One: Configuring The Cart Abandonment Webhook From Your Storefront To Siteti

The webhook is the entry point of your entire engine. If events do not arrive, nothing else works.

In your storefront:

For Shopify:

1. Navigate to Settings > Notifications > Webhooks
2. Click “Create webhook”
3. Event: “Checkout updated” (captures more data than “Cart updated”)
4. Format: JSON
5. URL: Copy from your Siteti webhook receiver (created in the next step)
6. Click “Save”

For WooCommerce:

1. Navigate to WooCommerce > Settings > Advanced > Webhooks
2. Click “Add webhook”
3. Name: “Cart Abandonment to Siteti”
4. Topic: “Cart updated”
5. Delivery URL: Copy from your Siteti webhook receiver
6. Secret: Optional but recommended
7. Click “Save webhook”

In Siteti:

1. Navigate to Automation > Webhook Receivers
2. Click “Create Webhook Receiver”
3. Name: “WooCommerce Cart Abandonment” (or your storefront name)
4. Copy the generated webhook URL to your storefront
5. Set the receiving workflow to “Cart Abandonment Engine”
6. Click “Save”

Example payload structure your storefront should send:

json

{

  “cart_id”: “cart_abc123”,

  “customer”: {

    “phone”: “2348012345678”,

    “email”: “customer@example.com”

  },

  “cart_value”: 45000,

  “cart_items”: [

    {

      “product_id”: “prod_001”,

      “name”: “Women’s Summer Dress”,

      “quantity”: 1,

      “price”: 45000

    }

  ],

  “checkout_step”: “payment_method_selected”,

  “abandonment_timestamp”: “2025-05-14T14:30:00Z”,

  “checkout_url”: “https://yourstore.com/checkout/abc123”

}

Test the webhook by triggering a test abandonment on your storefront and verifying that the event appears in Siteti’s Activity Log.

Step Two: Building The Contact Identity Match And Cart Value Classification Logic

Once the webhook delivers an event, Siteti must match it to a contact and classify the cart.

Identity match configuration:

1. Add a “Find Contact” node after your webhook trigger
2. Set the match condition: whatsapp_phone equals {{webhook.payload.customer.phone}}
3. If match found: Store the contact ID as a variable and proceed
4. If no match found: Log the event as “unrecoverable – no contact” and exit the workflow

Cart value classification configuration:

1. Add a “Condition” node after the identity match
2. Create four branches based on {{webhook.payload.cart_value}}:

Branch	Condition	Tier Assignment
Branch 1	cart_value < 15000	Impulse Tier
Branch 2	cart_value between 15000 and 60000	Considered Tier
Branch 3	cart_value between 60000 and 150000	High-Value Tier
Branch 4	cart_value > 150000	Premium Tier

3. 
   For each branch, add a “Set Variable” node that stores the tier value
4. Also store the cart value, abandonment timestamp, and checkout step for use in later nodes

Step Three: Configuring The Suppression Check As The First Node In Every Recovery Workflow

Before any message sends, suppression must run. This node should be placed immediately after classification, before any delay or message nodes.

Suppression check configuration:

Add a “Condition” node that evaluates the following checks in order:

Check Order	Condition	Action If True
1	opt_out_status equals true	Exit workflow, log “suppressed – opt out”
2	last_conversion_timestamp is greater than abandonment_timestamp	Exit workflow, log “suppressed – post conversion”
3	active_agent_conversation equals true	Wait 30 minutes, then recheck from start
4	last_message_timestamp is within last 6 hours	Wait 2 hours, then recheck from start

If all checks pass, proceed to the delay and message sequence.

This suppression check must be repeated before every message in the sequence, not only before the first message. To achieve this, copy the same condition node before each Send Message node in your workflow.

Step Four: Building The Delay Sequence For Each Value Tier With Specific Timing Parameters

Create a separate workflow branch for each tier. Do not try to build one sequence that handles all tiers with conditional delays. Separate branches are easier to test, debug, and modify.

Impulse tier sequence (under ₦15,000):

Step	Node Type	Configuration
1	Wait	2 hours
2	Suppression Check	Same as Step Three configuration
3	Send Message	Impulse Tier Message 1 template
4	Wait	22 hours (cumulative 24)
5	Suppression Check	Same configuration
6	Send Message	Impulse Tier Message 2 template
7	Wait	48 hours (cumulative 72)
8	Suppression Check	Same configuration
9	Send Message	Impulse Tier Message 3 template
10	Exit	End sequence, no further messaging

Considered tier sequence (₦15,000 – ₦60,000):

Step	Node Type	Configuration
1	Wait	4 hours
2	Suppression Check	Same configuration
3	Send Message	Considered Tier Message 1 template
4	Wait	20 hours (cumulative 24)
5	Suppression Check	Same configuration
6	Send Message	Considered Tier Message 2 template
7	Wait	24 hours (cumulative 48)
8	Suppression Check	Same configuration
9	Send Message	Considered Tier Message 3 template
10	Wait	48 hours (cumulative 96)
11	Suppression Check	Same configuration
12	Send Message	Considered Tier Message 4 template
13	Exit	End sequence

High-value tier sequence (₦60,000 – ₦150,000):

Step	Node Type	Configuration
1	Wait	24 hours
2	Suppression Check	Same configuration
3	Send Message	High-Value Tier Message 1 template
4	Wait	24 hours (cumulative 48)
5	Suppression Check	Same configuration
6	Send Message	High-Value Tier Message 2 template
7	Wait	48 hours (cumulative 96)
8	Suppression Check	Same configuration
9	Send Message	High-Value Tier Message 3 template
10	Agent Escalation	Assign to agent queue if customer has responded to any message
11	Exit	End automated sequence

Premium tier sequence (above ₦150,000):

Step	Node Type	Configuration
1	Wait	48 hours
2	Suppression Check	Same configuration
3	Send Message	Premium Tier Message 1 (agent-introducing) template
4	Wait	48 hours (cumulative 96)
5	Suppression Check	Same configuration
6	Send Message	Premium Tier Message 2 (agent follow-up) template
7	Agent Escalation	Assign to agent queue regardless of response status
8	Exit	End automated sequence

Step Five: Writing The Message Templates For Each Sequence Step By Tier

The exact copy is yours to write based on your brand voice. The structural approach below tells you what each message should contain.

Impulse Tier Message 1 (2 hours):

• Casual, energetic greeting
• Reminder of what was left (product name or image)
• Direct checkout link
• No question, no offer

Impulse Tier Message 2 (24 hours):

• Friendly check-in
• Brief social proof (one short review or rating)
• Checkout link again
• Still no offer

Impulse Tier Message 3 (72 hours):

• Final reminder
• Small incentive (5-7% discount) with expiration
• Checkout link
• Clear statement that this is the last message

Considered Tier Message 1 (4 hours):

• Thoughtful opening acknowledging consideration
• Question: “Was there something you wanted to know about this item?”
• Checkout link
• No offer

Considered Tier Message 2 (24 hours):

• Helpful framing
• Additional information (size guide, specs, or FAQ answer relevant to product)
• Checkout link
• Still no offer

Considered Tier Message 3 (48 hours):

• Social proof focus
• Two to three customer reviews
• Checkout link
• Still no offer

Considered Tier Message 4 (96 hours):

• Final message
• Small incentive (5-7% discount) with 24-hour expiration
• Checkout link
• Clear exit

High-Value Tier Message 1 (24 hours):

• Respectful, confident tone
• Acknowledgment of purchase importance
• Offer to answer questions
• Checkout link
• No discount

High-Value Tier Message 2 (48 hours):

• Value-add framing (free delivery, extended warranty)
• Checkout link
• Still no discount

High-Value Tier Message 3 (96 hours):

• Agent introduction
• Specific agent name and contact method
• No automated checkout link in this message
• Invitation to conversation

Premium Tier Message 1 (48 hours):

• Personal, warm, agent-led
• “Hi [name], I’m [agent name]”
• Acknowledgment of specific product in cart
• Offer to discuss, answer questions, or provide additional information
• No checkout link, no discount

Premium Tier Message 2 (96 hours):

• Follow-up from same agent
• Reinforcement of availability
• Gentle reminder of product
• No checkout link, no discount
• Clear invitation to reply

Step Six: Configuring The Conversion Detection Webhook That Triggers Suppression

The conversion webhook tells Siteti when a customer has completed a purchase so that active abandonment sequences can be suppressed.

In your storefront:

Configure a webhook that fires when an order is completed. The payload must include the customer’s phone number.

Example conversion webhook payload:

json

{

  “order_id”: “order_xyz789”,

  “customer”: {

    “phone”: “2348012345678”,

    “email”: “customer@example.com”

  },

  “order_value”: 45000,

  “conversion_timestamp”: “2025-05-14T15:45:00Z”,

  “payment_method”: “bank_transfer”

}

In Siteti:

1. Create a second webhook receiver named “Conversion Events”
2. In the workflow connected to this receiver, add an “Update Contact” node
3. Configure the node to set last_conversion_timestamp to the current timestamp
4. Also set active_sequence_flag to false (exits contact from any active sequence)
5. Add a “Log Event” node to record the conversion for attribution reporting

Once this webhook is configured and tested, any active abandonment sequence will suppress future messages when the suppression check compares last_conversion_timestamp to abandonment_timestamp.

Step Seven: Setting Up The Attribution UTM Structure For WhatsApp Recovery Links

UTM parameters enable you to measure which recovery messages drive which conversions.

In each Send Message node that contains a checkout link:

Structure the link as follows:

https://yourstore.com/checkout/{{cart_id}}?utm_source=whatsapp&utm_medium=crm&utm_campaign=cart_abandonment&utm_content={{tier}}_{{message_position}}

Where:

• {{tier}} = impulse, considered, high_value, or premium
• {{message_position}} = msg1, msg2, msg3, or msg4

Example for considered tier message 2:

https://yourstore.com/checkout/cart_abc123?utm_source=whatsapp&utm_medium=crm&utm_campaign=cart_abandonment&utm_content=considered_msg2

In Google Analytics 4:

Create a custom report that filters by utm_source=whatsapp and utm_campaign=cart_abandonment. Group by utm_content to see which tier and message position generates the most conversions.

Step Eight: The Pre-Launch Test Protocol — Eight Scenarios To Simulate Before Going Live

Run each test scenario with a real test contact before enabling the engine for live customers.

Test	Scenario	Expected Outcome
1	Abandon impulse tier cart, do not convert	Receive all 3 messages at correct intervals
2	Abandon considered tier cart, do not convert	Receive all 4 messages at correct intervals
3	Abandon high-value tier cart, do not convert	Receive 3 messages, agent escalation on message 3
4	Abandon premium tier cart, do not convert	Receive 2 messages, agent escalation regardless
5	Abandon cart, then convert via web before first message sends	No abandonment messages received
6	Abandon cart, receive message 1, then convert via web before message 2	Message 2 suppressed, no further messages
7	Abandon cart while contact has opt-out=true	No messages received, suppression logged
8	Abandon cart while contact is in active agent conversation	No messages received until conversation ends

Do not proceed to launch until all eight tests pass.

Step Nine: The Weekly Review Metrics That Tell You Whether The Engine Is Working Or Degrading

Once live, review these metrics in Siteti every week.

In Siteti Analytics:

Metric	What It Tells You	Warning Sign
Events received vs contacts matched	Identity resolution rate	Match rate below 60%
Messages sent vs suppressed	Suppression effectiveness	Suppression rate below 2% (means you are missing conversions)
Recovery rate by tier	Tier performance	Recovery rate drop of more than 30% week over week
Drop-off rate by message position	Sequence engagement	More than 50% drop-off between message 1 and 2

In your storefront analytics (with UTM tracking):

Metric	What It Tells You	Warning Sign
Recovered revenue by tier	ROI per segment	Tier with highest AOV has lowest recovery
Conversion rate by message position	Message effectiveness	Message 1 converting better than message 2 suggests delay too long
Assisted conversions from WhatsApp	True recovery ROI	Assisted conversions declining while last-click conversions flat

Weekly review checklist:

1. Pull the suppression log. Are any suppression conditions firing unexpectedly?
2. Check identity match rates. Is your storefront capturing phone numbers correctly?
3. Review recovery rates by tier. Is premium tier recovering at all? If not, shorten the first-message window.
4. Test the webhooks manually. Are events still arriving?
5. Review agent escalation logs. Are agents responding to escalated contacts quickly enough?

Conclusion

A properly built cart abandonment engine compounds its value over time. Every recovered cart adds revenue that required no additional traffic spend. Every suppression check that fires prevents a customer annoyance that would have eroded trust. Every sequence that routes correctly delivers the right message at the right time without agent intervention.

The manual follow-up approach does the opposite. It diminishes returns as volume grows. Agents become overwhelmed. Response times lengthen. Customers who converted hours ago receive messages that confuse them. The system works less well every month, not better.

The one thing most operators skip that causes the entire system to fail is suppression architecture. They build the messages. They configure the delays. They set up the webhooks. But they do not build the conditional logic that checks whether a customer has already converted before sending a message. Then the first post-conversion message goes out, a customer complains, and the operator decides WhatsApp automation “does not work” when the failure was not the channel but the missing suppression check.

Building this infrastructure now, before volume makes the absence painful, is the correct sequencing decision. The cost of building suppression logic into a new workflow is trivial. The cost of adding suppression to a broken workflow that has been annoying customers for six months is customer churn and lost trust that cannot be bought back.

The operators who will dominate Nigerian e-commerce in the next three years are building differently today. They are not asking which message template converts best. They are asking how to orchestrate events, identity, segmentation, timing, and suppression into a system that respects customers while recovering revenue. They understand that the message is the visible part, but the infrastructure beneath it is what separates scalable recovery from broadcast spam.

Siteti provides the infrastructure layer for this architecture. The platform handles webhook reception, contact state management, suppression checks, delay execution, and agent escalation routing. Your job as an operator is not to build these primitives from scratch. Your job is to configure them into the sequences that match your customers, your categories, and your commercial reality, and then to make the commercial decisions the engine cannot make for you: which incentives to offer, which verticals to prioritize, and when to escalate to a human conversation.

The engine recovers revenue. You run the business. That is the division of labor that scales.