The Retainix 5-Second Counter Rule

I learned the counter rule while watching staff use Retainix at a petrol pump.

If earning or redeeming takes more than five seconds to explain, the queue backs up, the staff skips it, and loyalty adoption drops to zero — no matter how good the platform looks in a demo.

Importantly, the reward is not per branch. It is one programme, shared members, branch-aware activity — as we describe in our case study. A reward earned at one branch must be usable at another when the rules allow it, and staff must see the same rules wherever they walk in.

5-SECOND COUNTER RULE — BRANCH-SAFE BY DESIGN

Earn at one branch, redeem at another — without staff re-learning per site.

Branch-Safe Sequence Flow

A 4-step sequence across three actors: Branch A, Platform, and Branch B.

1. Branch A to Platform: earn via POST /earn at the counter.
2. Platform to Branch B: member sync updates the shared member balance.
3. Branch B to Platform: redeem check verifies eligibility across sites.
4. Platform to Branch A: balance view remains consistent in real-time.

What breaks at the counter: different rules per branch, cashback timing, refund handling. If staff cannot explain it in 5 seconds, adoption dies.

Lesson: one programme, one rule set, one member view — taught at the counter, not in a deck.

BRANCH A

originating counter

PLATFORM

shared source of truth

BRANCH B

cross-branch counter

time sequence ↓

Branch A (Origin)⇄Platform (Sync)⇄Branch B (Redeem)

1. Step 01Branch A → Platform

   earn → POST /earn

   Customer earns points at Branch A counter with instant branch context.

2. Step 02Platform → Branch B

   member sync

   Shared member state updates on platform; balance becomes visible across all branches.

3. Step 03Branch B → Platform

   redeem OK?

   Staff at Branch B checks eligibility against shared rules without needing separate sheets.

4. Step 04Platform → Branch A

   balance view

   Real-time synchronized balance view remains consistent regardless of walk-in site.

What breaks at the counter

different rules per branch · cashback timing · “what if refund?” — if staff can’t explain it in 5 seconds, adoption dies.

Lesson: one programme, one rule set, one member view — taught at the counter, not in a deck.

What the counter teaches

Loyalty rules look simple on a whiteboard: earn points on purchase, redeem later.

At the counter they fracture:

• Which branch’s rule applies right now?
• What is the cashback timing — immediate or after settlement?
• What happens if the ticket is refunded?
• Who can explain this without opening a manual?

If those answers live in different branch memories or spreadsheets, the member experience is already broken.

Retainix started from those multi-location operations — not from a loyalty feature list. The requirement was that earn and redeem be simple for staff, consistent across sites, and measurable as one programme.

One programme, not per-branch reinvention

We run one programme shared across all branches. That is a product decision, not a setting.

Where it works	How we kept it simple — so the queue never stalls
Earn	Same rule at every counter; staff taps once, member sees the same balance — no manual needed
Redeem	Shared member base — reward earned at one branch is valid at another when you allow it
Reporting	Branch-aware activity without a separate spreadsheet per site — one view you trust
Mental model	One rule set taught at the counter, not per-branch exceptions in a deck

Multi-business admin is intentionally not exposed until a real second organisation needs it. The platform is multi-tenant under the hood; the surface today is one business with live multi-branch.

That constraint is discussed in our product story and mirrors the MVP checklist: cut surface, raise quality on what remains.

Branch-safe by design — the flow we run

The flow that survives the queue is the simplest that can be trusted:

1. Earn at the counter — a single POST with branch context.
2. Sync on the platform — member view updated once, visible from any branch.
3. Redeem check — shared member read, branch-aware rule applied, staff sees a clear “eligible or why not.”

Speed is the quality bar. As we noted in our case study, if cashiers take more than five seconds to grant points, loyalty adoption drops to zero.

That is why we built explicit states for each step — the same invisible engineering we describe in good engineering by design. When the sync is pending, the staff sees what is safe to retry. When redemption is denied, the screen says who can help without exposing role IDs.

What this means for your MVP

If your product has more than one location, door, or counter, test the core job where time actually matters.

A demo that adds three seconds per transaction will not survive the first busy hour.

We scope that risk in the timeline — weeks 3–4 harden the paths where money and trust are on the line — and we price it honestly in the cost breakdown.

Want to apply the counter test to your product? Test Your Core Job at the Counter — we map it where time actually matters and make the rule teachable in five seconds.