Loyalty & CRM

How it works

A loyalty system for a self-service car wash network. The customer registers in the app and tops up a balance, receiving a bonus that grows with the amount: ten percent on a standard top-up, fifteen above 200 UAH, twenty above 300. The funds are spendable immediately from the balance at any bay in the network.

The thresholds and rates are settings, not constants in code. The owner changes them without waiting for a developer, whenever they want to run a promotion or test an assumption. This matters: a loyalty programme you cannot change quickly stops being a tool and becomes technical debt.

Why this is harder than it looks

A balance is the customer’s money, and it has to reconcile every time. A top-up, a bonus accrual and a spend at the bay are three separate events happening at different moments in different places: in the app, on the payment server and on the wash equipment. A bay can lose connectivity mid-wash, a payment can confirm late, and a customer can start a second wash before the first is closed.

So every balance operation executes exactly once regardless of retries and delays, and a gap between what was charged and what was actually delivered shows up in a report rather than in a customer complaint. This is the same engineering as revenue reconciliation per device: three sources of numbers that never agree on their own.

The system runs through the network’s app and its API — the logic lives on the server, not in the phone. The app can be updated and the mechanics changed while the balance history stays intact.