B2B loyalty programme: how to automate dealer rewards

A dealer sees a promised reward in an account manager’s email but cannot use it on an order. Accounting calculates turnover after returns, while the website uses created shopping carts. In this situation, a B2B loyalty programme needs consistent rules for earning, redeeming and checking rewards, not another email campaign. Rules first, module second.

A manufacturer or distributor needs to establish who owns the reward and what happens when an order changes. Let us look at combining a rewards mechanism with a B2B portal and accounting without uncontrolled discounts.

Start by defining the recipient and the economics of the reward

A corporate buyer may have a purchasing officer, a department head and a finance specialist. An individual’s user account is not the same as the company that signs the contract. The programme terms should therefore explicitly identify the participant: a legal entity, a particular branch or another agreed unit. Decide whether branches’ turnover is combined and who is entitled to spend the accumulated rewards.

A reward for a company and a personal gift for one of its employees are different models. The latter may conflict with the customer’s procurement rules, so it should not be quietly substituted for the former. The responsible finance and legal specialists must approve the form of the reward, the documents and its accounting treatment. Having a technical rewards module does not replace this approval.

Choose the behaviour you want to encourage: regular purchases, a broader product range or an agreed turnover level. Check the financial result after rewards, logistics and returns, taking account of contractual discounts already granted.

Which mechanism is actually worth automating?

Points are not an essential feature of loyalty. Sometimes a transparent quarterly bonus is simpler for both the customer and accounting than a complex tier system. Compare mechanisms based on the behaviour they support and the data needed for a fair calculation.

Start with one mechanism. Define how discounts, promo codes and rewards can be combined. For exceptions approved by an account manager, record who approved them and why.

How to structure earning, redemption and transaction history

Reward transaction records are best designed as a log of changes rather than a single editable “balance” field. Each transaction needs a participant, a supporting document, a change type, a number of points, a timestamp and a rule version. This history must explain the current balance. Manual corrections should also be recorded as separate transactions with a reason.

Award points after an agreed event

A created order is not yet a paid purchase. Decide when a reward is merely pending and when it becomes available: after payment, shipment or another agreed confirmation. Partial deliveries require an appropriate calculation base. In the portal, distinguish between pending, available and reserved points so that the buyer does not mistake a forecast for an amount ready to spend.

An event may arrive again after a failure. Checking its unique identifier must prevent a second reward. Keep the version of the terms so that earlier calculations can be reproduced.

Redeem points with reservations and returns in mind

When two purchasing officers place orders simultaneously, they must not be able to spend the same balance twice. Provide for reserving the reward, final redemption after a defined confirmation and release of the reservation on cancellation. If an order gets stuck, its reservation must have a clear time limit and a controlled way of being resolved.

A product return requires two separate decisions: what to do with the points earned on that purchase and what to do with the points used to pay for it. These transactions must not be confused. An illustrative example of history, expiry and refund settings can be found in the official Adobe Commerce documentation on reward points. However, this documentation alone does not establish that your solution supports a shared B2B company balance.

A hypothetical example: purchase, return and another redemption

Suppose a distributor agrees the following rule for a customer company: one point for every UAH 100 of the defined calculation base for a paid purchase. In this hypothetical example, delivery and other exclusions have already been removed from the base, and rounding is downwards per document. This is not a GL.ua case study or a recommendation of a particular rate.

With a confirmed calculation base of UAH 80,000, the system awards 800 points. A partial return reduces this base by UAH 10,000: a separate entry reverses 100 points, leaving 700. The buyer reserves 300 points for a new order. Until it is confirmed, 400 points are available and another 300 are reserved. If the new order is cancelled, the reservation is released and 700 points are available again.

If the original payment notification arrives a second time, the total does not change. If a return occurs after all the points have been spent, a rule agreed in advance is needed: for example, a controlled points debt to be repaid through future earnings. Do not disguise it as a zero balance or change the price of a completed order without a defined process.

The monetary equivalent of points, the maximum share of an order they can cover and compatibility with an individual price list need to be agreed separately: this example does not define them.

Where rules and access permissions should reside

ERP integration is needed where the accounting system is what confirms payment, delivery and returns. The CRM can hold agreements and the partner’s segment, while the portal displays terms and available actions. However, only one designated component should be the source of the final rewards balance. Several independent calculations create disputed amounts.

A built-in module makes sense if it covers your rules. Consider a separate service for multiple channels and custom development for non-standard contracts and roles. Check licensing, compatibility, history export and maintenance costs, not just the look of the widget.

Link the company, its branches and users using stable identifiers. A purchasing officer may be allowed to view the balance, while only an approved role can spend it. An employee’s departure must neither remove the company’s history nor leave that employee with access. Related rules for accepting terms are worth considering alongside B2B quote approval and order handover, but the rewards ledger remains a separate process.

How to test the programme before opening it to dealers

Acceptance testing must demonstrate that the balance can be reproduced and that errors can be corrected without losing history. Prepare test companies with different roles and reference documents.

1. Document the rules: participant, calculation base, confirmation event, rounding, exclusions, expiry and redemption procedure.
2. Calculate the expected result manually for payment, partial delivery, return, cancellation and a tier change. Compare it with the system for each transaction.
3. Replay messages, change their arrival order and interrupt the connection. Check that data exchange recovers without awarding points twice.
4. Have two users redeem points simultaneously. Check reservations, insufficient balance, access denial and reservation release.
5. Reproduce expiry and the reversal of a reward that has already been used. Reconcile the ledger, the portal and the data in the responsible accounting component.
6. Launch with a limited group of partners, appoint someone to handle discrepancies and test stopping new transactions without deleting history.

Before the pilot, reconcile a parallel calculation without issuing rewards. The article on safe online store releases provides further guidance on releasing changes.

Risks, timelines and cost components

The most dangerous discrepancy is between the terms offered to the buyer and the system’s actual logic. Other risks include duplicate companies, hidden stacking of discounts, expired reservations and unexplained manual changes. Restrict permissions, log exceptions and define a dispute resolution procedure. If identifiers are unstable or the economics have not been agreed, it is better to postpone launch.

What determines how long the work takes?

First, agree the terms and check the data; then implement the ledger and data exchange, followed by the portal, test scenarios and pilot. The timeline depends on the number of systems, availability of a test environment, quality of historical records and speed of approvals. Closing a rewards period must also be tested: one successful day of operation is no substitute. A calendar estimate should be given after checking integrations and exceptions.

The budget should include rules analysis, data preparation, development or licensing, integrations, access permissions, the interface, testing and account manager training. After launch, data exchange monitoring, reconciliation, support and changes to the terms are needed. Budget separately for funding the rewards themselves: this is not a programming cost. Assess results by company activity, repeat purchases and the financial result after incentives, not by the number of points issued.

Where to start with automation

Prepare a page of rules and reference transactions before choosing a platform. If the team calculates returns and reward redemption differently, automation will accelerate the discrepancies. Start with a mechanism that the partner understands and that can be checked against the ledger.

To assess implementation of the portal and data exchange, send GL.ua (Glyanets) a programme description, sample documents and a list of systems as part of a discussion about business website development. This will provide a concrete basis for defining the scope of work, integrations and acceptance criteria.