QR Loyalty for Kenyan Retailers and Trade Influencers

≡Table of Contents⌄

A carton of paint leaves a wholesaler's yard in Nairobi with a code printed inside the flap. Four days later a fundi opens it on a site outside Thika and scans that code on a handset showing half a bar of signal. Whether anything happens next, and how soon the money lands, is the whole programme.

Brands running trade loyalty in Kenya are reaching two different people with one mechanic. Duka owners and wholesalers buy stock and want the volume they move recognised. Fundis, masons, painters, plumbers and mechanics never buy for resale — they choose a brand on somebody else's job, and the only evidence they were there is the empty packaging.

A QR code can serve both, but only if the plumbing behind it is honest: enrolment that finishes in one visit, scans that are validated rather than counted, duplicates refused without insulting genuine claimants, and rewards that settle over M-Pesa without anyone asking twice.

Who a QR Programme Is Actually For

Trade loyalty in Kenya is really three programmes wearing one name, and the first design decision is to admit it.

• Retailers. The duka, the kiosk, the mini-mart, the agrovet, the hardware shop on a busy corner. They buy for resale, and their reward competes with a discount they could have asked for at the counter instead.
• Wholesalers and stockists. Larger volumes, fewer accounts, and a counter assistant doing the scanning rather than the owner. The person holding the phone is often not the person the reward belongs to.
• Trade influencers. Fundis, masons, painters, plumbers and mechanics. They are paid for labour, not stock, so accrual has to be per pack opened rather than per shilling invoiced. They never see an invoice.

Retailers usually want the reward against the account. Trade influencers want cash, and soon, because it tops up a day's work rather than rebating a purchase. Write the rules separately even when the code on the carton is identical.

What the Code Has to Carry

There are two kinds of code, and choosing wrongly at the printing stage cannot be corrected later in software. A generic code — the same image on every pack — can be claimed by anyone, any number of times, so it cannot be controlled, and within a season it circulates as a photograph in a chat group.

A serialised code, unique per pack, case or bundle, is the only version that supports a real programme. Each code becomes a single claimable item with a state: unissued, despatched, claimed, blocked.

Placement matters as much as content. A code on the outside of a carton can be harvested by anyone passing a bin. Inside the flap, under the cap, beneath a scratch panel or on the inner liner, it is reachable only by whoever opens the pack — the behaviour you are paying for. Print a short human-readable equivalent beside it, because a code smudged in a hot yard should still be claimable by typing.

Tie every serial back to its batch and its despatch. That link tells you whether a code redeemed near Kisumu was ever sent anywhere near Kisumu, and it doubles as batch traceability if a KEBS or quality question arrives.

Enrolment That Finishes in One Visit

Enrolment is where these programmes lose the people they most wanted. A form needing a second visit, a document nobody carries, or a signal that is not there goes uncompleted, and the reason never reaches head office.

Keep the captured set small and make every field earn its place: name, trade or outlet type, the shop or site, a +254 number, the M-Pesa number where it differs, a town, and a recorded consent. For a duka, add the outlet record and a geo-pin so the account joins the route data your reps already work from. Anything more is a longer conversation in exchange for a decision nobody was going to make.

Verify the number at capture with a one-time code. A mistyped digit found eight weeks later at payout is not a data problem — it is somebody who did the work and never got paid, and they will mention it to every other fundi at the counter.

Two routes usually run side by side. Reps enrol retailers during the normal call, in the same app as orders and coverage. Trade influencers more often enrol themselves on a first scan: scan, register, watch the accrual land. Both have to work with no connection, because rural signal is uneven and power interruption is a real planning assumption in Kenya.

What Happens in the Second After a Scan

The scan is the entire product as far as the participant is concerned. It has to return a decision quickly, and say what happened rather than flash a tick. There are only a handful of honest outcomes, and each needs plain-language wording available in English and Kiswahili:

• Accepted. Points added, running balance shown, and the value in KSh where the scheme settles in cash.
• Already claimed. With the date it was claimed, so a genuine claimant can argue rather than guess.
• Not recognised. The code is not one of yours, or it was never despatched.
• Outside the scheme or expired. Wrong product, region or participant type, or a claim window that has closed.
• Held for review. Something looked unusual and a person will look at it.

