Why reward delivery fails silently in Africa — and how to debug it

Your programme dashboard shows a 95% delivery rate. Your redemption rate is 28%. The gap between those two numbers is silent failure — rewards technically sent but never received, delivered to the wrong channel, or arriving in a state the recipient can't act on. Here's every failure mode, how to identify it, and how to fix it.

Silent delivery failure is the most expensive problem in African reward programmes because it's invisible. The platform reports delivery. The budget is spent. The behaviour change never happens. Nobody knows why the programme isn't working because the data says it is.

The gap between "delivered" and "redeemed" is where programmes leak value. In a well-configured programme, delivery rates above 95% should produce redemption rates above 65%. When delivery is high but redemption is low, something in the delivery chain is wrong — and "delivered" means something different than the recipient actually receiving and being able to use their reward.

Failure mode 1: WhatsApp delivery to non-WhatsApp numbers

WhatsApp delivery is reported as "sent" by the WhatsApp Business API the moment the message is sent to the platform. If the recipient's number is not registered on WhatsApp, the message enters a queue and eventually fails — but the sending system has already recorded it as sent. The recipient receives nothing.

In Nigerian programmes, the proportion of target phone numbers not registered on WhatsApp can be 30–50% depending on the recipient demographic. A mass-market FMCG programme targeting informal trade channel participants may have a majority of recipients on feature phones with no WhatsApp.

How to identify: compare WhatsApp "sent" count to WhatsApp "delivered" count (two-tick confirmation). The gap is your silent failure rate. How to fix: implement automatic fallback — if WhatsApp delivery is not confirmed within 60 seconds, automatically retry via SMS.

Failure mode 2: SMS delivery to inactive or ported numbers

Phone number churn in African markets is higher than in developed markets. Prepaid numbers that go unused for 90+ days are frequently recycled by operators and reassigned to new subscribers. Your customer database may contain phone numbers that now belong to different people.

An SMS delivery to a recycled number is reported as delivered by the SMS gateway — because it technically was delivered, to whoever now has that number. The original customer received nothing. A stranger received a reward card notification that means nothing to them (and may be redeemable by them, depending on programme design — an additional fraud surface).

How to identify: implement HLR (Home Location Register) lookups to verify number activity before sending, especially for customer databases that haven't been updated in 6+ months. How to fix: require periodic phone number re-verification for programme participants, and implement recipient confirmation mechanics that ensure the person redeeming the reward is the intended recipient.

Failure mode 3: USSD session timeout before completion

USSD sessions in African networks have a hard timeout — typically 180 seconds, sometimes shorter on congested networks. If a recipient initiates a reward redemption USSD session and doesn't complete it within the timeout, the session terminates. Depending on programme design, the reward may be marked as "redeemed" (because the session started) even though the recipient never actually got their code.

This failure mode is invisible in systems that track session initiation as redemption. The recipient calls the support line saying they never got their reward. The system shows it was redeemed. Neither is wrong — the session happened, the reward was released to the session, but the session timed out before the code was displayed.

How to fix: only mark a reward as redeemed when the final screen of the USSD session — the one displaying the redemption code — is confirmed delivered. Send a follow-up SMS with the redemption code immediately after the USSD session completes, so the recipient has a permanent record that survives session expiry.

Failure mode 4: Correct delivery, wrong category

Reward cards configured with a category that has low relevance to the recipient demographic are delivered successfully and then not redeemed — not because of a technical delivery failure, but because the recipient doesn't want what they've been given. This looks like a delivery success and a redemption failure, but the root cause is catalogue mismatch.

In mass-market Nigerian programmes, rewards configured with electronics or travel categories see dramatically lower redemption than equivalent rewards with grocery or connectivity categories. The delivery "worked." The programme didn't.

How to identify: segment redemption rates by reward category. If grocery rewards have 75% redemption and electronics rewards have 20% redemption among the same recipient cohort, the category is the variable. How to fix: offer category choice where possible, or configure categories to match the recipient demographic based on your customer data.

Failure mode 5: Value too low to motivate redemption

Rewards below the effective minimum value for a market and programme type are technically delivered and technically available for redemption. Recipients receive the notification, assess the effort required to redeem, decide it's not worth it, and move on. Delivery: 100%. Redemption: near zero.

In Nigeria, this failure point is around ₦500 for consumer promotions — below that, the USSD or WhatsApp redemption steps cost more in time and attention than the reward is worth. In South Africa, the equivalent threshold is around R30–R50.

Failure mode 6: Network operator delivery failures

SMS and USSD delivery in African markets has higher failure rates than in developed markets — network congestion, intermittent coverage, operator maintenance windows. A message sent at 2pm in Lagos on a weekday during peak network usage will have lower delivery success than the same message sent at 6am.

Most SMS gateway dashboards report aggregate delivery rates that obscure these timing and operator patterns. A programme averaging 82% delivery may be achieving 95% delivery on MTN numbers and 65% on 9mobile numbers, or 90% delivery in the morning and 70% delivery during evening peak hours.

How to identify: break down delivery rates by operator, by time of day, and by region. The patterns reveal where to focus optimisation. How to fix: implement retry logic with operator-specific timing, and use multi-gateway redundancy for critical reward delivery — if one gateway fails delivery, automatically retry through a second gateway.

Reward issued:        10,000   (100%)
├── Sent to gateway:   9,950    (99.5%) — gateway connectivity
├── Accepted:          9,720    (97.2%) — number validity
├── Delivered:         8,100    (81.0%) ← where most failures are
├── Opened/read:       6,800    (68.0%) — engagement rate
└── Redeemed:          5,440    (54.4%) — redemption rate

// Without the middle metrics:
// Issued: 10,000 | Redeemed: 5,440 = "54% redemption"
// You don't know whether to fix delivery or catalogue.
// With the funnel:
// Delivered: 81% | Redeemed of delivered: 67%
// Delivery is the problem — not the catalogue.