Offline, only the timing changes. The scan queues on the handset, the participant sees a pending accrual rather than nothing, and it is confirmed or reversed on sync. A scan that vanishes when the signal drops does more damage than a refusal: it teaches people the programme is unreliable rather than strict.

Blocking Duplicate and Recycled Scans

Every serialised programme gets attacked, rarely by criminals. It is attacked by people finding the cheapest legitimate-looking route to a reward: a counter assistant scanning unsold stock, codes lifted out of a yard, one handset enrolled under several names.

The base rule is not negotiable. One code, one claim, recorded in a ledger that is the single source of truth — the first valid scan wins and every later attempt returns the claimed date. A few pattern rules catch most of the rest:

• Velocity. A run of scans from one handset inside a few minutes, or one device scanning across several accounts, is a pattern no working day produces.
• Geography. A serial despatched to a Nakuru distributor and claimed the same week in Mombasa is worth a look, and the despatch link is what makes that answerable.
• Sequence. Consecutive serials from one case, claimed one after another, usually mean an unopened case rather than a run of completed jobs.
• Never despatched. Codes printed but damaged, written off or still in the plant should never validate at all.

Make the response proportionate. A hard rejection that fires on a busy but genuine day teaches people the programme is arbitrary. A hold-for-review queue keeps the claim alive and gives the field team an appeal route to point at. Blocking has to look fair, or it costs more participation than it saves in leakage.

Tiers People Can Explain to Each Other

A tier structure works only if a painter can explain it to another painter while they wait at a hardware duka counter. That is the design test, and it rules out most of what gets drawn in a planning session.

Three tiers is usually the ceiling, and each has to change something the participant can feel: a better rate per scan, a lower payout threshold, earlier access to a seasonal scheme. A tier that only alters a badge on a screen is decoration, and people work that out quickly.

Publish the qualifying period, the rule for falling out of a tier alongside the rule for climbing in, and the conversion rate itself. If a scan is worth a stated number of points and points convert to KSh at a stated rate, participants can do the arithmetic themselves. Silent demotion, or a rate that moves quietly, turns an advocate into a complaint.

Settling Rewards Over M-Pesa

In Kenya the reward settles over M-Pesa. That is how money reaches a fundi or a duka owner, and a programme leading with vouchers or gift items offers something less useful than what people already use daily.

The design questions are timing and threshold, not the rail. Paying every scan instantly produces a stream of very small transfers, each carrying a cost. A threshold — say KSh 500 — or a weekly payout run is usually cleaner, provided the balance and the distance to it stay visible in the app. Publish whichever you pick, because "when will it come" decides whether people keep scanning.

Three operational details cause most of the pain and are worth solving before launch:

• Name and number mismatch. The registered name and the name the M-Pesa number resolves to often differ — a spouse's line, a shop line, an old number. Confirm the payout number at enrolment and again at first payment, and re-verify whenever it changes.
• Failed disbursements. Numbers go dormant, limits are reached, digits get transposed. Failures need a retry queue, a visible status in the app and an owner in the team.
• A ledger anyone can read. Every accrual, adjustment, reversal and payment, with dates. Disputes get settled by showing the statement, not by arguing about memory.

Money travels the other way too. Retailers pay their distributor into a till or a paybill, and matching those receipts back to invoices is its own discipline — covered in M-Pesa reconciliation and collections. Some brands settle retailer rewards as a credit against the next invoice instead, which moves the reward onto the invoice trail where finance can see it.

A Morning at a Hardware Duka in Thika

The shop is on a side street off the main road in Thika, one counter deep, paint and fixings stacked to the ceiling. By half past eight there are four people waiting: two painters buying for a job, a plumber after fittings, and a rep working the beat with a handset.

The rep enrols the plumber in about two minutes — name, trade, the +254 number, a one-time code confirmed on the spot, consent recorded. The painters are already enrolled and open their tins at the counter out of habit, because the code sits under the lid and scanning at the shop beats remembering to do it on site.

One scan comes back as already claimed. The screen shows the date, and the painter recalls that tin came from another shop last week and he had scanned it then — exactly the answer that message is designed to produce. The second goes through, the balance moves, and the app shows how far he is from the payout threshold. There is no signal in the shop, so both scans queue and clear later.

The owner is on the same programme for a different reason. His accrual comes from cases taken in and settles as a credit against his next invoice, so the reward lands on what he owes. The trade payout run goes over M-Pesa on Friday, and by Monday the only people the field team hears from are the two whose numbers failed — a queue somebody works, not a mystery.

Consent, Records and the Paper Trail

A loyalty programme collects personal data: names, phone numbers, trades, locations and a payment history. In Kenya that sits under the Data Protection Act, 2019, with the Office of the Data Protection Commissioner as regulator.

Collect only what the programme uses. Say plainly at enrolment what it is for and how long you will hold it. Give people a way to leave and have their number removed. Restrict who can export a participant list. Most of the risk here is not a breach — it is a spreadsheet of enrolled numbers forwarded so often that nobody can say where it now lives.

There is a tax dimension too. KRA has required electronic tax invoices through eTIMS since January 2024, and income and expense declarations are now validated against eTIMS data. A loyalty payout is not an invoice, but a reward settled as a credit or discount against a trading account touches the invoice trail and has to agree with what was invoiced. Cash rewards to trade influencers sit outside the sales invoice and still need a clean record — name, number, date, amount. Agree the treatment with your finance and tax advisers before launch.

Where QR Loyalty Programmes Go Wrong

The failures are consistent enough to list, and nearly all of them are decisions made before a single code was printed.

• Generic codes. One image on every pack cannot be claimed once, so it cannot be controlled. Everything after that is guesswork dressed as data.
• Enrolment that needs a second visit. Every extra field, document or callback loses somebody who was willing on the day.
• Silence after the scan. No balance, no reason for a refusal, no indication of when payment comes. Participation dies quietly and no report explains it.
• Fraud control with no appeal. Hard rejections with no route to a human turn honest claimants into detractors.
• Payouts run by hand. A spreadsheet and a manual disbursement list survive the pilot and collapse the month it succeeds.

How 1Channel Supports QR Loyalty Programmes

Scanning, validation, tiers and payouts are one moment at a counter, not separate systems, so 1Channel handles them on one platform alongside the orders, coverage and outlet data the same team already works from.

The platform is offline-first and runs on entry-level Android handsets, so enrolment and scanning finish where they happen and sync when the network returns. A team can:

• Enrol retailers, wholesalers and trade influencers in the field, with number verification and recorded consent.
• Issue and track serialised codes against batch and despatch records, so a claim can be checked against where the stock went.
• Validate scans online or offline, with a single-claim ledger that blocks duplicate and recycled codes, and route unusual claims into a review queue with an appeal path.
• Run separate scheme rules, tiers and accrual rates for retailer and influencer programmes.
• Keep a points ledger per participant, and process payout runs over M-Pesa with thresholds, batching, failure handling and retry status.
• Support Data Protection Act, 2019 obligations through role-based access, audit trails and controlled export, and support eTIMS-aligned invoicing where rewards settle as credits on account.

Key Takeaways

A QR loyalty programme is judged on two moments: what the screen says after the scan, and how long the money takes. Get those right and the rest is administration.

• Serialise the code. One code, one claim, tied to a batch and a despatch — everything else rests on that.
• Hide the code inside the pack. Reward whoever opened it, not whoever found the carton afterwards.
• Finish enrolment in one visit. Few fields, a verified +254 number, recorded consent, and it must work with no signal.
• Refuse fairly, not silently. Say why a scan failed, hold doubtful claims for review, and give people a route to appeal.
• Settle over M-Pesa on a published schedule. A stated threshold, a working retry queue for failures, and a ledger anyone can read.

Do that and the programme stops being a campaign that needs defending, and becomes the most reliable view you have of who moves your product.